Desenvolvimento database-first:desenhe antes do prompt

Desenvolvimento database-first é desenhar seu banco de dados antes de escrever uma única linha de código da aplicação. As duas semanas que você passa desenhando o sistema antes de construí-lo vão te poupar dois meses de refatoração durante a construção. Isso não é uma hipótese — é um problema de matemática comprovado em todo código que já vi, incluindo o meu.

As duas semanas mais importantes da construção do FIKR Space foram as duas semanas que passei desenhando o esquema do banco de dados antes de escrever qualquer código da aplicação. A maioria das pessoas concorda com essa frase e depois a ignora. Esta é a versão prática: as três coisas que "desenhar a arquitetura" realmente significa, e o cronograma de construção que vem depois que você faz isso.

Desenvolvimento database-first: por que a tentação é a armadilha

Você vai sentir a tentação, no momento em que terminar a validação, de abrir o Claude ou o Cursor e começar a construir. Vai querer a dopamina do código se acumulando. Vai querer mostrar um print para seu cônjuge no fim do fim de semana. Resista.

Começar a programar antes de desenhar o banco de dados é o erro-mestre — todas as outras armadilhas da construção vêm depois dele. Você se sente produtivo no primeiro dia porque a IA está gerando telas, mas a fundação por baixo delas é fluida, e a cada semana que a fundação se mexe, tudo o que foi construído em cima precisa ser refeito. Esse ciclo de retrabalho cada vez mais rápido é exatamente como a armadilha do vibe coding se fecha em torno de pessoas que se sentiam imparáveis na primeira semana.

Passo 1: desenhe o banco de dados — no papel

Liste todas as entidades do seu produto. Usuários. Empresas. Assinaturas. Quaisquer que sejam os substantivos centrais. Depois liste as relações: um usuário pertence a uma empresa, uma empresa tem muitos usuários, uma assinatura pertence a uma empresa e registra o uso.

Desenhe isso no papel. Sim, papel. O ato de desenhar te faz pensar em situações que você deixaria passar num desenho só de cabeça. Quando as caixas e setas param de mudar, você tem um esquema. Aí descreva as entidades com clareza para o Claude, e ele escreve o SQL de verdade para você em vinte minutos. Agora você tem sua fundação.

Passo 2: defina os limites dos serviços

Quais são as principais operações que seu sistema executa? Cadastrar. Processar um pagamento. Gerar um relatório. Enviar uma notificação. Cada uma delas é um serviço — uma parte autocontida do sistema com uma função definida. Defina as entradas e saídas de cada serviço antes de escrevê-lo.

Parece burocrático. Não é. É a diferença entre um sistema que consegue evoluir e um sistema que calcifica depois de três meses.

Passo 3: percorra os fluxos do usuário

Percorra as três coisas mais importantes que um usuário vai fazer com seu produto: cadastrar-se, concluir a primeira ação de valor, renovar a assinatura. Esboce cada fluxo como uma sequência de telas ou interações — não desenhe as telas ainda, só a sequência. Você está caçando os pontos onde o fluxo quebra, ou onde você supôs algo que não vai ser verdade.

Quando o banco de dados, os serviços e os fluxos fazem sentido no papel — e continuam fazendo sentido depois que você os olha com olhos descansados um dia depois —, você tem uma arquitetura. Agora pode construir.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

O cronograma de oito semanas que vem depois

Arquitetura primeiro não é mais lento. É o que faz a parte rápida ser rápida. Este é o cronograma que ela destrava, com quatro a oito horas por semana de construção focada:

Ao final da sexta semana, o produto tem seus três ou quatro fluxos centrais funcionando: cadastrar-se, fazer a coisa principal, ser cobrado, voltar amanhã e fazer de novo. Isso é o que uma pessoa consegue fazer em 2026 e que dez pessoas não conseguiam fazer em 2020 por dinheiro nenhum — e cada uma dessas funcionalidades semanais começa com um briefing escrito, não com um prompt esperançoso. Esse é o método PRP, e ele só funciona porque a arquitetura por baixo parou de se mexer.

Não deixe a IA ser a arquiteta

O Claude é um implementador brilhante e um arquiteto medíocre. Pergunte "isso deve ser uma tabela separada ou uma coluna JSON?" e ele vai te dar uma resposta — normalmente boa, às vezes ruim, de vez em quando ótima. O problema é que você não tem como avaliar em qual caso está, a menos que tenha seu próprio gosto arquitetural. Desenvolva-o de propósito: veja como outros produtos estruturam seus sistemas, trabalhe os trade-offs no papel e escreva a arquitetura antes de pedir ao Claude que a implemente.

As decisões de arquitetura são suas. As decisões de implementação são do Claude. Mantenha essa fronteira e a qualidade do código se acumula; borre-a e o código se deteriora.

Se você está nessa fase agora, esta é a sua semana: passe três noites nas entidades e relações. Desenhe o esquema no papel. Refine. Peça ao Claude que gere o SQL. Confira a consistência percorrendo seus três fluxos de usuário mais importantes e vendo se o esquema os suporta de forma limpa. Não escreva código da aplicação ainda. No domingo à noite, você terá um esquema em que confia e uma lista das quatro a seis funcionalidades centrais que vai construir nas próximas seis semanas. Chato. Lento. Vale cada hora.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Perguntas frequentes

O que é desenvolvimento database-first?

Construir o modelo de dados antes de qualquer código de aplicação: liste as entidades e relações do seu produto, refine-as no papel até pararem de mudar e só então gere o esquema e comece a construir funcionalidades. O banco de dados é a fundação — todo o resto é construído em cima dele, então ele precisa parar de se mexer primeiro.

Quanto tempo devo passar na arquitetura antes de programar?

Duas semanas — banco de dados, limites dos serviços e fluxos do usuário. Essas duas semanas te poupam dois meses de refatoração durante a construção, porque funcionalidades construídas sobre uma fundação estável não precisam ser refeitas toda vez que a fundação se mexe.

A IA pode desenhar meu banco de dados por mim?

A IA pode escrever o esquema — descreva suas entidades com clareza e o Claude produz o SQL em vinte minutos. Mas ela não deve tomar as decisões de desenho. O Claude é um implementador brilhante e um arquiteto medíocre: as entidades, as relações e os trade-offs são decisões suas, a tomar antes do prompt.

Não sou técnico — consigo mesmo desenhar um esquema?

Sim, porque a parte difícil não é técnica. É listar os substantivos do seu negócio — usuários, empresas, assinaturas — e como eles se relacionam, e isso você conhece melhor do que qualquer desenvolvedor. Caixas e setas no papel. Quando elas param de mudar, o desenho está pronto e a IA cuida da tradução para SQL.