Empieza aquí
Quick start
De cero a deploy en Vercel en una sentada.
Al final de esta página vas a tener:
- ✅ Tu repo en GitHub con el código de VibeFast.
- ✅ El proyecto corriendo en
localhost:3000. - ✅ Supabase conectado a tu app, con las tablas pre-cargadas.
- ✅ Tu landing deployada en Vercel con una URL pública.
Tiempo estimado: 30–60 minutos (la primera vez puede tardar un poco más).
Antes de empezar (revisa esto primero)
Esta página asume que ya hiciste las 3 anteriores de "Empieza aquí". Si te falta alguna, ve, hazla y regresa aquí — cada una te lo recuerda al final:
1 · Tu compu preparada → Prepara tu compu (Mac / Windows). Ahí instalas Node, yarn, Git, Supabase CLI y Cursor, y configuras tu nombre y correo de Git. Si node --version, yarn --version, git --version y supabase --version te responden con un número, ya estás.
2 · Tus cuentas creadas → Cuentas que necesitas. Para hoy bastan GitHub, Vercel y Supabase (en casi todas entras con tu cuenta de GitHub).
3 · Tu proyecto de Supabase listo, con las 3 keys a la mano → Supabase paso a paso. Crear cuenta, crear proyecto, guardar la contraseña de la base y copiar tus 3 keys (~10 min, todo con clicks). Vuelve aquí con tus keys copiadas.
No avances al Paso 1 sin esto:
✅ Los cuatro comandos --version responden (compu lista).
✅ Cuentas de GitHub, Vercel y Supabase creadas.
✅ Tus 3 keys de Supabase copiadas en un bloc de notas.
Paso 1 · Haz tu fork (primero esto)
Antes que nada, crea tu propia copia del repo en GitHub. No trabajas sobre el original — trabajas sobre tu copia.
- Abre este link en tu navegador, en una pestaña nueva: github.com/arampersand/VibeFast.
- Arriba a la derecha, haz click en el botón Fork → Create fork. Espera unos segundos.
- Listo: ahora tienes tu copia en
github.com/TU-USUARIO/VibeFast. Sobre esa vas a trabajar de aquí en adelante.
Fork vs. Use this template
El Fork es lo más simple (un clic) y queda ligado al original para traer mejoras después — por eso lo recomendamos. Si prefieres un repo totalmente limpio, sin el historial de VibeFast, usa "Use this template" → Create a new repository en el mismo repo.
Paso 2 · Clónalo en tu computadora
Ahora baja tu fork a tu compu. Primero elige en qué carpeta vivirá (conviene una carpeta para tus proyectos).
En Mac (Terminal):
cd ~/Documents
mkdir -p proyectos && cd proyectosEn Windows (PowerShell):
cd ~\Documents
mkdir proyectos; cd proyectosYa estás parado en Documents/proyectos. Ahora necesitas el link de tu fork.
El link de abajo es un EJEMPLO — NO lo copies tal cual
Cada quien tiene su propio link. Consíguelo así:
- Ve a tu fork en GitHub (
github.com/TU-USUARIO/VibeFast). ¿No lo tienes? Es que no forkeaste — regresa al Paso 1. - Haz click en el botón verde
Code. - Pestaña HTTPS → copia el link (termina en
.git).
Ese link copiado es el que va después de git clone.
¿GitHub te pide usuario o token al hacer push?
Con HTTPS, la primera vez que publiques, Cursor te mostrará un botón para iniciar sesión con GitHub — acéptalo y no te lo vuelve a pedir. Si prefieres la alternativa avanzada con llaves SSH (opcional, no la necesitas para el curso), la guía oficial está en docs.github.com.
Con tu link copiado, clónalo y ábrelo en Cursor (aquí TU-USUARIO es solo ejemplo — usa tu link real):
git clone https://github.com/TU-USUARIO/VibeFast.git
cd VibeFast
cursor .git clone crea la carpeta VibeFast/ con todo el código adentro, dentro de la carpeta donde estés parado.
Tip: ¿dónde estoy parado?
Corre pwd para ver tu carpeta actual y ls para ver qué hay. Los dos funcionan igual en Mac y en Windows (PowerShell los acepta). Así confirmas que clonaste en el lugar correcto.
Paso 3 · Instala dependencias
En la terminal de Cursor:
yarn installEsto puede tardar 1–2 minutos la primera vez.
¿Falla el install?
Los tropiezos más comunes (versión de Node incorrecta, yarn: command not found, permisos, red) y su solución están en Errores comunes → instalar dependencias.
Paso 4 · Ten tus keys de Supabase a la mano
Necesitas 3 valores de tu proyecto de Supabase:
NEXT_PUBLIC_SUPABASE_URLNEXT_PUBLIC_SUPABASE_ANON_KEYSUPABASE_SERVICE_ROLE_KEY
Ya los copiaste en Supabase paso a paso → Paso 4. ¿No los tienes? Ve ahí — dice exactamente en qué botón está cada uno — y vuelve.
La service_role es secreta
Es la llave maestra de tu base de datos. Nunca la subas a git ni la pongas en el navegador. La anon sí es pública (por eso lleva NEXT_PUBLIC_).
Paso 5 · Crea tu .env.local
Las variables de entorno son datos de configuración y secretos (tus keys). Viven en un archivo llamado .env.local dentro de la carpeta web/ (no en la raíz del proyecto): la ruta es web/.env.local.
El repo ya trae una plantilla, web/.env.example, con todos los nombres de variables (sin valores). Cópiala a .env.local:
cp web/.env.example web/.env.localÁbrela en Cursor: en el explorador de archivos (panel izquierdo), entra a la carpeta web/ y abre .env.local. Empieza con punto, así que es un archivo "oculto", pero en el árbol de Cursor sí aparece.
Cada variable va en su propia línea, con el formato NOMBRE=valor — sin espacios alrededor del = y sin comillas. Por ejemplo: NEXT_PUBLIC_SUPABASE_URL=https://xxxx.supabase.co. El archivo se ve así:
# Sem 1 — obligatorias
NEXT_PUBLIC_APP_URL=http://localhost:3000
NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_ANON_KEY=
SUPABASE_SERVICE_ROLE_KEY=
# Sem 3+ — para las features de IA
OPENAI_API_KEY=
# Opcionales
RESEND_API_KEY=
NEXT_PUBLIC_POSTHOG_KEY=Por ahora solo necesitas las 4 primeras. El detalle de cada una (y de dónde sale) está en Variables de entorno.
Al cambiar el .env.local, reinicia
Las variables de entorno no se recargan solas. Cada vez que edites .env.local, detén yarn dev (Ctrl+C) y vuelve a correrlo.
Nunca subas .env.local a git
Ya está en .gitignore. Mantenlo así. La service_role key es como la llave maestra de tu base de datos.
Paso 6 · Sube el schema a Supabase
Ya instalaste el Supabase CLI en Antes de empezar. Conéctalo a tu proyecto y sube las tablas:
supabase login
supabase link --project-ref <tu-project-ref>
supabase db pushTu project-ref está en la URL del dashboard (https://supabase.com/dashboard/project/TU-REF) o en Project Settings → General. Si supabase link te pide contraseña, es la Database Password que guardaste al crear el proyecto.
Verifica que funcionó: abre el Table Editor en el dashboard de Supabase — deberías ver las tablas (profiles, waitlist, core_items…). El detalle está en Supabase paso a paso → Paso 5.
¿Se atoró supabase link o db push?
No te bloquees: puedes seguir al Paso 7 y volver aquí después (la landing corre sin base de datos, pero tu waitlist no guardará emails hasta completar este paso). Pega el error exacto en Cursor o revisa Errores comunes.
Paso 7 · Personaliza tu producto
Abre web/config.js y cambia solo estos 4 valores para confirmar que todo funciona:
app.name— el nombre de tu producto.app.description— qué hace tu producto en una frase.landing.hero.title— el titular de tu landing.brand.primary— tu color (hex).
El copy completo lo harás en Semana 1
Aquí solo comprueba que al cambiar config.js cambia tu landing. La personalización a fondo (hero completo, features, FAQ) tiene su propio prompt en Semana 1 · Paso 2.
Paso 8 · Corre en local
yarn devAbre http://localhost:3000. Deberías ver tu landing con tus textos.
✅ Ves tu landing con tu título y color primario.
✅ El menú lleva a /docs y muestra estas docs.
✅ El formulario de waitlist responde — y si escribes un email, aparece como fila en la tabla waitlist (Supabase → Table Editor), gracias al Paso 6.
¿Algo no carga? → Troubleshooting.
Paso 9 · Deploy a Vercel
- Entra a vercel.com/new (haz login con GitHub).
- En la lista de repos, busca tu fork y haz click en Import. (Si no aparece, click en Adjust GitHub App Permissions y dale acceso.)
- Root Directory: click en Edit y selecciona/escribe
web. Es clave — el proyecto es un monorepo y la app vive enweb/. - Framework Preset: Next.js (se autodetecta, no lo toques).
- Expande Environment Variables y agrega cada variable de tu
web/.env.local(nombre y valor, una por una). Mínimo estas 4: las 3 de Supabase +NEXT_PUBLIC_APP_URL. - Click Deploy.
NEXT_PUBLIC_APP_URL en Vercel NO es localhost
En Vercel, NEXT_PUBLIC_APP_URL no debe ser http://localhost:3000 — ahí va la URL de tu deploy (ej. https://tu-producto.vercel.app). Esa URL la sabes hasta después del primer deploy: haz el deploy, copia la URL que te da Vercel, actualiza la variable en Settings → Environment Variables y redeploya (o agrégala después).
En 2–3 minutos tienes una URL pública. Compártela.
¿El build falla con 'Module not found'?
Casi siempre es que olvidaste el Root Directory = web. Ve a Project → Settings → General → Root Directory, ponlo en web y vuelve a deployar.
Estructura del proyecto
No necesitas conocerla toda hoy, pero ubícate. Esto es lo que hay:
| Carpeta | Qué vive ahí |
|---|---|
web/app | Las páginas (cada carpeta con page.js = una ruta). |
web/app/api | Los endpoints del backend (1 archivo = 1 API). |
web/components | Los componentes de React (landing, docs, UI). |
web/lib | Helpers: Supabase, OpenAI, Resend, utilidades. |
web/config.js | La configuración de tu producto (ver abajo). |
supabase/ | Migrations y schema de la base de datos. |
docs-content/ | Estas docs en MDX (son tuyas, edítalas). |
Regla mental
¿Algo se ve en pantalla? → está en web/app o web/components. ¿Algo que habla con un servicio (IA, DB, email)? → está en web/app/api o web/lib.
El archivo config.js
web/config.js es el archivo más importante del boilerplate: cambiarlo cambia tu producto entero sin abrir JSX. Cada sección está comentada:
app— nombre, descripción, dominio de tu producto.brand— color primario, logo, radios.features— toggles para prender/apagar cada feature (waitlist, aiChat, agents…).landing— todo el copy de la página pública (hero, features, FAQ, pricing).pricing— los planes.
Empieza por aquí en Semana 1
Abre web/config.js y edita app + landing.hero. Con eso tu landing ya es tuya.
¿Y ahora?
→ Sigue con el tutorial de 5 minutos: Semana 1 · Landing.