Boilerplate Next.js + Supabase en español: por qué no empezar de cero

Te voy a hacer una pregunta incómoda: ¿cuántas horas pierdes la primera vez que configuras autenticación, pagos y emails en un proyecto nuevo? Si nunca lo has cronometrado, te ahorro la cuenta — entre 30 y 60 horas. Y lo peor: no son horas que aporten valor a tu producto. Son horas que cualquier indie del mundo ha gastado antes que tú, peleándose con los mismos webhooks.

Este post va de eso: del coste oculto de empezar de cero, de qué resuelve un boilerplate Next.js + Supabase bien hecho y por qué tenerlo en castellano cambia las reglas si tu mercado habla español.

El coste oculto de empezar de cero

Vamos a poner números. Estas son las horas que, según mi experiencia (y la que leo en cualquier hilo de Twitter de indie hackers), te lleva configurar lo "aburrido" desde cero en Next.js + Supabase:

Y eso es tiempo de quien sabe lo que hace. Si nunca has integrado Stripe en serio, suma un 50% por las cosas que descubres por las malas: webhooks que no firmas bien, idempotencia mal hecha, suscripciones que se quedan en estado "incomplete" sin que sepas por qué.

El problema no es solo el tiempo. Es que esas horas no tienen rendimiento decreciente solo para ti — son trabajo que no aporta diferenciación. Tu auth no va a ser mejor que la de Notion. Tus webhooks no van a ser más bonitos. Tu panel admin no va a vender más. Es infraestructura, no producto.

Qué resuelve un boilerplate

Un boilerplate bien hecho no es "código que copias y pegas". Es una colección de decisiones tomadas. Cada archivo es un "no tienes que pensar en esto". Concretamente:

1. Decisiones de arquitectura

Dónde va el código de servidor vs cliente, cómo estructurar las API routes, dónde poner los hooks, cómo separar lo presentacional de lo lógico. Decisiones que parecen pequeñas pero que cuando las tomas mal en la semana 1 te explotan en la semana 6.

2. Integraciones pegadas con cinta

Auth, pagos, emails y storage hablan entre sí. Cuando un usuario paga, tienes que: verificar el webhook, actualizar la tabla users, mandar un email de confirmación, registrar el evento. Si lo hace cada pieza por su cuenta, tienes 4 sitios donde puede romperse. Un boilerplate decente lo conecta todo en flujos coherentes.

3. Edge cases ya pensados

¿Qué pasa si el usuario cancela el pago a mitad de checkout? ¿Si el webhook de Stripe llega antes que la confirmación? ¿Si pagas dos veces por error? ¿Si hay un chargeback? Estos casos los descubres en producción, con usuarios reales y cabreados. Un boilerplate maduro ya los ha cazado.

4. Componentes UI que no parecen un MVP

Tailwind v4 + shadcn/ui son la base, pero todavía tienes que componer formularios, modales, tablas, toasts, paginadores, estados vacíos, estados de carga. Un boilerplate decente te da 40-60 componentes ya pulidos con modo claro y oscuro.

"El valor de un boilerplate no se mide en líneas de código — se mide en decisiones que no tienes que tomar."

Por qué importa que esté en castellano

Aquí es donde la mayoría de boilerplates fallan para nosotros. ShipFast, Makerkit, SaaS Pegasus, BoilerplateHQ — todos en inglés. Y no me refiero solo a la landing — me refiero a la documentación, los nombres de variables, los comentarios del código, las plantillas de email.

"Vale, pero el inglés se entiende". Sí, pero hay tres costes ocultos:

1. Curva de aprendizaje partida. Aprender Next.js es difícil. Aprender Next.js leyendo docs en tu segundo idioma es 1,3x más lento. Está medido.
2. Plantillas que no encajan con tu mercado. Si tu producto vende a hispanohablantes, los emails de bienvenida en "Hey there 👋" hay que reescribirlos. Los textos legales de tu plantilla de RGPD no aplican igual en España que en EEUU.
3. Soporte en horario y idioma equivocados. Cuando tienes un bug a las 23:00 un domingo, escribir a un Discord en inglés con timezone PST es frustrante. Un Discord en castellano con creadores en tu zona horaria responde en 20 minutos.

