Procurar emprego virou um trabalho paralelo: abrir vários portais todos os dias, reescrever o currículo para cada vaga e, no fim, não saber o que está funcionando. O TrackVagas é um SaaS que tira esse trabalho das costas de quem busca vaga.

Foram 16 dias do primeiro commit ao ar. Mas "construir um SaaS" não é só programar. Neste post eu conto o que o produto entrega e, em seguida, todas as frentes que existiram por trás dele: desenho do produto, design e animações, engenharia, segurança, testes automatizados e manuais, cobrança e lançamento. Usei IA como ferramenta de trabalho em várias dessas frentes, e conto onde ela ajudou e onde as decisões continuaram sendo minhas.

O problema que o produto resolve

Quem está se candidatando costuma enfrentar o mesmo trio de problemas:

  1. Procurar em vários portais é trabalho manual e repetitivo. São horas por semana abrindo as mesmas buscas.

  2. O currículo é reescrito para cada vaga, mas ninguém guarda qual versão foi para onde. Quando a resposta chega (ou não chega), não há como ligar o resultado ao currículo enviado.

  3. Os retornos se perdem. Chegam por e-mail, WhatsApp e portais, e sem registro não dá para saber se o problema está no portal, no currículo ou no tipo de vaga.

O resultado é aplicar no escuro. O TrackVagas parte de uma pergunta simples: o que, de fato, gera retorno?

O que o produto entrega

  • Buscas diárias nos principais portais, com filtros (modalidade, senioridade, local etc.). As vagas chegam ordenadas pela aderência ao currículo.

  • Currículo-mestre em português, inglês e espanhol, e versões por tipo de vaga. Uma versão aprovada nunca muda, e o banco garante isso.

  • Adaptação com IA que reescreve o currículo para a vaga sem inventar experiência.

  • Retornos por e-mail registrados sozinhos: uma regra de encaminhamento no Outlook ou no Gmail, e o app reconhece entrevista, recusa e confirmação.

  • Métricas: funil, taxa de retorno e de entrevista por portal, por versão de currículo, por tecnologia, modalidade e senioridade.

  • Seus dados são seus: exportar tudo (ZIP com JSON, CSVs e PDFs) e excluir a conta pelo app.

Por trás do produto

Um produto de verdade não nasce de "escrever código": nasce de entender o problema, desenhar a solução, construir com segurança e testar antes de entregar. Estas são as frentes que existiram por trás do TrackVagas.

1. Desenho do produto: antes de qualquer código

A primeira semana não foi de código. Foi de decidir o que construir e o que deixar de fora:

  • Levantamento do negócio e do problema em 15 pontos (quem tem a dor, quais os riscos, se vale construir), com uma decisão explícita: começar como ferramenta própria e só virar produto se fizesse sentido. Fez, e o projeto passou a ser construído "como se pudesse virar produto" desde o início: página de apresentação pública e dados de cada usuário isolados.

  • Documento de requisitos (PRD) com problema, objetivos mensuráveis, escopo da primeira versão (MVP) e etapas. Cada mudança de escopo entrou em um histórico.

  • Etapas pequenas: currículo-mestre, vagas, importação, candidaturas, retornos, métricas, currículos por tipo de vaga, IA. Cada uma terminava em produção antes da próxima.

  • 91 decisões registradas em formato curto (problema, escolha, por quê). Elas viraram a memória do projeto: quando eu voltava a um assunto, a conversa começava do registro, não do zero.

  • Nome, logo e domínio escolhidos por mim. O produto nasceu com outro nome de trabalho; o nome TrackVagas, a lupa azul com a maleta amarela e o domínio trackvagas.com.br foram decisões minhas. Marca é parte do produto, não enfeite.

  • A vaga como centro do modelo. Uma decisão de produto que mudou a linguagem da página de apresentação e abriu caminho para um futuro ambiente de recrutadores: a candidatura é só o vínculo entre a pessoa e a vaga.

Uma regra que guiou tudo: nenhum serviço novo entra no projeto sem decisão consciente e sem registrar o motivo e o custo.

2. Design e animações: a IA ajuda, o olho decide

A identidade visual foi decidida cedo (tinta azul-marinho com marca-texto amarelo e, depois, o nome, a logo da lupa com a maleta, o favicon e o domínio) e protegida: ela não é refeita a cada tela.

  • Página de apresentação com demonstrações animadas: uma planilha viva no topo e uma seção "Registre, adapte, meça" com um app de demonstração que mostra buscas chegando, vagas sendo salvas e retornos entrando. É código, não vídeo, e o aviso "dados fictícios" deixa claro que são exemplos.

  • Instruções especializadas (skills) que orientaram a IA em cada tarefa de interface: uma para direção de design e auditoria, outra contra interfaces genéricas, uma de acabamento e detalhe, uma de movimento e outra de revisão de animações, uma para fazer o app parecer nativo no celular (PWA) e uma que tenta quebrar a tela com dados extremos (nomes enormes, listas vazias, textos longos).

  • Ajuste manual, o tempo todo. A IA gera boas primeiras versões; o acabamento é decisão minha: espaçamentos, a hierarquia de cada tela, o tamanho do toque no celular, o que anima e o que fica parado, o texto de cada botão. Boa parte das revisões foi eu olhando o app no navegador e no celular e pedindo (ou fazendo) o ajuste.

  • Acessibilidade e tema escuro tratados como parte do trabalho, não como extra.

Lição de design: a IA acelera o rascunho, mas "bonito" e "claro" continuam sendo julgamentos humanos.

