BMAD com Next.js: Como Criar um SaaS Completo

Galera, montar um SaaS do zero sempre foi aquele processo demorado. Weeks de planejamento, months de desenvolvimento, e no final, o MVP sai com metade das features que você queria. Com BMAD e Next.js juntos, a história muda completamente.

Eu usei esse combo pra criar um SaaS de gestão de agendamentos em 11 dias. Sozinho. Sem freelancer, sem time. O BMAD organizou o trabalho em sprints com agentes IA fazendo as funções de PO, Arquiteto, Dev e QA. O Next.js entrou como framework porque é o que tem melhor suporte de tooling e deploy automatizado hoje.

Neste artigo vou mostrar todo o processo: do setup inicial até o deploy na Vercel. Com exemplos reais, prompts que usei e os erros que cometi pra você não repetir. Se quiser entender a teoria por trás do BMAD primeiro, recomendo ler o artigo sobre agile coding com IA.

O que é BMAD e por que funciona com Next.js

Recap do workflow BMAD em 3 minutos

BMAD divide o desenvolvimento em papéis de agentes IA. Cada agente tem um prompt específico com persona, responsabilidades e regras. Você conversa com um agente por vez, e cada um produz um artefato que o próximo consome.

O fluxo é direto: o Product Owner gera o PRD (Product Requirements Document) com user stories e critérios de aceite. O Arquiteto lê o PRD e produz o Tech Spec com stack, estrutura e decisões técnicas. O Desenvolvedor lê os dois documentos e implementa. O QA revisa o código contra os critérios do PRD.

A sacada é que cada agente tem contexto limitado e objetivo claro. Em vez de pedir pra IA 'faz um SaaS inteiro', você pede 'como PO, analise esses requisitos e gere user stories'. A qualidade do output sobe muito quando o agente tem foco.

Por que Next.js é o framework ideal pra BMAD

Next.js casa perfeitamente com BMAD por três motivos. Primeiro: os agentes IA conhecem Next.js muito bem. É o framework React mais popular, com toneladas de exemplos nos dados de treinamento. O código gerado tende a ser correto de primeira.

Segundo: o App Router do Next.js 16 organiza o código por rotas e features, que é exatamente como o BMAD divide o trabalho. O agente Dev pode implementar uma feature inteira dentro de uma pasta sem mexer no resto do projeto.

Terceiro: deploy na Vercel é um git push. Sem configurar servidor, sem Docker, sem CI/CD manual. O agente Dev faz commit, push, e em 2 minutos tá no ar. Isso acelera o ciclo de feedback de dias pra minutos.

Setup do projeto: Next.js + Supabase + Agentes IA

Criando o repo e configurando o ambiente

O setup é rápido. Você cria o projeto Next.js, instala as dependências e configura a estrutura de pastas do BMAD. Em 15 minutos tá tudo pronto pra começar o primeiro sprint.

meu-saas/
├── CLAUDE.md              # Menu de agentes BMAD
├── agents/
│   ├── po.md              # Prompt do Product Owner
│   ├── arch.md            # Prompt do Arquiteto
│   ├── dev.md             # Prompt do Desenvolvedor
│   └── qa.md              # Prompt do QA
├── docs/
│   ├── prd.md             # Output do PO (requisitos)
│   ├── tech-spec.md       # Output do Arquiteto (stack + estrutura)
│   └── dev-log.md         # Log de decisões do Dev
├── src/
│   ├── app/               # Rotas Next.js (App Router)
│   ├── components/        # Componentes React
│   ├── lib/               # Utilitários e helpers
│   └── types/             # TypeScript types
├── supabase/              # Migrations e seed
└── package.json

Definindo os agentes BMAD no Cursor e Claude Code

O prompt de cada agente precisa ter três coisas: persona (quem ele é), responsabilidades (o que ele faz) e regras (o que ele não pode fazer). Sem isso, o agente vira um chatbot genérico que aceita qualquer coisa.

Aqui vai o template do CLAUDE.md que uso em todo projeto BMAD. No Cursor, o equivalente é o .cursorrules.

# Projeto: [Nome do SaaS]

## BMAD Workflow
Este projeto usa o método BMAD. Pergunte qual agente ativar.

## Ativar agentes
- `/po` → leia agents/po.md e aja como Product Owner
- `/arch` → leia agents/arch.md e aja como Arquiteto
- `/dev` → leia agents/dev.md e aja como Desenvolvedor
- `/qa` → leia agents/qa.md e aja como QA Engineer

