Qué te da un boilerplate de SaaS, y qué vas a tener que construir igual

Un boilerplate de SaaS te da las partes que son idénticas en todos los SaaS, como autenticación, cobros, un panel de administración, internacionalización y CI/CD, y ninguna de las partes por las que alguien va a pagarte. El trato suele valer la pena, pero solo si sabes exactamente dónde cae la línea antes de comprar. CastorStack es la implementación de referencia usada abajo.

Qué viene realmente construido

Una base lista para producción trae la fontanería que tiene una sola respuesta correcta y ninguna diferenciación de producto:

• Autenticación: registro, inicio de sesión, recuperación de contraseña, manejo de sesión y rutas protegidas en todos los frontends. En CastorStack esto va sobre Supabase, con la sesión validada del lado del servidor por la API en vez de confiar en el cliente.
• Cobros conectados de punta a punta. No un campo para la clave de Stripe, sino un endpoint de checkout real, manejadores de webhooks firmados, y los registros de acceso que esos webhooks escriben. CastorStack trae Stripe y Paddle, con una regla de enrutamiento por país que decide por cuál pasa cada comprador.
• Un modelo de productos y precios: productos, planes, funcionalidades y sus vínculos, editables desde un panel en vez de constantes esparcidas por el código.
• Un panel de administración con búsqueda de usuarios, estado de suscripciones, configuración de proveedores de pago, feature flags y registros de auditoría.
• Internacionalización: enrutamiento por idioma, archivos de traducción y selector de idioma en cada app. Agregar i18n después del lanzamiento es una de las refactorizaciones más miserables del desarrollo web.
• Estructura de tests y despliegue: tests unitarios en los frontends, tests de API en el backend, tests end-to-end sobre ambos, y un pipeline que los ejecuta.

El hilo conductor: cada elemento es algo que habrías construido igual, y cada elemento es algo que la primera vez te habría salido sutilmente mal. La idempotencia de los webhooks, las condiciones de carrera al refrescar la sesión, y la diferencia entre "el pago se aprobó" y "el acceso se otorgó" son la clase de bug que aparece en producción, a costa de un cliente.

Qué vas a tener que construir igual

Todo lo que es el producto.

Ningún boilerplate sabe qué hace tu aplicación. El panel es una cáscara, la funcionalidad de ejemplo es un ejemplo. Aquí se va todo tu tiempo restante, y de eso se trata.

Las decisiones de precio siguen siendo tuyas. El modelo soporta planes y restricciones por funcionalidad; decidir que el plan Pro incluye 10.000 llamadas y el gratuito 100 es una decisión de negocio que el código no puede tomar por ti.

El correo transaccional, es decir recibos, fin de prueba y reintentos de cobro, depende de un proveedor que eliges y de textos que escribes.

Tu postura de cumplimiento también es tuya: solicitudes de exportación y borrado de datos bajo el RGPD, un acuerdo de tratamiento de datos, una política de cookies que coincida con lo que realmente cargas. Una plantilla puede dejar los ganchos; no puede cumplir en tu nombre.

Las respuestas operativas, igual. ¿Qué pasa cuando un pago falla tres veces? ¿Cuando alguien baja de plan a mitad de ciclo? ¿Cuando piden reembolso después de usar el producto 29 días? El webhook que trae el evento existe. La política es tuya.

Y el diseño. Una base trae un lenguaje visual coherente y neutro. Que parezca tu producto es trabajo.

El modo de fallo honesto

El modo de fallo de comprar un boilerplate no es que el código sea malo. Es comprar uno cuya arquitectura no quieres habitar.

Estás heredando las decisiones de otra persona sobre framework, base de datos, proveedor de autenticación, estructura de carpetas y destino de despliegue. Si esas decisiones coinciden con las que habrías tomado, te ahorras semanas. Si no, vas a gastar esas mismas semanas peleándote con la plantilla, y te habría convenido empezar de cero.

Así que la pregunta de compra no es "¿tiene la funcionalidad X?". Es si lo habrías construido así. Lee la estructura del repositorio y uno o dos módulos reales antes de pagar. Si el código te encaja en diez minutos, va a seguir encajándote en el mes seis.

El segundo modo de fallo es quedarse viejo. Una base es una foto de las versiones de dependencias del día que salió. Fíjate cuándo se actualizó por última vez y si las actualizaciones vienen incluidas, porque un boilerplate que no puedes actualizar se vuelve deuda técnica con recibo de compra.

Cómo decidir

Un boilerplate vale la pena cuando:

• Ya construiste esta capa antes y sabes con precisión cuánto te lleva.
• El stack coincide con aquel en el que ya trabajas.
• El valor de tu producto está en el dominio, no en la infraestructura.

No vale la pena cuando:

• Tu producto es infraestructura, y las decisiones del boilerplate chocan con eso.
• Estás aprendiendo el stack. Vas a aprender más, y más rápido, desde un proyecto vacío.
• Tus requisitos son lo bastante inusuales como para que la capa genérica esté mal de todos modos (multi-tenant con base de datos por cliente, despliegue on-premise, residencia de datos regulada).

El número realista

Construir bien la capa descrita arriba, no como demo, sino con reintentos de webhook, manejo de impuestos, reembolsos, panel de administración y tests, le lleva a una persona con experiencia entre cuatro y ocho semanas. Decir que es "un fin de semana con un agente de IA" es marketing; la demo sale en un fin de semana, la versión lista para producción no.

Ese rango es el valor real de un boilerplate. Todo lo que viene después es tu trabajo.