Estudo de caso
Moringa: uma feira online para quem faz à mão
Um marketplace com dois lados. Quem compra encontra a peça, paga e acompanha o pedido até chegar. Quem faz cadastra as peças e envia os pedidos de um só painel. Cada peça leva a história de quem a fez.
O problema
Quem faz peças à mão no Brasil, como ceramistas, tecelãs e marceneiros, vende principalmente por mensagens no Instagram, WhatsApp e feiras locais. Funciona, mas custa tempo: as mesmas perguntas de novo e de novo, fotos enviadas uma a uma e nenhuma visão clara de quem pagou e do que falta enviar. Os grandes marketplaces resolvem a logística, mas escondem a pessoa por trás da peça.
Escrevi um brief do produto, duas proto-personas (Dona Lúcia, ceramista, e Marina, compradora) e um backlog com critérios de aceite antes de desenhar qualquer tela. Os documentos estão em inglês.
O que construí
- Catálogo com busca e filtros por região, material e preço, compartilháveis pela URL.
- Sacola e Stripe Checkout em modo de teste, com cartão e Pix, confirmado por um webhook assinado.
- Área de quem compra: pedidos, linha do tempo que atualiza sem recarregar, código de rastreio e avaliações.
- Área de quem vende: formulário guiado para cadastrar peça, editar ou pausar, gráfico de vendas com versão em tabela e pedidos para enviar.
- Português e inglês, tema claro e escuro, uso completo pelo teclado e com leitor de tela.
Decisões que valem explicar
O servidor nunca cobra um preço que a pessoa não viu
A sacola guarda o preço do momento em que a peça entrou. Quando quem vende passou a poder editar preços, isso podia deixar um preço antigo no botão de pagar. Agora a sacola se atualiza e avisa o que mudou, e o servidor se recusa a criar o pagamento se os preços forem diferentes.
Formulários validam ao enviar e depois enquanto a pessoa digita, nunca ao sair do campo
Um erro que aparece quando o campo perde o foco empurra o botão para baixo bem na hora do clique, e o clique erra. Validar ao enviar e depois a cada mudança, como recomenda o GOV.UK, evita isso.
Limite de tentativas que funciona em serverless
Login, checkout e consulta de pedido têm limites guardados no Postgres, então todas as instâncias do servidor compartilham a mesma contagem. O IP é salvo só como hash com salt, seguindo o princípio da LGPD de coletar o mínimo. Se o armazenamento falhar, a requisição passa: um soluço no banco não pode trancar todo mundo do lado de fora.
Uma Content Security Policy rígida
Cada requisição recebe um nonce novo, e só rodam os scripts que o carregam ou que foram carregados por eles. Com os outros cabeçalhos, o site no ar tem A+ no Mozilla Observatory.
Qualidade, medida
Medido no site no ar e em todo pull request. Última verificação em 22 de outubro de 2026.
| Área | Resultado | Como é verificado |
|---|---|---|
| PageSpeed Insights | 100 · 100 · 100 · 100 | Performance, acessibilidade, boas práticas e SEO, celular e computador; Lighthouse CI em todo pull request |
| Acessibilidade | 0 violações no axe · WCAG 2.2 AA | axe em todas as páginas nos dois temas, testes de teclado e foco no Playwright |
| Cabeçalhos de segurança | Mozilla Observatory A+ | Verificação no site no ar |
| Varredura de vulnerabilidades | OWASP ZAP: 0 alta, 0 média, 0 baixa | Varredura base em todo pull request |
| Testes | 179 unitários e de integração · 158 ponta a ponta | Vitest, PGlite (Postgres real em memória), Playwright no celular e no computador |
O ciclo de QA
Depois de construir, troquei de chapéu e testei o Moringa como uma analista de QA faria, seguindo um plano de teste. Todas as 15 histórias Must e Should têm casos de teste: 58 no total, 49 automatizados e rodando em todo pull request.
Uma sessão exploratória achou o BUG-001, de severidade alta: depois que quem vende editava um preço, a sacola e o botão de pagar ainda podiam mostrar o antigo. Foi corrigido com testes de regressão em três níveis: unitário, integração e ponta a ponta.
O mesmo ciclo deixou o pipeline mais rápido: agora um único build é compartilhado pelos jobs de ponta a ponta, Lighthouse e ZAP, e a suíte ponta a ponta roda em dois shards em paralelo. Relatório final de testes (em inglês).
O que aprendi
- Perguntar "por que isso confia nesse número?" levou de um teste de adulteração inofensivo a um bug real.
- Uma funcionalidade nova pode tornar falsa uma suposição antiga. Agora toda história nova passa por uma pergunta: "o que isso deixa de ser verdade?".
- Registrar alarmes falsos poupa a próxima pessoa da mesma hora de investigação.
Experimente
Sem cadastro: cada conta de demonstração é um clique. Pague com o cartão de teste do Stripe 4242 4242 4242 4242, qualquer data futura e qualquer CVC. Abrir o Moringa.