La frase que mata más productos no es una decisión estratégica, es una concesión pequeña dicha en una reunión: «para este cliente es solo un cambio chiquito en el código». Suena inofensivo y hasta generoso. Pero el día que existe una versión del código por cliente, el producto se murió y quedó, sin que nadie lo anuncie, un negocio de servicios con precio de producto. Esta es la distinción que decide si puedes vender la misma solución veinte veces con margen, o si cada venta nueva te compra un mantenimiento eterno.
La idea que ordena todo: configuración, nunca código. Todo lo que distingue a un cliente de otro (su catálogo, sus precios, sus zonas, sus horarios, su tono, sus reglas) tiene que vivir en configuración, no en una rama del programa. Si vender otra vez obliga a tocar una línea de código, no tienes un producto, tienes un desarrollo a medida que estás cobrando como si fuera producto.
¿Qué diferencia un producto de un desarrollo a medida?
Dónde vive la diferencia entre clientes. En un producto, todo lo que cambia de un cliente a otro está en configuración y el código es idéntico para todos. En un desarrollo a medida, cada cliente tiene su versión del código. La consecuencia es económica: una mejora llega a todos a la vez, o hay que aplicarla cliente por cliente.
| Qué es | Dónde debe vivir |
|---|---|
| Catálogo, precios, zonas, horarios | Configuración |
| Tono, textos, reglas del negocio | Configuración |
| Datos de pago y credenciales | Configuración (por cliente, aislada) |
| La lógica que resuelve el problema | Código, idéntico para todos |
| Una excepción «solo para este cliente» | En ningún sitio: o es configuración, o es producto |
La última fila es la difícil, y es donde se pierde el producto. Cada excepción que se resuelve tocando el código parece barata el día que se hace y se cobra durante años. Vamos a la aritmética.
La aritmética que mata el margen
El costo de bifurcar el código no se paga al bifurcarlo, se paga en cada cosa que ocurra después. Con una sola base de código, arreglar un fallo cuesta una vez y todos tus clientes quedan arreglados; mejorar algo cuesta una vez y todos mejoran. Con una versión por cliente, cada fallo existe en tantas versiones como clientes tengas, y cada mejora hay que portarla, probarla y desplegarla una por una.
Eso convierte tu mantenimiento en una función que crece con las ventas, que es exactamente lo contrario de un producto. En un producto, el cliente número veinte casi no añade trabajo de mantenimiento; en un desarrollo bifurcado, el cliente número veinte añade una vigésima parte más de todo, para siempre. El síntoma financiero es inconfundible: vendes más y trabajas más sin que el margen mejore, hasta que el equipo se pasa la vida sosteniendo veinte variantes y nadie tiene tiempo de construir nada nuevo.
Y hay un efecto secundario peor que el costo: el miedo. Cuando existen muchas versiones, nadie se atreve a tocar el núcleo, porque no se puede saber qué rompe en cuál. El producto deja de evolucionar, no por falta de ideas, sino porque cambiarlo se volvió peligroso.
Cómo se hace en la práctica
La técnica es más simple de lo que parece y se sostiene en tres decisiones.
Un solo objeto de configuración, validado. Toda diferencia entre clientes vive en un objeto de configuración con un esquema estricto que lo valida. Un esquema no es burocracia: es lo que te avisa cuando alguien intenta meter una diferencia que el producto no contempla, que es justo el momento en que hay que decidir si eso es configuración o es una función nueva del producto para todos.
Defaults seguros ante configuración inválida. Si la configuración de un cliente llega mal, el sistema cae a valores por defecto en lugar de reventar. Esto importa más de lo que parece: un producto multi-cliente donde un error de configuración tumba la operación de alguien es un producto frágil. Que degrade a algo razonable es lo que permite dormir tranquilo, con la misma lógica de diseñar para que las fallas sean baratas.
Se copia comportamiento, nunca datos. Al dar de alta un cliente nuevo se puede clonar el comportamiento de uno existente (sus reglas, su estructura, sus flujos) pero jamás su catálogo, sus precios ni sus datos de pago. Es una distinción que parece obvia escrita y que se viola con facilidad al buscar atajos, con consecuencias graves: un cliente cobrando con la cuenta de otro es el peor error posible de un sistema multi-cliente.
El alta de un cliente como guion del onboarding
Hay una prueba de fuego para saber si tienes un producto: ¿puedes dar de alta un cliente nuevo con un solo procedimiento repetible? Si la respuesta es un comando que crea todo (el cliente, su configuración, su estructura, su acceso) en una sola operación que o queda completa o no queda nada, tienes un producto. Si la respuesta es «depende del cliente» o una lista de pasos manuales que cambian cada vez, todavía no.
Y ese procedimiento tiene un valor extra que casi nadie ve: es, literalmente, el guion de la pantalla de onboarding que algún día vas a construir. Cada parámetro que pide el alta es un campo de ese formulario futuro. Escribirlo bien hoy no es solo eficiencia operativa, es diseñar el producto que vas a poder vender sin ti.
Los límites honestos: qué queda manual y por qué
Ningún alta es cien por ciento automática, y aquí es donde conviene ser riguroso con uno mismo. En el sistema que construí quedan pasos manuales: crear una cuenta en una plataforma externa, conectar un canal que pasa por aprobación de un tercero, someter unas plantillas a revisión. La diferencia entre deuda técnica y límite real es que cada uno de esos pasos está verificado contra la interfaz real del proveedor, con fecha, y documentado por qué no se puede automatizar todavía.
Esa distinción importa porque protege de dos errores opuestos. Uno es llamar «límite» a lo que solo es pereza, y quedarse con procesos manuales evitables. El otro es automatizar a ciegas un paso que no se puede verificar: si puedes crear algo por interfaz de programación pero no puedes comprobar que quedó bien creado, automatizarlo es peor que hacerlo a mano, porque cambias dos minutos de trabajo por un fallo silencioso. Documentar el límite con su fecha convierte una decisión en algo revisable cuando el proveedor cambie.
Cuándo SÍ conviene el desarrollo a medida
El matiz honesto: hay casos donde el desarrollo a medida es la respuesta correcta, y confundirlos con un producto también sale caro. Si vas a resolver el problema de un solo cliente, con reglas que nadie más comparte, y no tienes intención de venderlo otra vez, montar toda la maquinaria de configuración y esquemas es sobreingeniería: hazlo a medida, cóbralo como tal y listo. Y si un cliente grande necesita algo genuinamente único y está dispuesto a pagar el desarrollo y su mantenimiento, es un negocio legítimo, siempre que lo cobres como proyecto y no como licencia. El error no es hacer trabajo a medida, es hacerlo mientras te dices que estás vendiendo un producto: ahí es donde el precio no cubre el costo real y el margen desaparece sin que nadie sepa por qué. Decide qué estás vendiendo y cóbralo en consecuencia.
Errores comunes al construir para varios clientes
- La excepción «chiquita» en el código: el primer if con el nombre de un cliente dentro. Es el momento exacto en que el producto empieza a morir.
- Configuración sin validación: permitir cualquier valor y descubrir el error en la operación de un cliente. El esquema es el que avisa a tiempo.
- Clonar datos al dar de alta: copiar catálogo, precios o datos de pago de otro cliente. Se copia comportamiento, nunca datos.
- Alta manual y distinta cada vez: sin un procedimiento repetible no hay producto, hay un servicio artesanal con nombre de software.
- Cobrar como producto lo que operas como proyecto: el error económico de fondo. Si cada cliente cuesta un desarrollo, el precio tiene que reflejarlo.
El caso donde esta frontera se decidió antes de que alguien construyera: un SaaS multi-tenant sobre GoHighLevel, con el cliente anonimizado y las cifras medidas.
Preguntas frecuentes
Pregúntate qué hace falta para vender la misma solución a un cliente nuevo. Si es cargar una configuración y ejecutar un procedimiento repetible, tienes un producto. Si hay que tocar el código, aunque sea «un poquito», tienes un desarrollo a medida. La prueba complementaria es el mantenimiento: si arreglar un fallo beneficia a todos tus clientes a la vez, es producto; si hay que aplicarlo cliente por cliente, no lo es.
Convergir, empezando por lo más repetido. Identifica qué diferencias reales existen entre versiones y clasifícalas: la mayoría suelen ser datos o parámetros que pueden pasar a configuración sin drama, y solo unas pocas son comportamiento genuinamente distinto. Esas pocas se resuelven volviéndolas una opción del producto, disponible para todos. Es trabajo, pero cada versión que eliminas te devuelve capacidad de evolucionar el núcleo sin miedo.
Con un solo cliente, casi. Con tres, ya te está salvando. El esquema hace dos cosas que valen más de lo que cuestan: impide que una configuración mal escrita rompa la operación de alguien, y te avisa cuando estás intentando meter una diferencia que el producto no contempla, que es justo la conversación que hay que tener antes de bifurcar el código. Es barato de agregar temprano y caro de retrofitear tarde.
Su comportamiento sí, sus datos nunca. Clonar reglas, estructura y flujos acelera el alta y transmite todo lo aprendido; clonar catálogo, precios o datos de pago es un riesgo grave, porque un cliente operando con la información comercial de otro es un incidente serio y difícil de detectar. La separación tiene que estar explícita en el procedimiento de alta, no depender de que quien lo ejecute se acuerde.
Tienes tres respuestas honestas y ninguna es tocar el código para él solo. Puede ser una función nueva del producto, disponible para todos y priorizada como tal. Puede ser una configuración que aún no existe y conviene agregar al esquema. O puede ser un proyecto a medida aparte, cobrado como proyecto con su mantenimiento. Elegir cualquiera de las tres conserva el producto; la cuarta opción, la excepción silenciosa en el código, es la que lo mata.
Principio verificado construyendo un sistema multi-cliente en producción, a julio de 2026. El caso va anonimizado por confidencialidad del cliente. Si estás construyendo algo que quieres vender muchas veces y necesitas que siga siendo un producto, ese diseño es parte de lo que hago; hablemos en contacto.
La idea que conserva el producto
Un producto no se define por su tecnología ni por su precio, se define por dónde vive la diferencia entre un cliente y el siguiente. Mientras esa diferencia esté en configuración, cada venta nueva casi no añade trabajo y cada mejora llega a todos; el día que esté en el código, cada venta compra mantenimiento eterno y el núcleo se vuelve intocable por miedo. La disciplina se resume en una regla que conviene decir en voz alta cuando aparezca la tentación: si vender otra vez obliga a tocar el código, deja de ser un producto. Y esa decisión, como la modularidad o el orden en que se toman las decisiones, no se arregla después: se toma antes de la segunda venta, que es cuando todavía es gratis.
Y si la pregunta es quién construye eso, el criterio para elegir proveedor es el mismo criterio de producto: cuántas decisiones sigues tomando tú y cuántas estás comprando.
