Por Que Construtores de Apps com IA Precisam de Bancos de Dados Reais, Não Mock Data

Resposta rápida

Muitos construtores de apps com IA geram uma interface conectada a um arquivo JSON ou a um array em memória em vez de um banco de dados real, porque isso demonstra bem e sai em minutos. O problema aparece depois: sem relacionamentos, sem migrations, sem row-level security, sem forma de lidar com duas pessoas escrevendo ao mesmo tempo. Construir sobre um schema real com Postgres desde o primeiro prompt custa quase nada a mais e evita a reescrita inteira.

Por que um backend falso demonstra tão bem?

Abra dez construtores de apps "gerados por IA", digite o mesmo prompt em cada um, e pelo menos metade vai te entregar um dashboard com cara de pronto em menos de um minuto. Clique, adicione uma linha, atualize a página --- ela ainda está lá. Parece resolvido.

Olhe mais de perto e essa linha estava, o tempo todo, dentro de um array em JavaScript, ou de um arquivo data.json empacotado junto com o frontend. Atualize a partir de outro navegador e ela some, porque nunca existiu um banco de dados --- só um script fingindo ser um pelo tempo de uma demo. Isso não é uma crítica à ideia em si; uma camada mock é, de fato, o jeito mais rápido de colocar pixels na tela. O problema é que a maioria dos construtores nunca conta qual dos dois você recebeu, e os fundadores descobrem do jeito difícil, geralmente na semana em que tentam trazer um segundo usuário real.

O que o mock data esconde de você, na prática?

Aqui está a parte que ninguém diz em voz alta o suficiente: um schema é uma decisão, e o mock data deixa você pular essa decisão. Um array de users com um campo favoriteColor parece um modelo de dados real. Não é --- é um formato, não uma estrutura. Não existe chave estrangeira ligando um pedido a um cliente, nenhuma constraint impedindo um e-mail duplicado, nenhum índice mantendo uma busca rápida assim que você passa de quarenta registros.

Já vi fundadores apresentarem um app para investidores em cima de uma camada mock, conseguirem o investimento, e só depois pedirem para um engenheiro "conectar isso a um banco de dados de verdade" --- como se fosse uma mudança de configuração. Não é. É redesenhar o modelo de dados do zero, porque o mock nunca forçou ninguém a responder perguntas como: um cliente pertence a uma empresa só, ou a várias? O que acontece com os pedidos dele se a empresa for excluída? Essas perguntas são baratas de responder no dia um e caras de responder depois que 200 registros de clientes já violam qualquer resposta que você acabe escolhendo.

A pergunta do schema sempre acaba sendo feita

Só que quem faz é a produção, não você. E produção não pergunta com educação --- ela pergunta na forma de um chamado de suporte, um registro corrompido, ou um cliente bem confuso cujos dados sumiram porque alguém do time dele salvou primeiro.

O que quebra primeiro quando você finalmente troca para um banco de dados real?

Quase nunca as partes com que as pessoas se preocupam. Raramente é a sintaxe SQL ou a configuração do ORM. Quatro coisas quebram, mais ou menos nessa ordem:

Relacionamentos. Um array mock não tem noção de chave estrangeira, então nada garantia que todo order.customerId de fato apontava para um cliente real. Migre esses dados para o Postgres e você vai encontrar registros órfãos que nem sabia que existiam.

Migrations. Mock data não tem versão de schema --- você só edita o formato do array e recarrega. Um banco de dados real precisa que toda mudança seja expressa como uma migration que rode com segurança sobre linhas que já existem. Adicionar uma coluna NOT NULL numa tabela com 4.000 linhas ativas exige um valor padrão ou um passo de backfill, não uma edição na velocidade de protótipo.

Row-level security. Numa demo, "o usuário A consegue ver os dados do usuário B" nunca foi uma pergunta real, porque não havia uma camada de persistência de onde vazar. No momento em que você tem contas de verdade, precisa de políticas de RLS ou de queries que respeitem a autenticação, aplicadas no banco de dados --- não só escondidas na interface, porque um botão escondido não é uma barreira de segurança.

Escritas concorrentes. Essa é a que ninguém simula, porque simular exige duas pessoas usando o app ao mesmo tempo, e uma demo tem exatamente um usuário: você. Um produto real tem um vendedor e um cliente editando o mesmo negócio no mesmo minuto, ou um retry de webhook escrevendo numa linha que seu app também está atualizando. Sem transactions e locking adequados, uma dessas escritas simplesmente some em silêncio.

Backend real desde o dia um vs. encaixar um depois

Pular o banco de dados real não deixa a primeira versão mais rápida?

Quase nada, e só por mais ou menos um dia. Estruturar um schema Postgres com tipos, relacionamentos e autenticação corretos não é mais lento do que escrever um formato JSON mock, quando o construtor gera os dois a partir da mesma descrição em português claro --- o custo extra é bem mais próximo de zero do que as pessoas imaginam, porque a IA está modelando os dados de qualquer forma. O que sai caro não é construir sobre um schema real desde o início. É construir sobre um falso e depois pagar por isso duas vezes: uma pelo mock, outra pela versão real que você vai precisar de qualquer jeito.

Esse é o argumento real por trás de a Greta gerar apps sobre Supabase e Prisma desde o primeiro prompt, em vez de uma camada descartável. Quando você descreve um CRM ou um app de agendamento, a Greta estrutura o schema, os relacionamentos e as queries com autenticação como Postgres real desde o começo --- o mesmo app que você demonstra hoje é o que você escala amanhã, não um protótipo que você troca em silêncio depois. Se você está comparando isso com ferramentas feitas para mockups rápidos de interface, Greta vs. Lovable mostra onde esse teto aparece na prática, e o lado de webhooks e APIs de terceiros de um backend real vale a leitura assim que você for conectar o Stripe ou o Twilio.

FAQ

Mock data não serve bem para um protótipo que ninguém ainda está pagando? Para uma demo de pitch descartável que você vai apagar em uma semana, tudo bem. O problema é que a maioria dos "protótipos" silenciosamente vira o produto no momento em que alguém diz sim, e ninguém agenda a reescrita com antecedência.

Qual é a primeira coisa que realmente quebra com mock data? Geralmente, um segundo usuário. Uma pessoa editando os próprios registros quase nunca expõe relacionamentos faltando ou conflitos de escrita --- um segundo usuário concorrente expõe os dois quase imediatamente.

Usar um banco de dados real desde o início deixa a construção do MVP mais lenta? Não de forma relevante, quando a ferramenta que gera seu app constrói a interface e o schema a partir da mesma descrição. Você perde quase nada no início e evita uma reescrita completa da camada de dados depois.

Row-level security é exagero para um app pequeno? Não, se ele guarda dados de mais de uma pessoa. No momento em que duas contas existem, algo precisa garantir que a conta A não consiga ler as linhas da conta B --- e um elemento escondido na interface não conta.

Encerramento

Mock data não é o vilão --- é só uma decisão que precisa de um rótulo. Se uma ferramenta te entrega uma demo em cima de uma camada de dados falsa, tudo bem, contanto que você saiba o que está recebendo e quanto vai custar sair dali depois. O caminho mais barato é começar pelo backend de verdade, porque um banco de dados real custa quase nada a mais no dia um e poupa a reescrita inteira no dia noventa.

Comece a construir seu app com a Greta hoje.