Do protótipo à produção
Você entregou o mockup com IA.
Agora entregue a coisa de verdade — numa base que não vaza.
Seu agente te levou aos 80% numa velocidade que pareceu quase injusta. Os últimos 20% — auth real, pagamentos, segurança, multi-tenant — é onde os apps vibe-coded quebram e vazam. Aqui já está construído e blindado.
Os últimos 20% é onde o demo vira um passivo
"That last 20% — the part that makes your SaaS actually ready for paying customers — takes 80% of the effort, and that last 20% is where vibe coding starts to struggle." (Infinity Sky AI) O demo que você vê é uma fatia pequena de um app real. Os 80% invisíveis — tratamento de erros, segurança, idempotência, manter um usuário fora dos dados de outro — é exatamente do que um cliente pagante depende, e exatamente o que um agente entrega inseguro por default.
O penhasco técnico, em histórias reais
Uma key do Stripe no frontend
"user list was leaked on the FE... the hacker got a hold of his Stripe key and issued every customer a refund. Now he's hiring a developer to shore it up." — Hacker News (item 44739556)
170 apps vazando pela mesma falha
Um scan encontrou 170+ apps vibe-coded com bancos de dados totalmente expostos e API keys hardcoded visíveis no bundle do navegador. O builder não técnico nunca soube que row-level security existia. (relatório de segurança da vibe-eval.com, fev 2026)
A parte que ninguém pediu
"AI does what you ask. It just never thinks about what you didn't ask." — web developer, r/VibeCodeDevs (161 upvotes)
As partes chatas e perigosas — já resolvidas e blindadas
Auth
Login real com 2FA, magic-link, OAuth, verificação de email e password reset, via BetterAuth. Você reseta a senha e as sessões antigas param de funcionar.
Pagamentos
Stripe, MercadoPago ou Polar — checkout, customer portal, mudanças de plano, pagamentos falhos e webhooks assinados que não cobram duas vezes.
Segurança e isolamento
Os secrets vivem no server, nunca no bundle do navegador. Um tenant-isolation guard garante que um cliente jamais consiga ler os dados de outro.
Papéis que significam algo
"admin" e "member" são checados no server, não só escondidos na UI — então uma request modificada não consegue se autopromover.
Aponte seu agente pra cá, não pra uma pasta vazia
Uma pasta vazia obriga seu agente a inventar a arquitetura — e do zero ele repete os mesmos três bugs de segurança toda vez: sessões que sobrevivem a um password reset, webhooks que cobram duas vezes, e dados que vazam entre usuários. Começar de uma base com paredes que ele não consegue cruzar significa que ele gasta o esforço dele na sua ideia, não em rederivar auth e billing e errar de forma sutil.
Não um substituto do seu builder — o lugar pra onde você se gradua
Continue rascunhando ideias no Lovable, Bolt ou v0 — eles são ótimos pra isso. Aqui é pra onde você se muda no momento em que tem usuários reais, pagamentos reais e auth que protege os dados de outras pessoas. Você ainda roda um repo e seu agente; só aponta ele pra uma base que já cuidou das partes chatas e perigosas.
O que você tem no dia um
Um dashboard funcionando
UI de conta, settings e as superfícies que um usuário logado espera — já construídas.
Organizações e admin
Times, convites de membros, um painel de admin e papéis — a espinha multi-tenant.
Um portal de billing
Os clientes gerenciam a própria assinatura — upgrade, downgrade, cancelar — sem te mandar email.
Email e jobs
Email transacional e background jobs ligados e prontos pra enviar e rodar.
Deploy de um comando
Entregue no Docker ou Railway com defaults opinados — sem diploma de DevOps.
Docs em 3 idiomas
Guias de setup passo a passo em inglês, espanhol e português.
Respostas diretas antes de se comprometer
Não sou dev sênior. Consigo rodar isso de verdade?+
Vou ter que reconstruir depois?+
Meu app vibe-coded é inseguro só por azar?+
E se eu já tiver usuários no meu protótipo?+
Entregue a coisa de verdade, não só o mockup.
A segurança que sua IA não escreveu — já construída, testada no CI, e a base que você não vai precisar reconstruir.