MVP Starter Kit explicado simplemente (con diagramas y código real)
MVP Starter Kit : lo esencial en un artículo — código real, diagramas y pasos concretos, extractos de un curso de 43 lecciones.
Una guía que va al grano: MVP Starter Kit analizado con diagramas, ejemplos concretos y comandos probados. Todo proviene de un curso estructurado de 11 capítulos — aquí tienes lo mejor.
- Introducción y Mentalidad MVP
- Ideación y Validación
- Arquitectura del Starter Kit
- Autenticación y Usuarios
- Construir el Core del MVP
CRUD con Server Actions Next.js
Objetivos pedagógicos
- Comprender qué es una Server Action y por qué reemplaza a una API REST para un MVP
- Escribir una acción de creación, lectura, actualización y eliminación
- Refrescar la interfaz con
revalidatePathdespués de una mutación - Validar las entradas del lado del servidor antes de escribir en la base de datos
- Comprender cómo RLS protege automáticamente cada consulta
La intuición: llamar a una función servidor desde un formulario
Tradicionalmente, para modificar datos, el cliente envía una petición HTTP (fetch('/api/tasks', ...)) a una ruta API, que habla con la base de datos y luego devuelve una respuesta. Las Server Actions de Next.js eliminan esta plomería: escribes una función marcada con "use server" y la llamas directamente desde un formulario o componente. Next.js crea la petición HTTP por ti, entre bastidores.
Para un MVP, es una gran ganancia de tiempo: menos archivos, menos código de serialización, sin gestión manual de estados de carga para cada llamada. Escribes la lógica de negocio, Next.js se encarga del transporte.
El cliente Supabase del lado del servidor
Toda Server Action necesita un cliente Supabase que conozca al usuario conectado (a través de las cookies de sesión). Se centraliza en un helper:
Esquema Postgres y migraciones Supabase
Objetivos pedagógicos
- Modelar las entidades centrales de tu MVP en tablas Postgres
- Escribir una migración SQL versionada con la CLI Supabase
- Comprender y activar Row Level Security (RLS) en cada tabla
- Vincular los datos al usuario conectado mediante
auth.uid() - Mantener el esquema simple: modelar solo lo que exige el MVP
La intuición: el esquema cuenta lo que hace tu producto
Antes de escribir la primera línea de código de la aplicación, hazte una pregunta sencilla: ¿cuáles son las 2 o 3 entidades que manipula mi producto? Una aplicación de gestión de tareas manipula proyectos y tareas. Un SaaS de notas manipula notas. Una herramienta de facturación manipula clientes y facturas. El esquema de base de datos es la traducción directa de esa respuesta.
La tentación del principiante es prever todo: etiquetas, categorías, historial, archivos adjuntos, compartir. Para un MVP, se corta. Se mantiene la tabla principal, su relación con el usuario, y nada más. Se añadirá el resto cuando un cliente real lo solicite.
Modelar las entidades del MVP
Tomemos un ejemplo concreto: un MVP de gestión de tareas compartidas. Dos entidades bastan para la primera versión: projects y tasks. Cada proyecto pertenece a un usuario, cada tarea pertenece a un proyecto.
| Tabla | Columnas clave | Relación |
|---|---|---|
projects | id, user_id, name, created_at | pertenece a un user (auth.users) |
tasks | id, project_id, title, done, created_at | pertenece a un project |
Observa la convención: un identificador uuid generado automáticamente, una clave foránea hacia el padre, un created_at por defecto. Esta estructura se repite en el 90 % de las tablas de un MVP.
Escribir la migración SQL
Supabase versiona el esquema mediante archivos de migración SQL en supabase/migrations/. Se crea un nuevo archivo con la CLI:
with check
Controla qué filas pueden insertarse o modificarse. Impide que un usuario cree un proyecto a nombre de otro.
anon (pública por naturaleza) puede leer toda tu base de datos. Es la fuga de datos número uno de los MVPs Supabase. Activa RLS en CADA tabla, sin excepción.Aplicar la migración
En local con el contenedor Supabase, luego hacia la base remota:
Webhooks Stripe y sincronización Supabase
Objetivos pedagógicos
- Comprender por qué el webhook es la única fuente de verdad del pago
- Crear una ruta webhook en Next.js
- Verificar la firma de Stripe para rechazar peticiones falsas
- Actualizar la tabla de suscripción en Supabase
- Probar el webhook en local con la CLI Stripe
La intuición: Stripe te avisa cuando algo sucede
Tras un pago, Stripe envía una petición HTTP a una URL que declaras: es un webhook. Esta petición lleva un evento (checkout.session.completed, customer.subscription.deleted, etc.). Es la única información fiable: la página de retorno del navegador puede recargarse, cerrarse o ser falsa, pero el webhook procede de los servidores de Stripe.
El principio es por tanto: solo se concede el acceso de pago cuando el webhook lo indica. Es más robusto e imposible de eludir por un usuario astuto.
La tabla de suscripción en Supabase
Este artículo cubre los extractos más útiles — el curso completo MVP Starter Kit (11 capítulos, 43 lecciones, ejercicios corregidos y proyecto final) te lleva hasta el final.
./acceder-al-curso-completo curso gratuito: Vibe CodingFAQ
¿Cuánto tiempo se necesita para aprender MVP Starter Kit?
¿Se necesitan requisitos previos?
¿Por dónde empezar concretamente?
📬 ¿Quieres recibir este tipo de guía cada semana? Suscríbete gratis — código real, cero palabrería.