Apps de IA com Backend e Base de Dados Reais: O Guia Completo (2026)

Que construtores de apps com IA criam um backend real — e o que conta como "real"?

Resposta curta: um backend real significa dados persistentes em PostgreSQL, autenticação server-side e APIs REST que impõem regras no servidor — não um frontend React bonito em que o formulário de login não autentica ninguém e os gráficos do dashboard renderizam JSON hardcoded. A maioria dos construtores de apps com IA gera a segunda coisa. O VULK (o nosso produto — disclosure abaixo) gera e faz deploy da primeira: quando o teu prompt descreve contas, dados guardados ou papéis de administrador, provisiona um backend real automaticamente — schema PostgreSQL, endpoints CRUD, auth JWT com papéis — ao lado do frontend, tudo ligado e com deploy feito. O Lovable e o Bolt seguem uma rota diferente e legítima: delegam o backend no Supabase, que funciona bem mas implica operar uma segunda plataforma. As ferramentas frontend-first deixam-te construir sozinho os 60% difíceis.

A procura não é um caso raro: 62% de todas as apps geradas no VULK incluem um schema SQL (dados da plataforma VULK, julho de 2026, sobre 11.355 apps geradas) — a maioria das pessoas que pede uma "app" está a descrever algo com utilizadores e dados, quer se aperceba quer não. Este guia cobre tudo: os quatro testes de um backend real, como funciona o provisionamento automático, como são realmente o schema e a auth gerados, padrões de segurança, deploy, seis prompts completos prontos a copiar, e — a parte que os vendedores resmoneiam — a história honesta de exportação e portabilidade, incluindo a nossa. Disclosure: o VULK é o nosso produto. Atualizado a 17 de julho de 2026.

Tabela comparativa: como os construtores de IA tratam o backend

Três arquiteturas escondem-se por trás do rótulo "construtor de IA full-stack". Gerado (VULK, Databutton): a IA escreve o teu schema, endpoints e auth como parte da app — o mais integrado, e estás a confiar em código de servidor gerado (é inspecionável; inspeciona-o). Delegado (Lovable, Bolt → Supabase): a ferramenta liga o teu frontend a um BaaS gerido — excelente DX e portabilidade de dados limpa, mas operas duas plataformas e herdas a forma do BaaS. Embebido (Base44): zero configuração, zero saída. Nenhuma está errada; falham de maneiras diferentes à medida que cresces. Preços verificados a 17 de julho de 2026.

O que falta realmente às apps de IA só-frontend?

Passa qualquer demo de "construtor de apps com IA" por quatro testes:

1. Persistência: crias dados, fazes redeploy — ainda lá estão? Apps de dados fictícios fazem reset. Apps de localStorage mantêm os dados reféns de um browser.
2. Auth real: o formulário de login verifica credenciais num servidor e emite uma sessão? "Auth" client-side é decoração — qualquer pessoa abre as DevTools e passa ao lado.
3. Regras impostas no servidor: o utilizador A consegue ler os registos do utilizador B mudando um ID no pedido? Se a validação só vive no React, a resposta é sim.
4. Dados inspecionáveis: consegues correr SQL contra a tua própria base de dados?

Chumba nesses testes e tens um protótipo — genuinamente útil para validar uma ideia, e é aí que ferramentas como o v0 brilham. Mas a distância entre esse protótipo e um produto é precisamente o backend: contas, papéis, validação, relações, migrações. É a parte que historicamente consumia a maior parte do tempo de engenharia, e é a parte de que 62% das gerações do VULK acabam por precisar (dados da plataforma VULK, julho de 2026).

Como é que o VULK provisiona um backend automaticamente?

Nunca dizes "adiciona um backend". A deteção lê o teu prompt à procura de sinais:

• Sinais de auth — "login", "registo", "contas de utilizador", "painel de administração", "papéis": disparam o sistema de auth.
• Sinais de persistência — "guardar", "armazenar", "histórico", "registos", "base de dados": disparam a geração de schema + CRUD.
• Sinais de API — "endpoint", "REST", "webhook": disparam a geração de rotas.

