Comecei um projeto pessoal: um app web para hábitos, tarefas e metas. Sete semanas e 253 commits depois, ele está no ar e aberto para todo mundo. Quero contar as decisões técnicas que mais pesaram, o que deu errado e quanto custa manter isso.
Stack Técnica
A stack utilizada foi Next.js 16 (App Router) + React 19 + TypeScript, na Vercel Pro (US$ 20/mês, o único custo fixo). PostgreSQL no Neon (plano grátis) com Prisma 7. PWA instalável (sem offline nem push, por enquanto). Rollbar para erros e Vercel Web Analytics para visitas, ambos no plano grátis. Paddle para a assinatura do Pro, como Merchant of Record: ele cobra na moeda de cada país, emite a nota e recolhe os impostos, e o app nunca vê dado de cartão.
Interface Não Espera o Servidor
A interface não espera o servidor. Todo clique (marcar um hábito, concluir uma tarefa) atualiza a tela na hora e só depois chama uma Server Action. Se a action falha, o estado volta. Isso mora num provider só (AppDataProvider), que fala com uma camada de repositórios que não sabe onde os dados moram: no servidor (Postgres) ou no navegador.
Métrica de Uso Sem Rastrear Ninguém
Queria saber se as pessoas voltam (D1, D7, D30) sem colocar cookie de rastreamento nem banner. A solução foi uma tabela própria de eventos no Postgres (AnalyticsEvent): o nome da ação e propriedades não pessoais, nunca o título do que a pessoa escreveu. Esses eventos entram na exportação de dados e somem quando a conta é excluída. As visitas da landing ficam com o Vercel Web Analytics, que não usa cookie.
Deploy Só Sai Se a Bateria Inteira Passar
Push na main é deploy em produção, então o CI virou porteiro: lint, typecheck e testes unitários (Jest) das regras de negócio, que são funções puras; build e 279 testes e2e no Playwright, em Chromium e WebKit; acessibilidade com axe em tema claro e escuro; snapshots de SEO (canonical, hreflang, sitemap); Lighthouse CI com pisos mínimos. O erro mais chato foi de hidratação: no runner lento do CI, o teste clicava antes de o React hidratar o botão, e o clique simplesmente sumia. "Network idle" não resolve. A saída foi esperar o React anexar as props ao elemento (__reactProps…) antes de interagir. Depois disso, os testes pararam de falhar aleatoriamente. No próprio dia do lançamento: o GitHub tinha trocado o ubuntu-latest para o Ubuntu 26.04, em que o apt não conseguia resolver os mirrors do Ubuntu, e o playwright install --with-deps ficava travado até o job estourar o tempo. A produção ficou protegida porque o deploy espera o CI; fixar o runner em ubuntu-24.04 resolveu.
Backup Que Eu Não Preciso Lembrar
Um workflow do GitHub Actions roda pg_dump todo dia e guarda o arquivo por 14 dias. Lição: o schedule do GitHub atrasa bastante. Meu cron das 06:17 UTC costuma começar 5, 8 horas depois. Para backup diário tudo bem; para algo com horário, não confie nele.
Vídeos de Lançamento São Código
Não sei editar vídeo, então os vídeos de divulgação são código do começo ao fim. Um script Playwright cria uma conta com dados de exemplo, move um ponteiro falso no ritmo de uma pessoa e grava pela screencast do DevTools. Cada quadro chega como JPEG com timestamp, e o ffmpeg monta um MP4 H.264 com a duração real de cada quadro. O gravador nativo do Playwright entrega VP8 a 1 Mbit/s, mole demais para 1080p. Depois, o Remotion (vídeo escrito em React) junta essas gravações com os textos na tela, em 16:9, 1:1 e 9:16, em português e inglês. Até a trilha é gerada por um script Python, então não tem licença de música para conferir. Mudou a interface? Rodo de novo e tenho tudo atualizado.
Conclusão
Um app de hábitos de zero a produção: decisões técnicas, erros e custos.
Comentários