30 dias solo, do primeiro commit ao Stripe live: a ordem que importou

Entre 2026-07-25 e 2026-08-24, o Tamperlens foi de repositório vazio a API em produção com billing Stripe em dólar e real. Foram 271 commits, uma pessoa. Este post não é sobre velocidade. Velocidade é consequência. É sobre ordem: o que veio primeiro, o que veio depois, e por que essa sequência específica é a parte reaproveitável para qualquer produto solo.

Primeiro, a cronologia verificável, direto do git e dos registros do projeto. Depois, as decisões de sequência por trás dela.

---

A cronologia, com carimbos

Dia 1: 2026-07-25, madrugada. O primeiro commit, à 00:51, não tem uma linha de código de produto. É o plano: go-to-market, arquitetura, plano de build e deploy. Dois minutos depois, o segundo commit cria o contrato do engine com um stub, uma implementação vazia que só cumpre a interface. À 01:08, o shell Fastify existe com autenticação, quota e o checker gratuito. À 01:23, chega o engine real: parser forense, as primeiras 10 famílias de sinais, scoring, fixtures e 111 testes. À 01:27, deployado, faltando um passo manual de Cloudflare.

Ou seja: plano, contrato, casca com billing-shaped auth (autenticação já pensada para cobrar), engine com testes, produção. Tudo em 36 minutos de commits, na primeira hora do projeto. No mesmo dia, o fluxo Stripe inteiro foi verificado em modo teste: checkout → webhook assinado (o aviso que o Stripe manda de volta) → plano aplicado → cancelamento revertendo para free.

Dia 3: 2026-07-27. Stripe em modo live, verificado ponta a ponta com dinheiro de verdade: checkout real, webhook live assinado, plano aplicado, cancelamento imediato, downgrade, refund. No mesmo dia, o tier de entrada foi criado. Os preços passaram a ser cotados na moeda do visitante. E a página em português passou a dizer com todas as letras que cartão brasileiro é cobrado em reais.

O resto do mês, que é a maior parte. Um repricing fechando 23 achados de revisão e os pacotes pré-pagos de créditos (30/07). Página de status pública (31/07). Uma bancada de evasão medida contra ferramentas reais (03/08, re-rodada em 15/08 e 24/08). Um post publicando a taxa de falso positivo própria, medida em 1.728 documentos reais (04/08). Uma página de evidências com as medições, incluindo as que falharam (06/08). Um servidor MCP, o protocolo que conecta assistentes de IA a ferramentas, empacotado (04/08) e publicado no registry oficial (18/08). E os 111 testes do primeiro dia viraram 1.605.

A régua de leitura honesta: cobrar era possível no dia 3. O produto que sustenta a cobrança levou os 27 dias seguintes e continua levando.

---

Decisão 1: o primeiro commit é o plano, e o plano mora no repo

Começar pelo documento não foi cerimônia. O plano no repositório fez duas coisas que um plano na cabeça não faz. Primeiro, fixou o contrato do engine antes do engine: o segundo commit é a interface e um stub, e todo o resto do sistema nasceu programando contra ela. Segundo, deixou o escopo do “pronto para cobrar” escrito antes do entusiasmo da madrugada opinar.

A consequência prática apareceu em horas. Com contrato estável, a casca HTTP, a autenticação e a quota puderam nascer antes de o engine fazer qualquer coisa útil. E quando o engine chegou, encaixou sem reforma.

Decisão 2: deploy na primeira hora, porque deploy é feature de aprendizado

O quarto marco do dia 1 é o deploy. Não porque houvesse usuários, porque não havia. Foi porque a esteira commit → produção é o instrumento de medida de tudo que vem depois. Cada decisão dos 29 dias seguintes foi tomada contra um sistema rodando no lugar real: TLS real, borda real, latência real. Isso inclui billing, headers, quota anônima e a página de status. A alternativa é integrar tudo “quando estiver pronto”. Ela cobra juros compostos: cada dia sem deploy é um dia acumulando diferenças entre o ambiente imaginado e o real.

Decisão 3: billing verificado com uma cobrança de verdade — e refund

A verificação do dia 3 merece detalhe, porque “integrei o Stripe” e “verifiquei o billing” são afirmações muito diferentes. O teste foi o fluxo inteiro, em live mode, com cartão real. Pagar, receber o webhook assinado, ver o plano aplicado na conta, cancelar, ver o downgrade acontecer, devolver o dinheiro. Cada transição de estado observada, não presumida.

Por que tão cedo? Porque billing é o subsistema com mais integrações externas e mais estados (webhook fora de ordem, cancelamento, moeda, disputa). É o pior candidato do sistema inteiro para “deixar para o final”. Verificá-lo no dia 3, quando o produto era pequeno, custou horas. Descobrir um webhook mal assinado no dia 30, com clientes reais no meio, custaria outra coisa.