A deteção é deliberadamente conservadora — uma landing page ou um portefólio continua a ser um frontend estático rápido; um prompt com "os utilizadores podem publicar anúncios e enviar mensagens aos vendedores" recebe a stack completa. Quando dispara, uma única geração produz quatro camadas coordenadas:

1. Schema PostgreSQL — tabelas, tipos, constraints, chaves estrangeiras, índices, derivados das entidades do teu prompt.
2. API REST — CRUD completo por entidade com validação, paginação e códigos de estado corretos, com deploy no motor de API do VULK.
3. Sistema de auth — endpoints de registo e login, hashing de passwords com bcrypt, emissão de JWT, middleware a proteger rotas privadas, verificações de papéis quando o teu prompt implica papéis.
4. Frontend ligado — a app React é gerada contra esta API: as chamadas fetch apontam para endpoints reais, os tokens anexam-se aos pedidos, os estados de loading e erro existem. O formulário de login inicia mesmo a sessão. Esta última camada é o que separa "gerou um backend" de "gerou duas metades que tens o prazer de integrar sozinho".

O editor dá-te depois um painel de Backend: navega por tabelas e linhas, corre SQL puro num query runner, testa endpoints com um API tester e exporta qualquer tabela para CSV. Os teus dados nunca estão atrás de uma cortina.

Como é o schema SQL gerado?

A qualidade do schema decide a qualidade da aplicação, por isso a geração impõe os padrões que um engenheiro de bases de dados cuidadoso usaria. Para "um gestor de tarefas onde os utilizadores criam projetos e adicionam tarefas; os utilizadores só veem os seus próprios projetos":

