Qué es Sushi SaaS
Qué incluye el starter, qué decisiones de producto toma y cómo decidir si adoptar todo o solo una parte.
Sushi SaaS es un starter de código fuente, con licencia MIT, para productos de suscripción y pago por uso. No es una plataforma alojada ni genera una aplicación a partir de un formulario. Clonas el repositorio, eres responsable del código resultante y adaptas sus decisiones de producto a tus usuarios.
¿Documentación o Guías?
Usa Documentación cuando ya conoces la tarea y necesitas pasos exactos para configurar, ampliar, verificar u operar el código publicado. Usa Guías cuando decides si una elección encaja, por qué Sushi la hizo y qué conservar, cambiar o eliminar. Son dos momentos del mismo recorrido de adopción.
Para quién es
Valora Sushi SaaS si eres desarrollador o formas parte de un equipo pequeño que ya se inclina por Next.js, TypeScript, PostgreSQL, Drizzle, Better Auth y Stripe. Aporta más valor cuando el producto también necesita organizaciones, créditos compartidos, cargas privadas, trabajos en segundo plano, interfaz localizada y consola de operaciones.
Elige una base menor si solo validas una landing page, creas una herramienta para un único usuario sin cobros o piensas sustituir casi toda esa pila. Empezar con menos contratos sale más barato que borrar contratos que nunca quisiste.
Qué incluye
El repositorio contiene tres aplicaciones desplegables y un worker portable:
- la app cliente en
src/app, con auth, organizaciones, cobros, créditos, storage privado, reservas y tareas de pago de referencia; apps/admin, con MFA, roles, recuperación de jobs, moderación, conciliación, cobros y auditoría;apps/content-studio, una aplicación Payload con base y autenticación editorial propias;- un worker durable que funciona junto a VM/contenedores o mediante scheduler.
Web y admin comparten esquema y auth SaaS; Content Studio nunca. Identidad, consentimiento y auditoría de entrega permanecen en el SaaS. El sitio público es un cuarto repositorio desacoplado.
Decisiones que heredas
| Elección incluida | Por qué se eligió | Cuándo revisarla |
|---|---|---|
| Capas horizontales ruta → servicio → modelo → base de datos | Mantiene las reglas de negocio y consultas en lugares previsibles | El equipo ya adoptó otra arquitectura y actualizará también sus tests de cumplimiento |
| Cada cuenta posee o integra una organización | Da a cobros, archivos, créditos y límites una única frontera de tenant | El producto es realmente de un solo tenant y vas a retirar el alcance por organización de extremo a extremo |
| Los eventos de Stripe finalizan el estado de cobro | Trata los reintentos y webhooks tardíos como entradas normales | Tu proveedor o modelo comercial es distinto |
| Despliegue de admin separado | Aísla el acceso de operadores de la navegación del cliente | Las operaciones son bastante simples para compartir aplicación y frontera de despliegue |
| Cinco locales de producto | Permite localizar interfaz y errores visibles | Mantienes menos idiomas y retiras sus rutas, catálogos y tests a la vez |
Son valores predeterminados, no una afirmación de que todo SaaS deba decidir igual.
Tres formas de adoptarlo
- Usar toda la base. Conserva las fronteras, sustituye marca y ejemplos de producto, y configura proveedores y políticas.
- Usar patrones concretos. Copia una idea autocontenida—como la libreta de créditos o el manejo de reintentos de Stripe—junto con sus migraciones, tests y reglas operativas.
- Usarlo como referencia. Compara sus fallos e invariantes con tu sistema sin adoptar el código.
Evita una migración a medias con dos arquitecturas o modelos de tenancy: cada cambio nuevo tendría dos lugares aparentemente correctos.
Lo que sigue siendo tu responsabilidad
El starter no puede decidir precios, reembolsos, retención de datos, términos legales, soporte, objetivos de backup, controles antifraude ni modelo de amenazas. Las recompensas por recomendación están desactivadas porque el pago exige decisiones comerciales y de cumplimiento. El proveedor de texto a vídeo y el flujo de reservas son ejemplos de integración, no una propuesta de producto terminada.
Una evaluación práctica
- Sigue Inicio rápido y abre las aplicaciones de cliente y admin.
- Traza un flujo que realmente necesites—registro, Checkout, carga o gasto de créditos—desde la ruta hasta la base de datos.
- Lee Cuándo encaja Sushi SaaS y enumera qué decisiones conservarás, cambiarás o retirarás.
- Revisa Despliegue y seguridad antes de estimar el trabajo de producción.