Un código, muchos clientes: la frontera entre servicio y producto

Mapa conceptual

# Parametrización, multiempresa y plantillas
## Un código, muchos clientes: la frontera entr
## Los tres mecanismos, uno por uno

Admisión Servicio Social 1954 reverso.png — Imagen libre de Wikimedia Commons (Public domain, autor: Falange Española Tradicionalista y de las JONS)

Mientras cada cliente te obligue a copiar el proyecto y modificarlo, sigues en modo servicio: cada venta multiplica tu carga de mantenimiento. El producto empieza cuando las diferencias entre clientes dejan de vivir en el código y pasan a vivir en la configuración. Piénsalo así: el motor (el flujo, el objeto de datos, la lógica) es uno y idéntico para todos. Lo que cambia —el logotipo, los nombres de los campos, las reglas de notificación, a quién se le cobra— se lee de un lugar aparte. Ese 'lugar aparte' tiene tres nombres que vas a dominar en este objeto: parámetros, aislamiento por empresa y plantillas.

La regla de las tres preguntas Antes de tocar el código para un cliente nuevo, pregúntate: ¿esto es un valor que cambia por empresa (→ parámetro)? ¿un conjunto de datos que no debe mezclarse (→ aislamiento)? ¿una apariencia o estructura repetible (→ plantilla)? Si ninguna aplica, quizá sí es código nuevo, y ahí tu producto aún no llega.

Los tres mecanismos, uno por uno

De la diferencia al mecanismo correcto

Convierte en **variables leídas desde fuera** todo lo que cambia por cliente: nombre de la empresa, correo remitente, moneda, límites de uso, reglas de negocio simples. Un nuevo cliente es una fila de configuración, no un fork del código.
Cada registro lleva una **etiqueta de empresa** y toda consulta la filtra. Los datos del cliente A jamás deben verse en la pantalla del cliente B. Es el requisito no negociable del que hablamos en el curso de producto (privacidad y roles).
Lo que se repite con forma —un formato de reporte, un correo, un tablero— se guarda como **plantilla editable**, no quemado en la interfaz. El cliente personaliza sin que tú recompiles.
No parametrices todo: una configuración infinita es código disfrazado y se vuelve inmantenible. Parametriza lo que **de verdad piden varias empresas**; lo raro, se resuelve con un plan premium o se dice que no.

Elegir el mecanismo equivocado es lo que convierte tu "producto" en veinte servicios disfrazados.
Lo que cambia por cliente	Mecanismo correcto	Antipatrón (señal de que sigues en servicio)
Correo remitente y logotipo	Parámetro de configuración	Editar la plantilla en el código por cliente
Ver solo sus propios tickets	Aislamiento multiempresa por etiqueta	Una base de datos copiada por cliente
Formato de su reporte mensual	Plantilla editable	Programar el reporte a la medida
Límite de consultas a la IA	Parámetro con techo y alerta de costo	Dejarlo sin límite y sorprenderse de la factura
Un requisito rarísimo de un solo cliente	Decir que no, o cobrarlo como proyecto	Contaminar el producto con una función que nadie más usa

Llega un cliente 4 y tu instinto es "copiar la carpeta del cliente 3, renombrarla y cambiar el logotipo en el código". ¿Qué revela ese instinto?

En una arquitectura multiempresa bien hecha, basta con que cada usuario tenga su contraseña para garantizar que no verá datos de otra empresa.

Toma tu candidato a producto del objeto anterior y enumera tres cosas que cambian entre tus clientes. Junto a cada una, escribe si sería un parámetro, un tema de aislamiento por empresa o una plantilla.

Pista

Si descubres que casi todo sería código distinto, tu "producto" todavía es un servicio: te falta parametrizar el núcleo común.

Siguiente paso: Proyecto: plan de servicio a producto — vas a escribir el plan concreto para convertir tu repetidor en un producto parametrizado, con precios, usuarios y soporte.

Sigue: Detectar el patrón entre proyectos de clientes
Objeto de la misma ruta para continuar aprendiendo.

Sigue: Proyecto: plan de servicio a producto
Objeto de la misma ruta para continuar aprendiendo.