CREATE TABLE users (
  id            SERIAL PRIMARY KEY,
  email         VARCHAR(255) UNIQUE NOT NULL,
  password_hash VARCHAR(255) NOT NULL,
  name          VARCHAR(120) NOT NULL,
  role          VARCHAR(20) NOT NULL DEFAULT 'member',
  created_at    TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at    TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE projects (
  id         SERIAL PRIMARY KEY,
  user_id    INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
  name       VARCHAR(160) NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE TABLE tasks (
  id          SERIAL PRIMARY KEY,
  project_id  INTEGER NOT NULL REFERENCES projects(id) ON DELETE CASCADE,
  title       VARCHAR(200) NOT NULL,
  description TEXT,
  priority    VARCHAR(10) NOT NULL DEFAULT 'medium'
              CHECK (priority IN ('low','medium','high')),
  status      VARCHAR(12) NOT NULL DEFAULT 'open'
              CHECK (status IN ('open','in_progress','done')),
  due_date    DATE,
  created_at  TIMESTAMPTZ NOT NULL DEFAULT now(),
  updated_at  TIMESTAMPTZ NOT NULL DEFAULT now()
);

CREATE INDEX idx_projects_user_id ON projects(user_id);
CREATE INDEX idx_tasks_project_id ON tasks(project_id);
CREATE INDEX idx_users_email ON users(email);

As escolhas deliberadas, cada uma delas uma falha comum em código gerado ingénuo:

• password_hash, nunca password. O próprio nome da coluna torna impossível escrever armazenamento em texto simples por acidente — uma regra imposta ao nível do prompt engineering.
• Chaves estrangeiras com comportamento de delete intencional — ON DELETE CASCADE onde os filhos não devem sobreviver aos pais; SET NULL onde os órfãos devem sobreviver (produtos que sobrevivem a uma categoria apagada).
• Constraints CHECK para valores limitados — um estado de tarefa não pode tornar-se silenciosamente "donee".
• Índices que correspondem aos padrões de query — chaves estrangeiras, email de lookup no login, colunas de ordenação.
• Timestamps em todas as tabelas. Aborrecido até precisares deles; depois, crítico.

Porquê PostgreSQL e não MongoDB ou Firebase? Porque as apps que as pessoas pedem são esmagadoramente relacionais — encomendas contêm itens, tarefas pertencem a projetos, projetos pertencem a utilizadores — e chaves estrangeiras com constraints exprimem isso com garantias de integridade que os documentos não conseguem dar. E porque uma dependência de um BaaS de terceiros quebraria o "um prompt, uma app funcional com deploy" com a criação de conta numa segunda plataforma. O Postgres é o que escolherias à mão para produção, por isso é o que é gerado.

Como funciona a autenticação gerada?

O fluxo de auth completo, construído como deve ser, porque a auth é a camada onde os atalhos gerados se tornam violações de segurança:

• POST /api/auth/register — valida o input, faz hash da password com bcrypt (nunca texto simples, nunca reversível), guarda em password_hash, devolve um JWT.
• POST /api/auth/login — compara o hash bcrypt, emite um JWT assinado em caso de sucesso. Mesmo erro para email errado e password errada (sem enumeração de contas).
• Middleware em todas as rotas protegidas verifica o JWT server-side; o frontend anexa-o automaticamente.
• Propriedade ao nível da linha nas queries — WHERE user_id = $1 a partir do token verificado, para que mudar um ID no URL não leia as linhas de outra pessoa.
• Papéis quando pedidos ("o admin pode gerir produtos") — uma coluna role verificada no middleware, endpoints só-admin e UI condicional a condizer.

Ao lado da auth, os defaults de segurança não-opcionais: queries parametrizadas em todo o lado (nada de SQL concatenado em strings), validação de input server-side em todos os endpoints, CORS restringido à origem da app e rate limiting nos endpoints de auth. Revê a lógica de autorização gerada antes do lançamento como revias a de um programador júnior rápido — os padrões estão certos; as regras específicas da tua app sobre "quem pode ver os dados de quem" merecem olhos humanos.

6 prompts completos prontos a copiar para apps full-stack

Cada um é completo e exercita deliberadamente a geração de backend — contas, relações, papéis, agregação. Cola tal como está.

1. Gestor de tarefas SaaS com equipas:

Constrói uma app de gestão de tarefas chamada Taskframe onde os utilizadores se registam, criam projetos e adicionam tarefas com título, descrição, prioridade (baixa/média/alta), data limite e estado (aberta/em curso/feita). Os utilizadores podem convidar colegas para um projeto por email; os membros veem os projetos partilhados, mas só o dono do projeto pode apagar o projeto ou remover membros. Vistas: um quadro agrupado por estado com drag entre colunas, e uma vista de lista com ordenação e filtros. O dashboard mostra as minhas tarefas abertas em todos os projetos, ordenadas por data limite, com as atrasadas a vermelho. UI clara e limpa, acento índigo.

2. Loja e-commerce com painel de administração:

Cria uma loja online de cerâmica artesanal chamada Kiln & Co. Os clientes navegam numa grelha de produtos com filtros por categoria, veem páginas de detalhe de produto, adicionam ao carrinho e fazem checkout (formulário de morada de envio + pagamento simulado), criando uma encomenda com histórico guardado na conta. Papel de admin: área /admin separada com gestão de produtos (criar, editar, arquivar produtos com nome, preço, stock, categoria, descrição), lista de encomendas com atualizações de estado (pendente/enviada/entregue) e um resumo de receita por mês. O stock decrementa na encomenda; produtos com stock a zero mostram esgotado e não podem ser encomendados. Design quente e minimal, acento terracota.

3. Plataforma de reservas:

Constrói uma app de reservas para um estúdio de yoga. Público: horário de aulas da semana (nome, professor, hora, vagas restantes), registo e login. Os membros reservam lugar numa aula — capacidade imposta server-side para que uma aula cheia rejeite mais reservas — e podem cancelar até 2 horas antes do início. A página das minhas reservas mostra aulas futuras e passadas. Papel de staff: criar e editar aulas (nome, professor, dia da semana, hora, capacidade), ver as listas de presenças por aula e marcar presenças. Impede reservar duas vezes o mesmo membro na mesma aula. Design calmo em salva e creme.

4. Quadro de feedback de clientes:

Cria um quadro público de feedback como uma ferramenta minimal de roadmap de produto. Qualquer pessoa com sessão iniciada pode submeter uma ideia (título, descrição, categoria) e votar noutras — um voto por utilizador por ideia, alternável. As ideias ordenam por votos ou recência; cada uma tem uma thread de comentários. Papel de admin: mudar o estado da ideia (em análise/planeada/em curso/lançada), afixar ideias e apagar spam. A página pública de roadmap agrupa as ideias por estado em colunas. As mudanças de estado aparecem num feed de atividade na ideia. Tema escuro, acento azul-elétrico.

5. App de faturação:

Constrói uma app de faturação para freelancers. Os utilizadores gerem clientes (empresa, nome de contacto, email, morada) e criam faturas: cliente, linhas (descrição, quantidade, preço unitário), taxa de imposto, data de vencimento e um número de fatura sequencial auto-gerado por utilizador. Estados da fatura: rascunho, enviada, paga, vencida — vencida calculada automaticamente a partir da data de vencimento. Dashboard: total em dívida, pago-este-mês, contagem de vencidas e um gráfico de barras de receita de 6 meses. Página pública de fatura só-leitura num link partilhável com layout amigável para impressão. Design profissional em ardósia e branco.

6. Plataforma comunitária de receitas:

Cria uma plataforma comunitária de partilha de receitas. Os utilizadores registam-se, publicam receitas (título, placeholder de foto, lista de ingredientes, passos numerados, tempo de confeção, dificuldade, tags) e editam ou apagam apenas as suas. Toda a gente navega por tag ou pesquisa full-text em títulos e ingredientes; cada receita tem classificações por estrelas (uma por utilizador, editável) ordenadas por classificação média, mais comentários. Os perfis de utilizador mostram as suas receitas e favoritos guardados. Página inicial: melhor classificadas esta semana e mais recentes. O papel de moderador pode remover receitas e comentários. Design fresco em verde e creme com títulos serifados.

A ler o padrão: nomeia as entidades e os seus campos, diz quem pode fazer o quê ("só o dono pode apagar") e menciona qualquer regra que tenha de se manter ("capacidade imposta server-side", "um voto por utilizador"). Essas frases tornam-se chaves estrangeiras, middleware e constraints.

Como funcionam o deploy e as pré-visualizações em apps full-stack?

Durante a geração, o frontend corre numa microVM de pré-visualização ao vivo com hot reload, já a falar com a API real gerada — o registo que testas na pré-visualização escreve linhas reais que podes ver imediatamente no navegador de tabelas do painel de Backend ou consultar com SQL puro. Fazer deploy envia o frontend para a edge da Cloudflare e o backend + PostgreSQL para a infraestrutura do VULK, um clique, URL ao vivo, domínios personalizados suportados. Os deploys de backend + PostgreSQL estão incluídos a partir do plano Builder ($19.99/mês); a iteração depois do deploy é o mesmo ciclo de prompts de seguimento, com as mudanças de schema tratadas como migrações em vez de reconstruções que destroem dados.

Podes exportar tudo e ir embora? (A resposta honesta)

A pergunta a fazer a qualquer plataforma antes de teres 10.000 utilizadores. A resposta do VULK tem uma metade forte e uma metade limitada — aqui estão as duas, com precisão:

O que exporta de forma limpa:

• Código completo do frontend — download ZIP ou push para o GitHub; um projeto standard React + Vite + TypeScript sem dependências proprietárias.
• O teu schema completo — o schema.sql segue na exportação do código.
• Todos os teus dados — exportação CSV por tabela a partir do painel de Backend (a tabela completa, não só a página visível), mais acesso SQL puro via query runner.

O que não exporta: o runtime do backend. O motor de API que serve os endpoints CRUD gerados e a auth é infraestrutura alojada do VULK, e o frontend exportado chama-o no seu URL alojado. Exporta uma app full-stack e o frontend corre em qualquer lado — mas continua a falar com a API do VULK. Self-hosting da coisa toda significa reimplementar a camada de API (com o teu schema e dados exportados como especificação completa — uma reconstrução delimitada em Express-ou-o-que-quiseres, mas trabalho real).

Para contexto sobre como o resto do mercado responde à mesma pergunta: Lovable/Bolt têm a portabilidade de dados mais limpa — o projeto Supabase é teu, pg_dump e vai (a lógica de backend em edge functions e políticas RLS ainda precisa de migração). O Replit dá acesso total ao código; a VM é tua. O Base44 não tem exportação de backend nenhuma. As ferramentas só-frontend fintam a pergunta por nunca terem os teus dados. Seja qual for a ferramenta que escolheres: testa o caminho de exportação na semana um, não no mês doze.