## Stack decidida
- Next.js 16 (App Router, Server Components)
- Supabase (PostgreSQL + Auth + Storage)
- Tailwind CSS + shadcn/ui
- Vercel (deploy)

## Regras gerais
- TypeScript strict mode sempre
- Commits atômicos: um por feature
- Testes obrigatórios para lógica de negócio
- Sem TODO no código — implementa ou cria issue

Pro agente PO, o prompt foca em fazer perguntas antes de gerar stories. Pro Arquiteto, o foco é justificar cada decisão técnica. Pro Dev, é seguir os padrões definidos sem inventar. Pro QA, é ser rigoroso com edge cases. Se quiser se aprofundar em como escrever esses prompts, tem um guia completo de prompt engineering pra IDE.

Sprint 1 — Do PRD ao primeiro Epic com IA

Product Manager Agent: gerando requisitos

Você ativa o agente PO e descreve o que quer construir. No meu caso: 'Quero um SaaS de gestão de agendamentos para profissionais autônomos. O usuário cria horários disponíveis, clientes agendam online, e tem um dashboard com métricas.'

Um bom agente PO não aceita isso e sai escrevendo. Ele faz perguntas: Quantos serviços o profissional pode oferecer? Tem pagamento online ou só presencial? Precisa de notificação por email ou WhatsApp? Qual o nível de customização visual? Essas perguntas refinam os requisitos antes de virar código.

Depois das suas respostas, o PO gera o PRD com user stories priorizadas. As stories seguem o formato 'Como [persona], quero [ação] para que [benefício]' com critérios de aceite claros. Ele salva tudo em docs/prd.md.

# PRD: SaaS de Agendamentos

## Personas
- Profissional: cabeleireiro, dentista, personal trainer
- Cliente: pessoa que agenda horário online

## Epic 1: Autenticação e Onboarding
### US-01: Cadastro do profissional
Como profissional, quero me cadastrar com email/Google
para acessar o painel de gerenciamento.

Critérios de aceite:
- Login com email/senha e OAuth Google
- Após primeiro login, redireciona para setup do perfil
- Campos obrigatórios: nome, profissão, telefone

### US-02: Cadastro do cliente
Como cliente, quero agendar sem precisar criar conta
para que o processo seja rápido.

Critérios de aceite:
- Agendamento com nome + email + telefone (sem senha)
- Email de confirmação enviado automaticamente

Architect Agent: decidindo a stack

Com o PRD pronto, você ativa o Arquiteto. Ele lê docs/prd.md e propõe a stack técnica com justificativa pra cada decisão. Não é só 'use Supabase' — é 'use Supabase porque o PRD exige autenticação OAuth, real-time pra atualizar agenda e storage pra fotos de perfil. Tudo isso vem built-in no Supabase, sem precisar de 3 serviços diferentes.'

O Arquiteto também define a estrutura de componentes, os padrões de nomenclatura e o schema do banco de dados. Tudo isso vai pra docs/tech-spec.md e serve como referência pro agente Dev na hora de implementar.

Sprint 2 — Implementação guiada por agentes

Developer Agent: gerando código com contexto

Agora vem a parte boa. Ativa o Dev e manda: 'Implemente a US-01 (cadastro do profissional) conforme o PRD e Tech Spec.' O agente lê os dois documentos, entende os critérios de aceite e começa a codar.

No meu projeto, o agente Dev criou a rota de autenticação com Supabase Auth, configurou o OAuth do Google, criou o componente de login com shadcn/ui e implementou o redirect pra página de setup do perfil. Tudo em uma sessão de 40 minutos.

A diferença de pedir 'faz uma tela de login' vs pedir 'implementa a US-01 conforme o Tech Spec' é enorme. No segundo caso, o agente sabe exatamente qual provider usar (Supabase Auth), qual componente de UI (shadcn/ui Button + Input), e pra onde redirecionar (/onboarding). Zero ambiguidade.

// src/app/(auth)/login/page.tsx
// Gerado pelo agente Dev seguindo o Tech Spec
import { createClient } from '@/lib/supabase/server';
import { redirect } from 'next/navigation';
import { LoginForm } from '@/components/auth/login-form';

export default async function LoginPage() {
  const supabase = await createClient();
  const { data: { user } } = await supabase.auth.getUser();
  
  if (user) {
    // Verifica se já completou onboarding
    const { data: profile } = await supabase
      .from('profiles')
      .select('onboarding_completed')
      .eq('id', user.id)
      .single();
    
    if (profile?.onboarding_completed) {
      redirect('/dashboard');
    }
    redirect('/onboarding');
  }
  
  return <LoginForm />;
}

