Desenvolvimento database-first:desenha antes do prompt

Desenvolvimento database-first é desenhar a tua base de dados antes de escreveres uma única linha de código da aplicação. As duas semanas que passas a desenhar o sistema antes de o construíres poupam-te dois meses de refactoring durante a construção. Isto não é uma hipótese — é um problema de matemática que se comprovou em todas as bases de código que alguma vez vi, incluindo a minha.

As duas semanas mais importantes da construção do FIKR Space foram as duas semanas que passei a desenhar o esquema da base de dados antes de escrever qualquer código da aplicação. A maioria das pessoas concorda com esta frase e depois ignora-a. Esta é a versão prática: as três coisas que "desenhar a arquitetura" quer realmente dizer e o calendário de construção que se segue quando já o fizeste.

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

Vais ter a tentação, no momento em que terminares a validação, de abrir o Claude ou o Cursor e começar a construir. Vais querer a dopamina de ver o código a acumular-se. Vais querer mostrar uma captura de ecrã ao teu companheiro ou companheira no fim do fim de semana. Resiste.

Começar a programar antes de a base de dados estar desenhada é o erro-mãe — todas as outras armadilhas da construção vêm a jusante dele. Sentes-te produtivo no primeiro dia porque a IA está a gerar ecrãs, mas a fundação por baixo deles é fluida, e cada semana em que a fundação mexe obriga a refazer tudo o que foi construído por cima. Esse ciclo de retrabalho cada vez mais rápido é exatamente a forma como a armadilha do vibe coding se fecha sobre pessoas que se sentiam imparáveis na primeira semana.

Passo 1: desenha a base de dados — em papel

Lista todas as entidades do teu produto. Utilizadores. Empresas. Subscrições. Sejam quais forem os substantivos centrais. Depois lista as relações: um utilizador pertence a uma empresa, uma empresa tem muitos utilizadores, uma subscrição pertence a uma empresa e regista a utilização.

Desenha isto em papel. Sim, papel. O ato de desenhar obriga-te a pensar em casos-limite que te escapariam num desenho feito só de cabeça. Quando as caixas e as setas deixarem de mudar, tens um esquema. Depois descreve as entidades com clareza ao Claude, e ele escreve-te o SQL em vinte minutos. Agora tens a tua fundação.

Passo 2: define as fronteiras dos serviços

Quais são as grandes operações que o teu sistema executa? Registo. Processar um pagamento. Gerar um relatório. Enviar uma notificação. Cada uma delas é um serviço — uma peça autónoma do sistema com uma função definida. Define as entradas e saídas de cada serviço antes de escreveres o serviço.

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

Passo 3: percorre os fluxos de utilizador

Percorre as três coisas mais importantes que um utilizador vai fazer com o teu produto: registar-se, concluir a primeira ação com valor, renovar a subscrição. Esboça cada fluxo como uma sequência de ecrãs ou interações — não desenhes ainda os ecrãs, só a sequência. Estás à procura dos sítios onde o fluxo se parte, ou onde assumiste algo que não vai ser verdade.

Quando a base de dados, os serviços e os fluxos fizerem todos sentido em papel — e continuarem a fazer sentido depois de os olhares com olhos frescos um dia depois — tens uma arquitetura. Agora podes construir.

O livroThe Solopreneur RevolutionLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem deixar o emprego.Quero o livro →

O calendário de oito semanas que se segue

Começar pela arquitetura não é mais lento. É o que torna rápida a parte rápida. Eis o calendário que desbloqueia, com quatro a oito horas por semana de construção focada:

No fim da semana seis, o produto tem os seus três ou quatro fluxos centrais a funcionar: registar-se, fazer a coisa principal, ser cobrado, voltar amanhã e fazê-la outra vez. Isto é o que uma pessoa consegue fazer em 2026 que dez pessoas não conseguiam fazer em 2020 por dinheiro nenhum — e cada uma dessas funcionalidades semanais começa com uma especificação escrita, não com um prompt esperançoso. Esse é o método PRP, e só funciona porque a arquitetura por baixo dele deixou de mexer.

Não deixes a IA ser a arquiteta

O Claude é um executor brilhante e um arquiteto medíocre. Pergunta-lhe "isto deve ser uma tabela separada ou uma coluna JSON?" e ele dá-te uma resposta — normalmente aceitável, às vezes má, de vez em quando ótima. O problema é que não tens forma de avaliar em que caso estás, a não ser que tenhas o teu próprio gosto arquitetónico. Desenvolve-o deliberadamente: vê como outros produtos estruturam os seus sistemas, trabalha os compromissos em papel e escreve a arquitetura antes de pedires ao Claude que a implemente.

As decisões de arquitetura são tuas. As decisões de implementação são do Claude. Mantém essa fronteira e a qualidade da base de código acumula-se; esbate-a e a base de código degrada-se.

Se estás nesta fase agora, eis a semana: passa três serões com as entidades e as relações. Desenha o esquema em papel. Afina-o. Pede ao Claude que gere o SQL. Confirma se faz sentido percorrendo os teus três fluxos de utilizador mais importantes e vendo se o esquema os suporta de forma limpa. Ainda não escrevas código da aplicação. No domingo à noite, tens um esquema em que confias e uma lista das quatro a seis funcionalidades centrais que vais construir nas seis semanas seguintes. Aborrecido. Lento. Vale cada hora.

12 semanasA tua carreira corporativa nunca foi o planoCandidata-te ao Solopreneur Accelerator.Candidatar-me →

Perguntas frequentes

O que é o desenvolvimento database-first?

Construir o modelo de dados antes de qualquer código da aplicação: listar as entidades e relações do teu produto, afiná-las em papel até deixarem de mudar e só então gerar o esquema e começar a construir funcionalidades. A base de dados é a fundação — tudo o resto é construído por cima dela, por isso tem de deixar de mexer primeiro.

Quanto tempo devo passar na arquitetura antes de programar?

Duas semanas — base de dados, fronteiras dos serviços e fluxos de utilizador. Essas duas semanas poupam-te dois meses de refactoring durante a construção, porque funcionalidades construídas sobre uma fundação estável não precisam de ser refeitas cada vez que a fundação mexe.

A IA pode desenhar a minha base de dados por mim?

A IA pode escrever o esquema — descreve as tuas entidades com clareza e o Claude produz o SQL em vinte minutos. Mas não deve tomar as decisões de desenho. O Claude é um executor brilhante e um arquiteto medíocre: as entidades, as relações e os compromissos são decisões tuas, a tomar antes de escreveres o 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 teu negócio — utilizadores, empresas, subscrições — e como se relacionam, coisa que conheces melhor do que qualquer programador. Caixas e setas em papel. Quando deixarem de mudar, o desenho está feito e a IA trata da tradução para SQL.