No es chovinismo. Es eficiencia. Si tu mercado es hispanohablante, todo tu stack — incluido el boilerplate — debería serlo también. Es por eso por lo que existe IndiePack: nada de "traducción literal de ShipFast", sino diseñado desde cero pensando en cómo trabajamos los indies de habla hispana.

Qué buscar (y qué evitar) en un boilerplate

No todos los boilerplates son iguales. Antes de pagar uno, comprueba estas señales:

✓ Señales de que merece la pena

• Stack reciente y mainstream. Next.js 15+, TypeScript estricto, Tailwind v4. Evita boilerplates que llevan 18 meses sin actualizar la versión mayor.
• El creador lo usa en producción. Si quien lo vende no tiene apps reales con usuarios pagando, ese boilerplate es teoría. Pide ver los proyectos.
• Pago único + actualizaciones de por vida. Suscripciones por usar un boilerplate son una señal mala.
• Comunidad activa. Discord o similar, con preguntas y respuestas recientes.
• Stripe Y LemonSqueezy. Stripe es más flexible, LemonSqueezy se encarga del IVA por ti. Un buen boilerplate soporta ambos.
• i18n nativo. Aunque solo vendas en un idioma hoy, mañana puede no ser así.

✗ Señales de huida

• "Auth opcional, $99 extra". Si la auth es un addon, no es un boilerplate completo.
• Demo bonita pero código de mala calidad. Pide acceso al repo antes de comprar si puedes.
• Stack experimental. Boilerplates con frameworks de 2 meses son una bomba de tiempo.
• Cero referencias visibles. Si nadie de tu red lo recomienda, sospecha.

Boilerplate vs. aprender desde cero

Hay un argumento que oigo mucho: "Pero si uso un boilerplate, no aprendo".

Es una falacia. Mira:

• Aprender Stripe configurándolo de cero te ahorra el coste del boilerplate, pero te roba 20 horas de un fin de semana. Coste real: 20 horas de tu vida.
• Aprender Stripe leyendo el código ya integrado de un boilerplate decente te lleva 2 horas y aprendes mejor — porque ves cómo se integra con todo lo demás, no solo el flujo del happy path de la doc oficial.

El "tutorial" de Stripe es el checkout/route.ts del boilerplate, comentado y conectado a tu DB. Aprendes más leyendo eso una tarde que con 3 cursos en Udemy.

Cuándo NO usar un boilerplate

Hay casos en los que sí merece la pena empezar de cero:

• Tu producto NO es un SaaS estándar. Si haces un juego, un editor visual o algo que no encaja con auth + dashboard + pagos, un boilerplate te estorba más que te ayuda.
• Necesitas un stack muy específico. Si vives en Django, Rails o Phoenix, no fuerces Next.js solo porque el boilerplate exista.
• Estás aprendiendo desde cero y tienes meses. Si es tu primer proyecto y quieres aprender fundamentos, hazlo manualmente la primera vez. La segunda, ya con boilerplate.
• Tu empresa tiene equipo y senior devs. A escala, los boilerplates limitan más de lo que aportan.

Pero si eres un indie hacker hispanohablante intentando lanzar productos rápido — el caso para el que existe IndiePack — el boilerplate no es opcional, es el punto de partida sensato.

Conclusión

Configurar lo aburrido desde cero es una de esas cosas que parecen nobles ("estoy aprendiendo") pero que en realidad son la forma más cara de gastar tu tiempo de indie. Lo aburrido es aburrido porque es genérico. Y lo genérico se resuelve una vez, no cada vez.

Un boilerplate Next.js + Supabase bien hecho — y en castellano si tu mercado lo es — te entrega 40-60 horas de tu vida ya gastadas por otro y revisadas en producción. A cambio de un pago único, te quedas con el tiempo para hacer lo único que importa: el producto que sí va a diferenciarte.

Si te ha convencido, aquí está IndiePack. Si no, te animo a hacerte el cronómetro la próxima vez que arranques un proyecto — y vuelvas a este post cuando lleves 50 horas y aún no tengas usuarios.