Criador de apps com IA e Supabase: banco, login, arquivos
Criador de apps com IA e Supabase: banco, login, arquivos
Sim. O Supabase é a integração do Zugo para três coisas que andam juntas: banco de dados, login de usuários e armazenamento de arquivos. Os dados ficam em uma conta sua, conectar não gasta créditos, e é essa peça que separa um site de apresentação de um aplicativo de verdade.
O que muda quando um projeto ganha banco de dados?
Ele passa a lembrar. Essa é a diferença inteira, e ela vale mais que qualquer descrição técnica. Sem banco, cada visitante vê a mesma página parada e nada do que ele faz sobrevive ao fechamento da aba. Com banco, o projeto guarda cadastro, pedido, mensagem, agendamento e histórico.
A partir daí surgem coisas que não existiam antes: uma área que só o cliente logado enxerga, uma lista que cresce conforme as pessoas usam, um painel onde você acompanha o que chegou durante a noite. É o ponto em que o projeto deixa de ser folheto e vira ferramenta.
Também surgem responsabilidades. Dados de pessoas exigem cuidado com acesso, com backup e com o que a LGPD chama de finalidade: você guarda o que precisa para operar, e não tudo o que seria interessante ter algum dia.
Preciso do Supabase desde a primeira versão?
Quase nunca. E essa resposta economiza tempo e crédito de muita gente. Vale usar a tabela abaixo para decidir, porque a pergunta certa não é "meu projeto merece um banco", e sim "existe algo aqui que precisa ser lembrado depois que a pessoa sai".
| O que o projeto faz | Precisa de Supabase? |
|---|---|
| Mostrar serviços e um formulário de contato | Não |
| Página de vendas com botão de compra | Não |
| Área de cliente com login | Sim |
| Cadastro que gera lista consultável | Sim |
| Painel interno com dados da operação | Sim |
| Upload de arquivo pelo usuário | Sim |
| Jogo 2D no navegador, partida avulsa | Não |
Um formulário de contato que dispara e-mail resolve o caso mais comum de pequeno negócio sem banco nenhum. Se a sua necessidade é receber pedido de orçamento, começar pelo caminho simples é mais rápido, e o banco entra quando o volume passar do ponto em que a caixa de entrada dá conta.
O erro na direção contrária também existe. Adiar o banco em um projeto que claramente vai ter contas de usuário significa refazer o fluxo depois, e refazer custa mais do que fazer certo na primeira vez.
Conectar o Supabase custa créditos?
Não. Créditos pagam a construção e as edições, e esta é a lista completa de valores.
| Ação no Zugo | Créditos |
|---|---|
| Construção de um site, app ou jogo | 6 |
| Edição sobre um projeto existente | 3 |
| Plataforma multipágina, três primeiras páginas | 12 |
| Cada página adicional | 3 |
| Construção no modo Hi-Fi | 12 |
| Edição no modo Hi-Fi | 6 |
| Conectar o Supabase | 0 |
Projeto com banco costuma exigir mais idas e vindas que um site simples, porque cada campo novo mexe em tela, em formulário e na forma como o dado é guardado. Como cada edição custa 3, e não 1, planejar os campos antes de pedir vale dinheiro de verdade. O valor 1 aparece em materiais antigos e está errado.
O plano gratuito dá 5 créditos, menos que uma construção de 6. O Pro custa US$ 25 por mês com 200 créditos, cerca de 16 plataformas multipágina ou 66 edições, faixa confortável para um aplicativo com cadastro. O Business custa US$ 99 por mês com 800 créditos. O plano do Supabase é contratado por você, direto com eles.
Como planejar os dados antes de pedir a construção?
Escreva em papel quem usa o sistema e o que cada um pode ver. Leva quinze minutos e evita a maior parte das edições desperdiçadas. Em quase todo projeto pequeno existem três papéis: o visitante, o cliente logado e você, que administra.
Depois liste as entidades, que é uma palavra difícil para "as coisas que o sistema guarda". Uma clínica guarda paciente, profissional e consulta. Uma loja guarda produto, pedido e cliente. Uma escola guarda aluno, turma e presença. Três ou quatro entidades cobrem quase todo projeto de primeira versão.
Por fim, para cada entidade, decida quais campos são obrigatórios. Campo obrigatório demais trava o cadastro, campo obrigatório de menos gera base suja. No Brasil vale pensar cedo se você precisa mesmo de CPF, porque pedir documento sem necessidade afasta gente no formulário e aumenta o que você precisa proteger.
Quem pode ver os dados dos meus usuários?
Essa é a pergunta que merece mais atenção do que costuma receber. A regra de acesso decide quem enxerga o quê, e ela precisa ser pensada por papel: o cliente logado vê os dados dele, você vê os da operação, e o visitante não vê nada além do que é público.
Um sintoma clássico de regra frouxa é a área de cliente que mostra o histórico certo para quem está logado e também abre para quem trocar o endereço na barra do navegador. Isso não é exclusivo de projetos feitos com IA, e vale conferir do mesmo jeito: entre com duas contas diferentes e tente ver os dados de uma pela outra.
Backup entra na mesma conversa. Os dados ficam na sua conta do Supabase, o que é bom para independência e significa que a rotina de cópia é sua. Faça a primeira exportação no dia em que o primeiro cliente real cadastrar alguma coisa, e não depois.
Como o Supabase se encaixa nas outras integrações?
Ele costuma ser o primeiro do trio que sustenta um produto pago. O Supabase sabe quem é a pessoa, o Stripe cobra dessa pessoa e o Resend avisa por e-mail que algo aconteceu. Planejar os três juntos evita retrabalho, mesmo que você ligue um de cada vez.
Depois vêm as peças de entrega: domínio próprio para o endereço definitivo, Vercel se você quiser o deploy na sua conta, Google Analytics para medir a jornada até o cadastro. E o GitHub, que exporta o código-fonte quando o projeto passar do que edições resolvem.
A ordem sugerida é banco, cobrança, e-mail, domínio, medição. Não é a única possível, e é a que menos obriga a refazer coisa já feita.
Onde estão os limites honestos?
O Zugo não substitui um time de desenvolvimento em um produto complexo, e produto com banco é onde essa fronteira aparece mais cedo. Relatório pesado, permissão em muitos níveis, integração com sistema legado e volume alto de escrita são trabalho de engenharia. O caminho, quando chega a hora, é exportar pelo GitHub e continuar com quem programa.
A verificação em sandbox roda antes da entrega e garante que uma construção que não abre não chegue até você. Ela confirma que o projeto sobe, e não que a sua modelagem de dados está correta nem que as regras de acesso cobrem todos os casos. Essa revisão é sua, e a checagem com duas contas descrita acima é o mínimo.
Para jogos, a nota já conhecida: eles são 2D e rodam no navegador, e o banco entra quando existir placar ou progresso salvo.
Por onde começar?
Comece sem banco e adicione quando doer. Publique a primeira versão, veja se as pessoas se interessam e só então gaste créditos e tempo montando cadastro para um público que talvez ainda não exista.
Quando a hora chegar, escreva os papéis e as entidades antes de pedir. O custo real de um aplicativo com dados está nas edições que vêm depois de uma descrição vaga.
Para continuar, criador de apps com IA e Stripe cobre a cobrança, criador de apps com IA e Resend trata dos e-mails do cadastro e como criar um aplicativo com IA mostra o ciclo completo desde a primeira descrição.
Dá para testar tudo isso em zugo.dev pelo plano gratuito, com um dos 25 modelos prontos como ponto de partida.