E mesmo verificado cedo, o billing rendeu a lição mais barata-cara do mês. Semanas depois, uma reprecificação mudou o preço exibido. Só que a env var que nomeia o Price do Stripe, o identificador do valor que o Stripe cobra, não foi reapontada junto. Por uma janela, o site cotava um valor e o checkout cobrava outro.

A correção virou regra de arquitetura. O arquivo de planos é fonte para exibição e comparação. Quem cobra é o Price que a env var nomeia. E um teste compara os dois. Preço é o número que não pode divergir. E “não pode” só vale quando um teste reprova.

Decisão 4: USD e BRL sem conversão — moeda é decisão de cobrança, não de câmbio

O suporte a real não é uma conversão do preço em dólar. Cada Price no Stripe carrega um valor BRL definido à mão (currency_options). Isso por duas razões. A entidade brasileira do Stripe só cobra cartão emitido no Brasil em reais. E preço em moeda local é decisão de posicionamento, não de cotação do dia.

A mecânica de exibição é simples. Um endpoint público de pricing lê o país que a borda da Cloudflare, o servidor da rede mais próximo do visitante, anota na requisição (CF-IPCountry). Ele então responde a moeda: Brasil vê reais, o resto vê dólares, binário, já no primeiro paint.

O ponto fino que vale copiar: o país decide a moeda; o idioma é decidido por outro sinal, deliberadamente. Um brasileiro em Lisboa deve ler português e ver euros… não. Deve ler português e ver a moeda que o cartão dele vai pagar de onde ele está. Misturar os dois sinais é como se produz a página que diz $ e cobra cinco vezes o número impresso.

Os pacotes pré-pagos de créditos nasceram da mesma leitura de realidade. O comprador para quem eles existem é quem não assina recorrência. Um pacote cotado em dólar e cobrado em real surpreenderia exatamente a pessoa que ele deveria servir.

Decisão 5: publicar medição é trabalho de produto, não de marketing

Da segunda semana em diante, uma fração crescente dos commits não adiciona capacidade. Adiciona verificabilidade.

A bancada mede quais sinais sobrevivem a quais transformações de arquivo, e grava o resultado em JSON versionado. O post publica a taxa de falso positivo própria, medida em 1.728 documentos reais (985 PDFs públicos de governo dos EUA, 743 PDFs brasileiros da web). São números altos, publicados junto com o que mudou por causa deles. A página de evidências lista inclusive as medições que falharam. E os testes amarram cada número publicado à fonte, de modo que um release que invalide um número quebra o CI, a esteira automática de testes.

Num mercado onde ninguém publica taxa de falso positivo, publicá-la era a única forma de a afirmação “detector honesto” ser algo além de adjetivo. Publicar significa dar o denominador, a data e a engine version. O custo real disso não é escrever o post. É construir a bancada que torna o post re-derivável. Esse custo é o produto.

O que a sequência inverte, deliberadamente

Vale explicitar o que este roteiro não fez, porque cada omissão foi uma escolha:

• Não houve mês de engine antes da primeira cobrança possível. O engine do dia 1 tinha 10 famílias de sinais; hoje tem quase o dobro por modalidade e três motores. A profundidade veio depois da esteira completa existir. Cada família nova nasceu dentro de um sistema com deploy, billing, quota e testes esperando por ela.
• Não houve landing page antes de produto. O checker gratuito do dia 1 é a landing page: ele demonstra o produto fazendo o produto.
• Não houve “depois eu testo”. Os 111 testes do dia 1 não eram cobertura decorativa. Eram o contrato do engine executável. A proporção se manteve: ~15× mais testes em 30 dias, crescendo junto com o código, nunca atrás dele.

O checklist de sequência, para o próximo produto solo

1. Commit 1: o plano. Commit 2: o contrato. Interface e stub antes de implementação. Todo o resto programa contra o contrato.
2. Produção na primeira sessão. A esteira é o instrumento; sem ela, todas as decisões seguintes são tomadas contra um ambiente imaginário.
3. Billing verificado com dinheiro real e refund, na primeira semana. É o subsistema mais cheio de estados externos; idade não o melhora.
4. Um teste ligando preço exibido a preço cobrado. E fonte única nomeando quem cobra.
5. Moeda local à mão, decidida pelo país da requisição, separada do idioma.
6. Orce a verificabilidade como feature. Bancada, medições publicadas com denominador, testes que amarram número a fonte. É o que transforma “confie em mim” em “confira você”.

Trinta dias não é a parte impressionante. Madrugada e escopo pequeno explicam. A parte que se transfere é que nenhum desses seis itens depende de pressa: são decisões de ordem, e ordem é grátis.