Cada semana nos preguntan qué stack usamos. La respuesta corta: Next.js 15, Supabase y Claude API. La respuesta larga — y útil — es por qué elegimos esa combinación, qué problemas nos ahorra y en qué escenarios explícitamente la descartamos.
Este artículo es la versión sin marketing. Lo que realmente corre en producción en los proyectos que entregamos desde Ecuador a clientes en LATAM y Estados Unidos.
Los tres criterios que usamos para elegir stack
Antes del stack, los criterios. Un equipo pequeño que entrega MVPs en días necesita tres cosas del stack:
- •Tiempo-a-primer-deploy mínimo: del git init al primer dominio público, menos de una hora.
- •Costo operativo predecible: nada de sorpresas de USD 2K porque un cliente alcanzó tracción.
- •Capacidad de entregar al cliente sin soporte eterno: el cliente tiene que poder mantener su sistema sin que lo tengamos que tocar cada semana.
Este filtro descarta rápido muchas opciones populares. AWS directo queda fuera por complejidad. Firebase queda fuera por el costo impredecible cuando crece. Rails queda fuera porque el ecosistema de talento junior en LATAM es mucho más grande en JS/TS que en Ruby.
Next.js 15 como capa de aplicación
Usamos Next.js con App Router y Server Components como default. Las razones concretas:
- •Un solo codebase para frontend y backend. Los endpoints viven al lado de las páginas que los usan. Para MVPs, esto elimina la fricción "en qué repo va esto".
- •Server Components reducen el JavaScript que viaja al cliente entre 40% y 70% comparado con un SPA tradicional. Mejor performance móvil, que en LATAM importa mucho.
- •Deploy a Vercel toma literalmente dos minutos. Preview deploys automáticos por PR. El cliente puede aprobar features sin que nadie mueva un dedo en infra.
Trade-off honesto: Next.js obliga a entender el modelo mental de server vs client components. Los developers que vienen de React puro tardan una o dos semanas en dejar de pelearse con "por qué no puedo usar useState aquí". Lo asumimos — a la tercera semana, la productividad es neta positiva.
Supabase como plataforma de datos y auth
Supabase reemplaza lo que antes eran 4 o 5 servicios: Postgres, auth, storage, edge functions y real-time. Para un equipo de 2 personas, esto es decisivo.
Qué nos da sin configurar nada:
- •Postgres completo con Row Level Security. Las políticas de seguridad se definen en la base, no en la app. Imposible olvidar un check de permisos.
- •Auth con email, OAuth y magic links. JWT listos. Sesiones persistentes. Tres líneas de código en el cliente.
- •Storage con URLs firmadas, automático. Útil para MVPs con subida de imágenes o documentos.
- •Pricing predecible: plan Pro de USD 25/mes cubre la mayoría de MVPs hasta varios miles de usuarios activos.
Cuándo Supabase NO nos sirve: proyectos con lógica de datos extremadamente específica (eventos financieros con compliance, motores de búsqueda custom con Elastic). En esos casos armamos backend en Node o Go separado y usamos Supabase solo como auth.
Claude como motor de producto
Usamos Claude API, no solo como "chatbot al final". Claude es la capa que toma decisiones estructuradas dentro del producto. Ejemplos reales de los últimos tres proyectos:
- •Clasificación automática de leads entrantes por intent y presupuesto probable.
- •Generación de propuestas comerciales personalizadas a partir de un brief.
- •Extracción estructurada de PDFs que llegan sin formato fijo.
- •Routing de tickets de soporte al equipo correcto.
Por qué Claude y no otros modelos: la calidad de seguir instrucciones con prompts largos es consistentemente mejor que alternativas a precio similar. Prompt caching reduce el costo a la mitad en workloads repetitivos. Y la estabilidad de la API a lo largo del último año ha sido la más alta del mercado que hemos medido.
Cuándo este stack NO es la respuesta correcta
Para ser honestos — porque importa más que el pitch — hay tres escenarios donde no recomendamos este stack:
- •Aplicaciones con requisitos regulatorios duros (banca, salud con HIPAA estricto): Supabase multi-tenant no siempre cumple. En esos casos, Postgres dedicado en AWS o GCP con compliance específico.
- •Productos con procesamiento de datos extremo (ML training, ETL pesado): Next.js y Supabase no son el lugar. Mejor Python + infra dedicada.
- •Equipos grandes con arquitectura ya establecida: si ya tienes 40 ingenieros corriendo en Rails o Django, migrar no vale la pena. El stack se elige para acelerar equipos pequeños; en equipos grandes, el cuello de botella es otro.
Qué significa esto para tu proyecto
Si estás decidiendo el stack para un MVP o un producto nuevo, la pregunta no es "¿es Next.js lo mejor?". Es "¿qué stack maximiza tu velocidad de aprender del mercado dado tu equipo y presupuesto?".
En la mayoría de los casos que vemos en Daleki Lab — founders con equipo de 1-3 personas, USD 15K-60K de presupuesto inicial, necesidad de estar en producción en semanas — la respuesta es este stack. En otros, no. Si quieres que te demos una segunda opinión sobre tu caso específico, escríbenos a /contacto o abre ARCO en dalekilab.com. Preferimos decirte "este stack no es para ti" que meterte en un proyecto que no encaja.