Casos de sucesso

Problemas reais, decisões técnicas e o resultado que ficou depois da entrega.

22/22

Aluguel de jet-ski do anúncio ao repasse, em produção.

Contexto: Marketplace de duas pontas: de um lado quem tem um jet-ski parado, do outro quem quer o dia na água. São três aplicações, web, iPhone e Android, sobre um backend único.
Restrição: O caminho do dinheiro não admite ensaio: há divisão de valor entre plataforma e locador, caução bloqueada no cartão antes da retirada e estorno quando a reserva cai.
Decisão técnica: Stripe Connect com cobrança destinada e taxa de aplicação, caução fora de sessão e reversão de transferência no cancelamento. O backend é Java em arquitetura hexagonal, e tanto o BFF em Next quanto o app em Expo consomem o mesmo contrato.
Resultado: A jornada completa foi executada de ponta a ponta contra a API real, incluindo pagamento e estorno, e a régua medida entre o push e o código no ar é de catorze minutos.

2 produtos

A carteira debita antes de a mensagem sair.

Contexto: Camada de envio e recebimento entre os produtos e a API oficial da Meta, com número e marca próprios por cliente.
Restrição: A Meta cobra por conversa. Uma fila que reprocessa sem controle não gera log feio, gera fatura, e mensagem repetida para o cliente final não se desfaz.
Decisão técnica: O débito na carteira do cliente acontece antes do envio, com idempotência por chave e fila morta para o que falhar de verdade. Fastify e BullMQ sobre Redis, com console próprio em Next.
Resultado: Dois produtos em produção consomem o hub por chave de API, cada um mantendo a própria marca na conversa com o cliente final.

sem cadastro

O preço que paga a hora do dono, calculado sem conta.

Contexto: GPS financeiro para MEI e pequeno negócio: a conta de quanto realmente sobra, refeita sozinha quando o material sobe de preço.
Restrição: Um diagnóstico que pede e-mail antes de mostrar o número não é diagnóstico, é captura, e pedir faturamento a quem ainda não confia no produto é pedir cedo demais.
Decisão técnica: As mesmas funções de custo que rodam dentro do produto foram levadas para o navegador. A calculadora pública não tem servidor, não tem conta e não grava nada. Next sobre Turso, com política de segurança gerada a cada requisição.
Resultado: O visitante vê o próprio número antes de decidir se quer uma conta.

Caso anonimizado

39 habilidades

O relatório se recusa a imprimir fora da regra.

Contexto: Avaliação funcional da comunicação infantil, usada em consultório e entregue como relatório para a família ler.
Restrição: Relatório clínico não admite nota única, barra zerada nem número que ninguém mediu, e há expressões de autoria que não podem sair impressas.
Decisão técnica: O instrumento é dado versionado, e não código: a mesma definição alimenta a API em Rust, o front e os testes. Uma guarda de vocabulário roda na fase de captura do clique e cancela a impressão quando o texto viola a regra.
Resultado: Em uso clínico real, com trilha de auditoria que impede apagar avaliação que já tem histórico.

60 Hz

O servidor decide, o navegador só desenha.

Contexto: Jogo de futebol 2D multiplayer que roda no navegador, com partida rápida, treino offline e torre de duelos.
Restrição: Em jogo competitivo, cliente que calcula é cliente que trapaceia, e o mesmo código precisa rodar offline, sem servidor nenhum.
Decisão técnica: A simulação é determinística e vive num pacote próprio, separada do render. O servidor a executa e transmite estado, e o cliente apenas interpola. O modo offline roda essa mesma simulação dentro do navegador.
Resultado: No ar, com partida online, treino sem conta e duelo, com a lógica de jogo com uma fonte só, provada pelos dois modos ao mesmo tempo.