Creá una landing page completa y lista para producción para [nombre del producto], que vende [descripción breve del producto y a quién va dirigido]. Stack: Next.js App Router, TypeScript, Tailwind CSS. Mobile-first obligatorio. Secciones que debe tener, en este orden: 1. Hero — headline que golpea el dolor principal del usuario, subtítulo que explica el beneficio, CTA principal ("Empezar gratis" / "Ver planes"), badge de social proof ("Más de X usuarios"). 2. Problema — 3 puntos que describen el dolor actual del usuario antes de usar el producto. 3. Beneficios — 3 cards con ícono SVG, título corto y descripción de 2 líneas cada una. 4. Cómo funciona — pasos numerados (máx 4), cada uno con imagen o ilustración placeholder. 5. Testimonios — 3 cards con foto, nombre, cargo, y cita real o placeholder realista. 6. Precios — [indicar si hay planes o precio único], con tabla comparativa si hay más de uno. 7. FAQ — 5 preguntas frecuentes reales del nicho, con respuestas de 2-3 líneas. 8. CTA final — headline de cierre, subtítulo, botón principal y link secundario. Tono: [formal / casual / técnico]. Color principal: [color hex]. El copy debe vender la transformación, no el producto.
Configurá un proyecto Next.js 14+ (App Router) desde cero con este stack completo: - TypeScript estricto (strict: true en tsconfig) - Tailwind CSS v3 con el plugin de typography - Supabase: dos clientes separados — lib/supabase/client.ts (browser, 'use client') y lib/supabase/server.ts (server components, cookies) - Middleware en middleware.ts que refresca la sesión de Supabase en cada request - Variables de entorno validadas con Zod en lib/env.ts (lanzar error si faltan al arrancar) - Estructura de carpetas: app/, components/ui/, components/sections/, components/layout/, lib/, types/ Archivos a crear: - app/layout.tsx con fuentes de Google Fonts via next/font - app/page.tsx con placeholder básico - components/layout/Navbar.tsx y Footer.tsx vacíos con estructura - lib/utils.ts con función cn() para clases condicionales de Tailwind - .env.example con todas las variables comentadas - types/index.ts con los tipos base del proyecto Al final mostrá el árbol de carpetas completo y el comando para arrancar.
Quiero construir [descripción del producto] en un día. Soy [nivel de experiencia: principiante / intermedio] y uso [Cursor / Bolt / Lovable / v0]. Ayudame a definir el MVP mínimo viable siguiendo este análisis: 1. Core loop — cuál es la acción principal que el usuario hace (la que genera valor). Todo lo demás es secundario. 2. Features esenciales vs. opcionales — separalas en dos columnas: qué SÍ va en el MVP y qué queda para después. 3. Páginas mínimas — listá solo las rutas que necesito sí o sí para que el producto funcione y se pueda usar. 4. Orden de implementación — en qué orden arrancar para tener algo funcionando lo antes posible. 5. Qué NO hacer hoy — lista de features tentadoras pero que pueden esperar. Después de definir el scope, arrancamos directo con la primera pantalla: [indicá cuál querés hacer primero].
Creá el componente [NombreDelComponente] en React con TypeScript y Tailwind CSS. Contexto del componente: - Qué hace: [descripción precisa de la funcionalidad] - Dónde se usa: [en qué página o sección aparece] - Datos que recibe: [de dónde vienen — props, fetch, estado global] Requerimientos técnicos: - Props tipadas con interface TypeScript (no usar 'any') - Mobile-first: diseño base para 375px, breakpoints md: y lg: para desktop - Estados a manejar: [loading / error / empty / success — indicá cuáles aplican] - Accesibilidad: atributos aria-label donde corresponda, foco visible en elementos interactivos - Animaciones: solo si mejoran la UX, con Tailwind transition Casos borde que debe manejar: - Estado vacío (sin datos): mostrar mensaje amigable, no pantalla en blanco - Estado de carga: skeleton o spinner - Error: mensaje de error con opción de reintentar si aplica Props que acepta: [listá cada prop: nombre, tipo TypeScript, si es opcional, valor por defecto]
Convertí este diseño en un layout responsive con Tailwind CSS. El tráfico principal viene de mobile (celular), así que el diseño base debe ser perfecto en 375px y mejorar en pantallas más grandes. Diseño de referencia: [descripción detallada o adjuntá imagen] Reglas de responsive que quiero aplicar: - Mobile (base): columna única, padding horizontal 16px, botones full-width, texto mínimo 16px en inputs para evitar zoom en iOS - Tablet (md: 768px): [describí qué cambia — dos columnas, sidebar aparece, etc.] - Desktop (lg: 1024px): [describí el layout final de escritorio] Componentes específicos que necesito adaptar: - Navegación: [hamburger en mobile / links visibles en desktop] - Tablas: scroll horizontal en mobile (overflow-x-auto) - Imágenes: aspect-ratio fijo, object-cover - Grid de cards: [cuántas columnas en cada breakpoint] Además, revisá que los tap targets sean mínimo 44x44px en mobile y que el contenido no se desborde horizontalmente.
Creá el schema SQL completo de Supabase para una app de [tipo de app — ej: plataforma de cursos online, SaaS de gestión de proyectos, marketplace]. El producto hace lo siguiente: [descripción de las funcionalidades principales]. Los usuarios pueden: [listá las acciones clave del usuario]. Para cada tabla del schema incluí: - Nombre de la tabla en snake_case - Todas las columnas con su tipo de dato exacto (uuid, text, boolean, timestamptz, jsonb, etc.) - Restricciones: NOT NULL, DEFAULT, CHECK donde corresponda - Primary key (siempre uuid generado con gen_random_uuid()) - Foreign keys con ON DELETE CASCADE o SET NULL según el caso - Índices en columnas que se van a filtrar o joinear frecuentemente - created_at y updated_at en todas las tablas (updated_at con trigger automático) Después de las tablas, agregá: - Trigger para crear el perfil del usuario automáticamente al registrarse (auth.users → profiles) - Políticas RLS para cada tabla (habilitar RLS, usuarios ven solo sus datos) - Comentarios SQL en las columnas que no sean obvias Formato: SQL limpio listo para pegar en el SQL Editor de Supabase.
Escribí las políticas RLS de Supabase para la tabla [nombre_tabla]. Estructura de la tabla: [pegá el CREATE TABLE o describí las columnas principales] Reglas de acceso que necesito implementar: Para usuarios autenticados: - SELECT: [describí quién puede leer qué — ej: solo sus propios registros / todos los registros públicos / solo si tiene suscripción activa] - INSERT: [condiciones — ej: puede crear, user_id se asigna automáticamente del JWT] - UPDATE: [qué columnas puede modificar, solo las propias] - DELETE: [si puede o no borrar] Para admins (profiles.role = 'admin'): - Acceso total sin restricciones Para usuarios anónimos (no autenticados): - [qué pueden ver si es contenido público, o ningún acceso] Además: - Habilitá RLS en la tabla con ALTER TABLE - Usá auth.uid() para identificar al usuario actual - Si hay una columna user_id, asociala al JWT automáticamente en el INSERT - Dame el SQL completo listo para correr en Supabase
Escribí una migración SQL para Supabase (formato CLI) que aplique el siguiente cambio a la base de datos en producción: Cambio a aplicar: [descripción clara del cambio — ej: agregar columna subscription_status a la tabla profiles, crear tabla nueva, renombrar columna, agregar índice] Contexto del estado actual de la tabla: [pegá el schema actual o describí las columnas que ya existen] Requisitos de la migración: 1. Que sea segura para correr con datos en producción (no puede borrar ni romper datos existentes) 2. Que sea idempotente — si se corre dos veces no explota (usar IF NOT EXISTS, IF EXISTS) 3. Que tenga rollback comentado — el SQL para revertir el cambio si algo sale mal 4. Que maneje valores por defecto razonables para los datos existentes si se agrega una columna NOT NULL 5. Que actualice las políticas RLS si el cambio afecta la lógica de acceso Nombre del archivo de migración: [YYYYMMDD]_[descripcion-corta].sql Formato esperado: archivo SQL con comentarios explicando cada sección.
Implementá el sistema de autenticación completo con Supabase en Next.js App Router. Sin email/password — solo OAuth para minimizar fricción. Providers a incluir: Google [+ GitHub / Microsoft / Apple — indicá cuáles]. Archivos a crear: 1. app/login/page.tsx — página de login con: - Logo del producto - Headline: "Accedé con tu cuenta de [provider]" - Botones OAuth con ícono SVG de cada provider - Texto de privacidad: "No guardamos contraseñas" - Manejo del parámetro redirectedFrom para volver después del login 2. app/auth/callback/route.ts — ruta de callback que: - Intercambia el code por sesión - Crea el registro en tabla profiles si es la primera vez (upsert) - Redirige a /dashboard si ya tiene acceso, o a /precios si no tiene suscripción - Maneja errores y redirige a /login?error=... con mensaje 3. lib/supabase/server.ts — cliente server-side con cookies 4. lib/supabase/client.ts — cliente browser 5. middleware.ts — refresca sesión en cada request, redirige si la ruta está protegida Además: qué configurar en el dashboard de Supabase (redirect URLs) y en la consola de Google/GitHub para que funcione en local y en producción.
Creá el middleware de Next.js (middleware.ts) para proteger rutas privadas con Supabase Auth. Rutas privadas que deben estar protegidas: [listá las rutas — ej: /dashboard, /biblioteca, /configuracion, /admin] Rutas públicas que NO deben tocar el middleware: [ej: /, /blog, /precios, /login, /auth/callback] Lógica de redirección que necesito: - Sin sesión → redirigir a /login?redirectedFrom=[ruta original] (para volver después del login) - Con sesión pero sin suscripción activa → redirigir a /precios (verificar en tabla subscriptions) - Con sesión y suscripción activa → dejar pasar - Para rutas de /admin → verificar además que profiles.role === 'admin' Detalles técnicos: - Usar createServerClient de @supabase/ssr (no el cliente browser) - Refrescar el token automáticamente en cada request (supabase.auth.getUser()) - No usar getSession() del lado del servidor (no es seguro — usar getUser()) - El matcher del middleware solo debe correr en las rutas que lo necesitan, no en /api ni en archivos estáticos También mostrame cómo verificar el acceso dentro de un Server Component para casos donde el middleware no sea suficiente.
Preparame este proyecto Next.js para hacer el deploy en Vercel de forma correcta desde el primer intento. Estado actual del proyecto: [describí brevemente qué tiene — auth, pagos, webhooks, cron jobs, etc.] Necesito que me des: 1. Checklist de variables de entorno — todas las que tengo que cargar en Vercel → Settings → Environment Variables, separadas por entorno (Production / Preview / Development). 2. next.config.ts — configuración final con: - Headers de seguridad (CSP, X-Frame-Options, HSTS, etc.) - Redirects si hay alguno - Dominios permitidos en next/image - Variables de entorno del servidor que necesitan estar en el build 3. Webhooks a actualizar — listá qué URLs tengo que cambiar en cada servicio (Stripe, Supabase, etc.) con el formato exacto: https://[mi-dominio]/api/webhooks/[servicio] 4. Cron jobs — si tengo cron jobs en vercel.json, revisá que el schedule esté en UTC y que el endpoint tenga protección con CRON_SECRET. 5. Checklist post-deploy — 10 cosas a probar manualmente después del primer deploy para confirmar que todo funciona (auth, pago, email, rutas protegidas, etc.). 6. Dominio custom — pasos para conectar el dominio en Vercel y configurar los DNS.
Revisá todos los archivos del proyecto y generá el .env.example completo y bien documentado. Para cada variable de entorno seguí este formato exacto: # ─── NOMBRE DEL SERVICIO ─────────────────────────────────── # Para qué sirve esta variable (1 línea) # Dónde conseguirla: [URL o pasos exactos] # Ejemplo del formato del valor (nunca el valor real) NOMBRE_VARIABLE=ejemplo-de-formato Agrupá las variables por servicio: App, Supabase, Stripe / Mercado Pago, Email (Brevo / Resend), Analytics, Sentry, Redis (Upstash), Cron, APIs externas. Además: - Marcá con [OPTIONAL] las variables que no son obligatorias para que el proyecto arranque - Marcá con [NEXT_PUBLIC_] solo las que el browser necesita ver (y explicá por qué son públicas) - Para las variables de webhook secrets, explicá que deben generarse con openssl rand -base64 32 - Al final, agregá una sección "Variables que NO van en .env" con las que van en el dashboard del servicio (ej: redirect URLs de OAuth que van en Supabase, no en .env)
Analizá este error en detalle y dame todo lo que necesito para resolverlo: Error completo (con stack trace): [pegá el error completo — no lo recortes, el stack trace importa] Contexto donde ocurre: - Qué estaba haciendo el usuario cuando pasó: [describí el flujo] - En qué entorno ocurre: [local / producción / los dos] - Con qué frecuencia: [siempre / a veces / solo en ciertos casos] - Cambios recientes en el código: [qué modificaste antes de que aparezca] Necesito que me expliques: 1. Causa raíz — qué está fallando exactamente y por qué, en lenguaje simple 2. Por qué ocurre en este contexto — cómo se relaciona el error con lo que yo estaba haciendo 3. Reproducción mínima — el caso más simple para reproducirlo (si aplica) 4. Solución paso a paso — los cambios exactos que tengo que hacer, con el código corregido 5. Si hay más de una solución — cuál recomendás y por qué 6. Cómo prevenir errores similares en el futuro — qué patrón o validación agregaría
Este código no funciona como espero. Necesito que lo revises en profundidad. Comportamiento esperado: [describí qué debería pasar] Comportamiento actual: [describí qué pasa realmente — qué ves, qué error aparece, qué no aparece] Código completo del archivo (o la parte relevante): [pegá el código] Contexto adicional: - Framework y versión: [Next.js 14 / React 18 / etc.] - Dependencias relacionadas: [librería que estás usando] - Cómo se llama este código: [desde dónde se invoca] - Qué ya probaste: [lo que intentaste antes] Necesito que: 1. Identifiques el bug principal y expliques por qué ocurre 2. Muestres el código corregido completo (no solo el fragmento) 3. Comentés cada cambio que hiciste y por qué 4. Menciones otros problemas potenciales que veas aunque no sean el bug principal (performance, seguridad, edge cases) 5. Si hay una forma más limpia o idiomática de hacer lo mismo, la mostrés como alternativa
Generá el metadata completo y optimizado de Next.js para todas las páginas de este sitio. Datos del sitio: - Nombre del sitio: [nombre] - URL base (producción): [URL] - Descripción general: [1-2 oraciones sobre qué es el sitio] - Audiencia: [quién lo visita] - Locale: [es_AR / es_ES / en_US] - Color de marca: [hex — para theme-color] Para cada página que tengo ([listá tus páginas: /, /blog, /precios, etc.]) generá: - title: keyword principal + separador + nombre del sitio (max 60 chars) - description: orientada a conversión, con keyword + beneficio (max 155 chars) - openGraph: title, description, url, siteName, locale, type, images (con width/height/alt) - twitter: card type, title, description - alternates: canonical URL - robots: index/follow para páginas públicas, noindex para /admin y rutas privadas Además: - Layout raíz (app/layout.tsx): metadataBase, defaultMetadata, viewport, themeColor - Para páginas dinámicas (ej: /blog/[slug]): función generateMetadata() que hace fetch del post y usa sus datos - OG image: dimensiones recomendadas (1200x630) y cómo generarla con next/og
Creá el sitemap dinámico y robots.txt para este proyecto Next.js, optimizados para indexación en Google. Estructura del sitio: - URL base: [URL de producción] - Rutas estáticas públicas: [listá cada ruta — ej: /, /precios, /blog, /recursos, /contacto] - Rutas dinámicas: [listá con su fuente de datos — ej: /blog/[slug] desde tabla posts de Supabase] - Rutas a EXCLUIR del sitemap: /admin, /api, /auth/callback, y todas las rutas privadas Archivos a crear: 1. app/sitemap.ts — sitemap dinámico que: - Para rutas estáticas: define lastModified, changeFrequency y priority según importancia - Para rutas dinámicas: hace fetch desde Supabase (server-side, sin auth) de los registros publicados - Excluye entradas sin slug o sin fecha de publicación - Retorna máximo 50.000 URLs (límite de Google) — si hay más, explicá cómo hacer sitemaps divididos 2. app/robots.ts — robots.txt que: - Permite a todos los bots indexar las rutas públicas - Bloquea explícitamente /admin/, /api/, /auth/ - Incluye la URL del sitemap 3. Verificá que next.config.ts tenga el metadataBase configurado correctamente, porque sin eso el sitemap genera URLs relativas que Google rechaza.