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
- Un código, muchos clientes: la frontera entr
- Los tres mecanismos, uno por uno
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.
Los tres mecanismos, uno por uno
De la diferencia al mecanismo correcto
1. Parametrización
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.2. Multiempresa (multi-tenant)
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).3. Plantillas
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.4. El techo sano de la configuración
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.
Paso 1 de 4
| 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.
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.
Tu texto se guarda sólo en este dispositivo.
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.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.