Una base sobre la que construir.

El trabajo que cada producto repite

Un producto nuevo empieza con un problema particular. Sus primeras semanas suelen parecer mucho menos particulares: sesiones, registros de espacio, estado de suscripción, trabajo en segundo plano y entrega de email. Estas piezas deben cooperar antes de que el producto pueda hacer algo útil — cada una es un problema resuelto en abstracto y un riesgo de integración en concreto.

supastack da un hogar a ese trabajo repetido. Una app web Next.js y una app móvil Expo comparten paquetes TypeScript para la infraestructura subyacente. El objetivo es hacer esos límites lo bastante comprensibles para que un producto los configure sin heredar el modelo de dominio de otro.

Ninguna de las piezas es difícil en aislamiento. El coste vive en su coordinación — un pago que debe convertirse en un permiso, una sesión que debe convertirse en un ámbito de espacio, una tarea que debe sobrevivir a un portátil cerrado. Los productos rara vez fallan por una función que falta. Fallan en una unión.

Por qué construirlo una vez, bien

El argumento de la infraestructura compartida no es que el trabajo te quede pequeño — es que el trabajo repetido merece hacerse una vez, con cuidado. Una frontera de espacio bien implementada en un módulo compartido protege cada producto construido sobre ella. La misma frontera improvisada por producto se convierte en un conjunto de casi-aciertos que difieren de formas interesantes y peligrosas.

También concentra el mantenimiento. Las API de proveedores cambian, las librerías de auth evolucionan, la semántica de facturación deriva. Cuando esos cambios aterrizan en un solo lugar — la documentación de módulos del kit los sigue — una corrección se propaga en lugar de reaprenderse por proyecto. Y cuando sopesas el intercambio para un solo producto, ¿starter kit o desde cero? aplica el mismo razonamiento a la decisión de comprar o construir.

La infraestructura compartida también concentra la revisión. Una frontera que vive en un solo lugar puede probarse a fondo una vez — casos negativos, eventos repetidos, intentos entre tenants — en lugar de esperar que cinco reimplementaciones acertaran cada una. Es parte de por qué el kit invierte en su suite de tests: mantener la confianza en código compartido es más barato que recuperarla por proyecto.

Da a cada módulo una responsabilidad

La identidad establece quién hace una petición. Los espacios de trabajo determinan a qué registros puede acceder esa persona. La facturación registra el estado de pago, mientras los permisos responden si una capacidad está disponible. Mantener estas preocupaciones separadas evita que una redirección de pago exitosa se convierta en una decisión de autorización.

La misma disciplina se aplica al trabajo en segundo plano. El contrato JobRunner compartido promete enqueue, status y cancel. Trigger.dev posee el comportamiento de workflow. Una interfaz pequeña tiene valor cuando sus límites son visibles; ocultar reintentos o programación tras un método genérico haría el sistema más difícil de razonar.

Better Auth responde la identidad. Postgres y Drizzle guardan los registros. Stripe o Lemon Squeezy reportan el estado de pago. A ninguno se le pide ser listo con el trabajo de otro módulo — las uniones se quedan lo bastante estrechas para razonar sobre ellas — y una base solo es tan fiable como sus uniones.

Deja espacio para el producto

Un flujo de clientes potenciales, un editor de documentos y un asistente de investigación pueden usar los mismos módulos de identidad y facturación. Sus registros, lenguaje y flujos siguen siendo diferentes. La lógica propia del producto pertenece al codebase consumidor, con la configuración que lo vincula a la base.

Esa separación es también una decisión práctica de mantenimiento. Una corrección de aislamiento de espacios debería ser reutilizable. Un cambio en cómo un producto evalúa un cliente potencial no debería convertirse en un nuevo requisito para todos los demás productos.

Esa es la diferencia entre una base y un tema. Un tema te da un aspecto que conservar o reemplazar. Una base te da decisiones estructurales — quién posee la identidad, cómo se delimitan los registros, dónde un pago se convierte en acceso — sobre las que un producto construye en lugar de rodear. La guía de estructura de proyecto muestra dónde termina una y empieza la otra.

Empieza por un flujo completo

Comienza con el flujo de referencia local: inicia sesión, inspecciona el acceso, envía una tarea y lee su resultado. Los adaptadores fake y locales permiten que tests deterministas ejerciten el camino sin peticiones de pago a proveedores — el quickstart de cinco minutos lo ejecuta de punta a punta. Configura después las integraciones de producción que tu producto realmente necesita.

La aceptación local y la de producción responden preguntas diferentes. Un test local que pasa establece el comportamiento de la aplicación en condiciones controladas. La persistencia real de auth, la entrega de proveedores, el despliegue y el comportamiento en dispositivo aún necesitan su propia verificación. Mantén esa distinción visible a medida que el producto crece.

Una base se gana su nombre despacio: en el segundo producto que sale más rápido que el primero y en el día de mantenimiento que arregla un módulo en lugar de cinco codebases. Esa es la apuesta detrás de supastack — y el listón al que se mide cada módulo.

Preguntas detrás del enfoque

Algunas preguntas subyacen a este enfoque, y merecen una respuesta clara.

• ¿Es supastack una plantilla o un framework? — Una base de módulos con contratos entre ellos. El código de producto vive fuera de Starter Core y se conecta mediante configuración, así que la plataforma puede actualizarse sin bifurcar tus funciones.
• ¿No hará la infraestructura compartida que los productos sean genéricos? — Solo la fontanería es compartida. Los registros, los flujos y el lenguaje quedan en el codebase del producto — las partes que los clientes pueden ver siguen siendo tuyas.
• ¿Dónde empieza el código propio del producto? — Con los registros y flujos que solo él tiene. La base autentica al usuario y delimita los datos; no sabe lo que es un cliente potencial.
• ¿Por qué un monorepo? — Para que las apps web, móvil y escritorio cambien junto a los paquetes de debajo: un solo sistema de tipos, una sola puerta de tests, sin deriva entre repositorios.
• ¿Y si solo necesito la app web? — La base es la compra; móvil y escritorio son superficies que adoptar o ignorar. Nada te obliga a entregar una app que no necesitas.