QA Agent: testes automatizados com IA

Depois que o Dev implementa a feature, você ativa o QA: 'Revise a implementação da US-01 contra os critérios de aceite do PRD.' O QA lê o código, compara com o PRD e reporta o que tá ok e o que precisa de ajuste.

No meu caso, o QA encontrou três problemas que o Dev não cobriu: não tinha tratamento pra quando o usuário cancela o OAuth no meio do fluxo, não tinha rate limiting no endpoint de login, e o redirect depois do login não preservava a URL original. Bugs que eu mesmo provavelmente não pegaria na revisão manual.

O QA também gera sugestões de testes automatizados. Não substitui escrever testes, mas dá um bom ponto de partida com os cenários mais importantes já mapeados.

Sprint 3 — Deploy e iteração

Deploy na Vercel com CI/CD

Deploy com Next.js na Vercel é a parte mais simples de todo o processo. Conecta o repo do GitHub, configura as variáveis de ambiente e pronto. Cada push na main dispara um deploy automático.

Uma dica que faz diferença: configure o preview deployment. Cada vez que o agente Dev cria uma branch com uma feature nova, a Vercel faz deploy num URL temporário. Você testa em produção real sem afetar o ambiente principal.

Feedback loop e brainstorm de features

Com o MVP no ar, o ciclo de feedback fica muito rápido. Usuário reporta um problema, você ativa o agente Dev, ele corrige, push, deploy automático. Em 10 minutos o fix tá em produção.

Pra novas features, o fluxo BMAD se repete: ativa o PO pra definir a story, Arquiteto pra avaliar impacto técnico, Dev pra implementar, QA pra revisar. O bom é que os agentes já têm todo o contexto do projeto nos docs anteriores. Cada sprint fica mais rápido que o anterior.

Resultado final: quanto tempo economizei

Vou ser honesto com os números. O projeto de agendamentos que normalmente levaria 6-8 semanas com um dev full-time ficou pronto em 11 dias. Trabalhei umas 5 horas por dia, então foram aproximadamente 55 horas de trabalho.

Sem BMAD, usando IA de forma desorganizada (só mandando prompts soltos), provavelmente levaria 3-4 semanas. A diferença do BMAD não é que ele faz a IA codar mais rápido — é que ele reduz o retrabalho. Como cada agente tem contexto claro e os artefatos são documentados, o código sai certo de primeira com muito mais frequência.

O custo de $47 em tokens pode parecer pouco, mas eu usei Claude Haiku pros agentes PO e QA (que são mais conversacionais e gastam menos) e Claude Sonnet só pro Dev e Arquiteto. Essa otimização corta o custo quase pela metade.

Erros que cometi e como evitar

Nem tudo foi perfeito. Cometi erros que atrasaram o projeto e quero que você não repita.

O erro mais caro foi pular o PRD. Parece perda de tempo gastar 30 minutos conversando com o agente PO quando você já sabe o que quer. Mas o PO faz perguntas que você não pensou. No meu caso, ele perguntou sobre fusos horários diferentes e cancelamento de agendamentos — duas features que eu ia esquecer e que seriam muito mais caras de adicionar depois.

FAQ

Perguntas que a galera sempre faz quando mostro esse workflow.

Preciso de experiência com Next.js pra usar BMAD?

Precisa ter noção. Não precisa ser expert, mas entender como rotas funcionam no App Router, o que é Server Component vs Client Component e como fazer deploy na Vercel é o mínimo. Se você sabe React básico e já fez um projeto pequeno com Next.js, tá pronto.

Dá pra usar BMAD com outro framework que não Next.js?

Com certeza. BMAD é agnóstico de framework. Funciona com Nuxt, Remix, SvelteKit, Rails, Django, whatever. Next.js é a minha recomendação porque os agentes IA geram código melhor pra ele (mais exemplos nos dados de treinamento) e o deploy é mais simples.

Quanto tempo leva pra configurar os agentes?

Primeira vez: 1-2 horas pra escrever os prompts e testar. A partir do segundo projeto, você reutiliza os prompts e ajusta em 15 minutos. Eu mantenho um repo template com os agentes prontos e copio pra cada projeto novo.

O código gerado é bom o suficiente pra produção?

Depende do que você chama de 'bom'. O código segue os padrões definidos no Tech Spec, trata erros básicos e funciona. Mas sempre precisa de revisão humana. O agente QA pega muita coisa, mas edge cases muito específicos do domínio ainda escapam. Pra MVP e v1, a qualidade é mais do que suficiente.