3. Engenharia

  • Nuxt 4 e TypeScript para telas e rotas de servidor num só framework.

  • Nuxt UI (Tailwind 4) para componentes acessíveis e tema por tokens.

  • Supabase (Postgres, Auth, Storage): SQL de verdade para as métricas e RLS para isolar os dados.

  • Cloudflare Workers na hospedagem: barato, rápido, deploy a cada merge.

  • Apify nas buscas, porque os portais não têm API aberta.

  • Resend para receber o e-mail encaminhado e avisar o app por webhook.

  • Gemini na IA, atrás de uma camada que permite trocar de provedor.

  • Asaas na cobrança: cartão recorrente em reais, com webhook.

  • Zod para validar: o mesmo schema vale para formulário, API e resposta da IA.

Alguns problemas difíceis valem ser contados:

  • Dados de cada pessoa isolados no banco. Toda tabela tem user_id e política de RLS. Não confio só no código da aplicação.

  • O servidor é dono do estado sensível. Plano, limites e uso de IA não podem ser escritos pelo navegador.

  • IA que não inventa. O prompt só permite reordenar e reformular o que existe no currículo-mestre; a saída é validada; a tela mostra "o que mudou em relação ao mestre", com volta ao original. Testei também uma vaga que tenta mandar instruções ao modelo.

  • Retornos por e-mail sem ler a caixa de ninguém. Cada usuário tem um endereço próprio e cria uma regra de encaminhamento; nunca peço acesso à caixa.

  • Limites da plataforma. O limite de CPU do Worker me fez mover trabalho pesado para o navegador e manter telas estáticas.

4. Segurança

  • Isolamento por conta testado no banco, não só no código.

  • Ambiente de administração separado: subdomínio próprio, segundo fator obrigatório e log de auditoria de cada ação administrativa.

  • Chaves de produção só como secrets na hospedagem, nunca em código nem em prompts de IA. Quando uma chave ficou visível, eu a troquei.

  • Auditoria completa de segurança antes de abrir, conduzida com uma skill dedicada. Os achados foram corrigidos em pull requests separados, antes do lançamento.

  • LGPD no produto: exportar todos os dados e excluir a conta pelo app, política de privacidade e termos de uso.

5. Testes: automatizados e manuais

Automatizados

  • Mais de 350 testes de regras de negócio (métricas, status das candidaturas, planos, cobrança, validação da IA).

  • 289 verificações no banco (pgTAP): o que cada usuário pode ler e escrever, gatilhos e regras do plano.

  • Lint, checagem de tipos e testes rodando a cada pull request.

Manuais, e foram muitos

  • Cada tela olhada no navegador e no celular, em tema claro e escuro, com dados normais e extremos.

  • Fluxos de ponta a ponta com contas de teste: cadastro, redefinição de senha, busca, salvar, candidatar, registrar retorno.

  • Cobrança no ambiente de simulação e depois em produção com cartão real, incluindo cancelamento e estorno. Foi aqui que apareceu o erro que a simulação escondeu: o estorno devolvia o dinheiro e tirava o acesso pago da conta, mas a assinatura seguia ativa no Asaas e cobraria de novo no mês seguinte. Corrigi (o aviso de estorno agora cancela a assinatura) e cobri com teste. Teste dinheiro de verdade, de ponta a ponta, com estorno incluído.

  • Rodadas de ajustes depois de cada teste: foram vários pull requests só de "usei e percebi que…".

6. Cobrança e operação

Assinatura recorrente no cartão, webhook com token comparado em tempo constante, tarefa diária que encerra assinaturas vencidas, acesso especial que só o administrador concede, e painel de administração com métricas, custos e visitantes. Domínio próprio, e-mails transacionais e conta de empresa configurados.

O que esse processo entrega

Olhando para trás, estas são as marcas de um produto construído com cuidado:

  • Um começo que não é código: entender o negócio, o problema e o que não vale a pena construir agora.

  • Entregas em etapas pequenas, cada uma em produção, para ver e opinar enquanto o sistema cresce.

  • Design e acabamento cuidados, com identidade própria, e não só telas funcionais.

  • Segurança e testes desde o início, e não como remendo no fim.

  • IA como ferramenta, com responsabilidade humana sobre o que vai ao ar.

  • Atenção ao que foi entregue: correções, ajustes e evolução depois do lançamento.

Números do projeto

  • 16 dias entre o primeiro commit (5 de outubro de 2026) e o lançamento.

  • Cerca de 170 commits e dezenas de pull requests pequenos.

  • 37 migrations de banco e 91 decisões registradas.

  • 350+ testes de regras e 289 verificações no banco.

O que eu faria diferente

  • Testaria a cobrança real mais cedo. O erro do estorno só apareceu lá.

  • Colocaria pessoas de fora para usar antes. Detalhes pequenos (um clique na logo que não voltava ao topo, contagens que faltavam nas abas) só apareceram no uso de verdade.

  • Guardaria menos configuração solta em variáveis do painel. Hoje tudo vai direto como secret.

O que vem a seguir

O lançamento é só o começo. O produto está nascendo, e a próxima fase é fazê-lo crescer, com foco em marketing e distribuição, além de novos recursos (como um ambiente para recrutadores, novos idiomas e mais portais). E, claro, ouvir quem usa. O TrackVagas já está no ar em trackvagas.com.br.

Se você está procurando vaga, é só testar. E se você tem uma empresa, um processo manual ou uma ideia de produto que poderia virar software, e quer entender o que seria preciso para colocar de pé, é só me chamar! 😉✌🏽