Estudo de caso database-first:o banco antes da tela

Neste estudo de caso database-first, desenhei o banco de dados inteiro antes de construir uma única tela — e, dezoito meses depois, com 1.000 tabelas e o produto ainda em desenvolvimento, o banco nunca precisou ser refeito. Nem uma vez. Este é o estudo de caso: quanto custaram aquelas primeiras semanas nada glamourosas e exatamente o que elas compraram.

O método em si — por que os seus dados precisam vir antes das suas telas — tem um post só dele: desenvolvimento database-first. Este aqui é a prova. É fácil concordar com um método e fácil abandoná-lo no instante em que você fica impaciente para ver algo na tela. Então aqui está o que realmente aconteceu quando apostei um produto inteiro em fazer primeiro a parte chata: o FIKR Space, hoje com 11 produtos integrados, todos apoiados numa base de dados desenhada antes de qualquer um deles existir.

Duas semanas e meia sem nada para mostrar

Fase um — uma semana mapeando domínios. Antes de uma única linha de código, listei todas as áreas que o sistema tocaria algum dia. Mais de 20 domínios no total, divididos em cinco grupos:

• Núcleo: organizações, usuários, equipes, permissões
• Produto: projetos, tarefas, objetivos, sprints
• Dinheiro: cap tables, rodadas de investimento, transações, valuations
• Plataforma: programas de aceleração, candidaturas, turmas, currículo
• Suporte: comentários, anexos, notificações, logs de atividade

Fase dois — uma semana desenhando cada tabela. Toda tabela recebeu a mesma espinha dorsal: qual organização é dona do registro, quem o criou e quando, quem o alterou por último e quando, e exclusões que escondem registros em vez de destruí-los. Em cima dessa espinha dorsal, cada domínio recebeu seus campos específicos e suas listas de status e tipos guardadas como dados editáveis — nunca fixas no código.

Fase três — três dias mapeando relacionamentos. Um mapa completo de como tudo se conecta: quais registros pertencem a quais, quais se ligam de muitos para muitos, quais — como comentários e anexos — podem se prender a qualquer coisa.

Total: cerca de duas semanas e meia. O banco de dados inteiro desenhado, tudo conectado — antes de existir uma tela. Para quem olhava de fora, eu não tinha construído nada. As pessoas achavam que eu estava louco: "Por que não começar a construir e ir descobrindo no caminho?" Porque eu não tinha tempo para reconstruir, nem dinheiro para desperdiçar, nem margem para erro. O banco de dados tinha que estar certo da primeira vez.

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 →

Estudo de caso database-first: o que essa base comprou

Aí o retorno começou — e nunca parou. Aqui está cada grande redesenho pelo qual o FIKR Space passou, e o que cada um exigiu do banco de dados:

Cinco reformulações de interface. Zero mudanças no banco de dados. As telas são janelas para os dados — eu podia recortar as janelas à vontade porque as paredes nunca se moveram. Essa assimetria é todo o argumento a favor do database-first: você pode redesenhar completamente a sua interface; não pode redesenhar completamente o seu banco de dados.

A base comprou mais duas coisas que dinheiro nenhum consegue adaptar depois. Primeiro, uma fonte única da verdade: o dashboard e a lista de tarefas nunca podem discordar, porque toda tela faz as mesmas perguntas às mesmas tabelas. Segundo, isolamento de clientes desde o primeiro dia: todo registro indica a organização dona dele, então os dados de um cliente não podem vazar para a conta de outro — e toda funcionalidade que adicionei desde então herdou essa proteção automaticamente.

Como eu poderia saber de antemão tudo de que precisaria?

Eu não sabia. Não conhecia cada tabela com antecedência — alguns domínios evoluíram e campos foram adicionados pelo caminho. Mas eu conhecia o sistema: uma plataforma multi-tenant para startups, investidores e aceleradoras, lidando com dinheiro de verdade, precisando de permissões complexas e trilhas de auditoria, com vários produtos compartilhando uma única base. Conhecer o sistema diz que tipos de tabela precisam existir — entidades, relacionamentos, tabelas de referência, logs de auditoria — mesmo antes de você conhecer cada campo. Quando surgiam novas necessidades, elas se encaixavam nos padrões existentes em vez de brigar com eles.

Essa é a metade do trabalho que cabe ao arquiteto — a divisão completa de papéis está em você é o arquiteto, a IA é a construtora. A IA gerou cada migration exatamente como eu especifiquei. Não tomou nenhuma decisão de arquitetura. Pura execução. E brigou com a disciplina o tempo todo: esquecendo a marcação da organização, pulando índices, propondo atalhos — os sinais de alerta estão catalogados em 11 sinais de que a IA está errada com toda a confiança.

O contrafactual: quanto custa pular essa etapa

Veja como seria a versão desta história começando pela interface. Semana um, você constrói um dashboard lindo e cria uma tabela para alimentá-lo. Semana dois, constrói uma lista de tarefas e cria outra tabela. Semana três, o dashboard diz 15 tarefas e a lista mostra 18 — porque agora você tem duas fontes da verdade, e ninguém sabe quando elas divergiram nem qual está certa.

Agora aumente a escala. Suponha que eu tivesse pulado o isolamento de clientes e precisasse adicioná-lo depois: todas as tabelas alteradas, todas as consultas reescritas, todas as regras de acesso criadas, todos os dados existentes migrados. Semanas de trabalho de alto risco mexendo em tudo ao mesmo tempo — o tipo de cirurgia que mata produtos solo. Como isso foi desenhado desde o primeiro dia, nunca houve nada para adaptar.

E o dinheiro? A conta inteira de ferramentas para construir tudo isso foi de R$ 19.500 — o detalhamento está em o stack de R$ 19.500. O insumo caro nunca foi dinheiro. Foi a disciplina de passar duas semanas e meia na fundação enquanto não havia nada para demonstrar. Centenas de funcionalidades depois, todas se encaixando, esse continua sendo o investimento de maior retorno que já fiz num produto.

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

Perguntas frequentes

Por que desenhar o banco de dados inteiro antes de qualquer interface?

Porque a interface pode mudar e o banco de dados não — pelo menos não de forma barata. As telas são janelas para os dados; redesenhe-as quantas vezes quiser. Mas reestruturar os dados por baixo de um produto no ar significa mexer em todas as funcionalidades ao mesmo tempo. Acerte a base e tudo o que for construído sobre ela continua de pé.

Quanto tempo levou para desenhar o banco de dados inteiro?

Cerca de duas semanas e meia: uma semana mapeando mais de 20 domínios, uma semana desenhando cada tabela com uma espinha dorsal comum e três dias mapeando os relacionamentos entre elas. Esse é o preço total da base — comparado a dezoito meses de construção sem nenhuma reconstrução.

O banco de dados precisou ser refeito alguma vez?

Não. Nem uma vez em dezoito meses. Campos foram adicionados e alguns domínios evoluíram, mas sempre dentro dos padrões existentes. Cinco redesenhos completos de interface — dashboard, navegação, layout, estilo, celular — não exigiram nenhuma mudança no banco de dados.

Meu produto precisa de um banco de dados desse tamanho?

Não. O tamanho reflete 11 produtos integrados compartilhando uma única base. O princípio funciona em qualquer escala: liste cada entidade do seu sistema, mapeie como elas se relacionam, desenhe tudo antes de construir as telas. A disciplina é a mesma, quer o seu produto precise de uma dúzia de tabelas ou de centenas.