MVP Starter Kit explicado de forma simples (com diagramas e código real)
MVP Starter Kit : o essencial em um artigo — código real, diagramas e etapas concretas, extraídos de um curso de 43 lições.
Um guia direto ao ponto: MVP Starter Kit dissecado com diagramas, exemplos concretos e comandos testados. Tudo vem de um curso estruturado de 11 capítulos — aqui está o melhor.
- Introdução e Mindset MVP
- Ideação e Validação
- Arquitetura do Starter Kit
- Autenticação e Usuários
- Construir o Core do MVP
CRUD com Server Actions Next.js
Objetivos pedagógicos
- Compreender o que é uma Server Action e por que ela substitui uma API REST para um MVP
- Escrever uma ação de criação, leitura, atualização e exclusão
- Atualizar a interface com
revalidatePathapós uma mutação - Validar as entradas no lado do servidor antes da escrita no banco
- Compreender como a RLS protege automaticamente cada requisição
A intuição: chamar uma função servidor a partir de um formulário
Tradicionalmente, para modificar dados, o cliente envia uma requisição HTTP (fetch('/api/tasks', ...)) para uma rota de API, que conversa com o banco, e depois retorna uma resposta. As Server Actions do Next.js eliminam essa complexidade: você escreve uma função marcada com "use server" e a chama diretamente de um formulário ou componente. O Next.js cria a requisição HTTP para você, nos bastidores.
Para um MVP, isso representa uma grande economia de tempo: menos arquivos, menos código de serialização, sem gerenciamento manual de estados de carregamento para cada chamada. Você escreve a lógica de negócio, o Next.js cuida do transporte.
O cliente Supabase no lado do servidor
Toda Server Action precisa de um cliente Supabase que conheça o usuário conectado (via cookies de sessão). Centralizamos isso em um helper:
Esquema Postgres e migrações Supabase
Objetivos pedagógicos
- Modelar as entidades centrais do seu MVP em tabelas Postgres
- Escrever uma migração SQL versionada com a CLI Supabase
- Compreender e ativar Row Level Security (RLS) em cada tabela
- Vincular os dados ao usuário conectado via
auth.uid() - Manter o esquema simples: modelar apenas o que o MVP exige
A intuição: o esquema conta o que seu produto faz
Antes de escrever qualquer linha de código da aplicação, faça uma pergunta simples: quais são as 2 ou 3 entidades que seu produto manipula? Um aplicativo de gerenciamento de tarefas manipula projetos e tarefas. Um SaaS de anotações manipula anotações. Uma ferramenta de faturamento manipula clientes e faturas. O esquema do banco de dados é a tradução direta dessa resposta.
A tentação do iniciante é prever tudo: tags, categorias, histórico, anexos, compartilhamento. Para um MVP, cortamos. Mantemos a tabela principal, sua relação com o usuário, e só. Adicionaremos o resto quando um cliente real pedir.
Modelar as entidades do MVP
Vamos a um exemplo concreto: um MVP de gerenciamento de tarefas compartilhadas. Duas entidades bastam para a primeira versão: projects e tasks. Cada projeto pertence a um usuário, cada tarefa pertence a um projeto.
| Tabela | Colunas-chave | Relação |
|---|---|---|
projects | id, user_id, name, created_at | pertence a um user (auth.users) |
tasks | id, project_id, title, done, created_at | pertence a um project |
Note a convenção: um identificador uuid gerado automaticamente, uma chave estrangeira para o pai, um created_at por padrão. Essa estrutura se repete em 90% das tabelas de um MVP.
Escrever a migração SQL
O Supabase versiona o esquema por meio de arquivos de migração SQL em supabase/migrations/. Criamos um novo arquivo com a CLI:
with check
Controla quais linhas podem ser inseridas ou modificadas. Impede que um usuário crie um projeto em nome de outro.
anon (pública por natureza) pode ler todo o seu banco. Esse é o vazamento de dados número um dos MVPs Supabase. Ative RLS em CADA tabela, sem exceção.Aplicar a migração
Localmente com o container Supabase, depois para o banco remoto:
Webhooks Stripe e sincronização Supabase
Objetivos pedagógicos
- Compreender por que o webhook é a única fonte de verdade do pagamento
- Criar uma rota de webhook no Next.js
- Verificar a assinatura do Stripe para rejeitar requisições falsas
- Atualizar a tabela de assinatura no Supabase
- Testar o webhook localmente com a CLI Stripe
A intuição: o Stripe avisa quando algo acontece
Após um pagamento, o Stripe envia uma requisição HTTP para uma URL que você declara: é um webhook. Essa requisição carrega um evento (checkout.session.completed, customer.subscription.deleted, etc.). Essa é a única informação confiável: a página de retorno do navegador pode ser atualizada, fechada ou falsa, mas o webhook vem dos servidores do Stripe.
O princípio é simples: só concedemos o acesso pago quando o webhook nos informa. Isso é mais robusto e impossível de contornar por um usuário mal-intencionado.
A tabela de assinatura no Supabase
Este artigo cobre os trechos mais úteis — o curso completo MVP Starter Kit (11 capítulos, 43 lições, exercícios corrigidos e projeto final) leva você até o fim.
./acceder-au-cours-complet curso gratuito : Vibe CodingFAQ
Quanto tempo para aprender MVP Starter Kit?
É preciso ter pré-requisitos?
Por onde começar na prática?
📬 Quer receber este tipo de guia toda semana? Inscreva-se gratuitamente — código real, zero enrolação.