Hace algunos años me ficharon en una scale-up española con un mandato tan ambicioso como vago: “organizar la casa”. En teoría significaba profesionalizar el equipo, adoptar buenas prácticas y escalar la plataforma a nuevos mercados (Europa, México y Colombia). En la práctica descubrí un Frankenstein de código: ifs y elses por doquier —en el front, en el back, en las apps móviles y hasta en la capa de infraestructura— que obedecían a peticiones específicas de clientes concretos. Cada vez que abríamos un archivo aparecía un comentario tipo:
Imagina ese patrón repetido centenares de veces. El resultado era un sudoku de reglas de negocio tan particularizado que nuestro equipo de customer support tenía que memorizar cientos de combinaciones para resolver dudas cotidianas, y los desarrolladores maldecían cada vez que tocaban cualquier módulo por miedo a romper “esa cosa que solo usa el Cliente D los días pares”.
El costoso espejismo de la “gran cuenta”
Es tentador —sobre todo en fases tempranas— aceptar una feature personalizada para cerrar al “cliente soñado”. Parece un trato inofensivo: solo un ajuste más y la facturación sube mañana. Pero la realidad es un iceberg: lo que firma el comercial en media hora se convierte en meses —o años— de complejidad técnica, deuda de diseño y fricción operativa.
En mi caso, esa dinámica se había consolidado como rutina: vender primero, preguntar después. Cuando llegué, la plataforma ya arrastraba un centenar largo de comportamientos especiales, casi todos hard-coded. Aquella “flexibilidad” había generado ingresos individuales, sí, pero colectivamente era un lastre que ralentizaba todo el roadmap.
Los mismos vendedores que vendían cosas “custom” eran los primeros a decir que nuestro equipo de producto era demasiado lento. No les culpo, al final eso era reflejo del ambiente en que estaban y la cultura que se había formado en la empresa.
Costes inmediatos que no están en la hoja de Excel:
Velocidad de desarrollo: cualquier nueva funcionalidad debía probarse contra un árbol de casuísticas infinito. Íbamos lentos no por falta de talento, sino por la maraña de condicionales. Calidad de soporte: los agentes tenían que recordar quién tenía qué variante del proceso de check-in, qué informe concreto descargaba cada uno… El onboarding de un nuevo compañero podía tardar meses. Atracción y retención de talento: a nadie le motiva pelear con código espagueti escrito para apagar fuegos. Cada fuga de ingenieros sénior añadía presión sobre los que resistían. Escalabilidad internacional: lanzar país nuevo implicaba auditar todas las excepciones para asegurar que ninguna chocaba con legislación local. A menudo el bloqueo no era técnico sino de compliance.
La trampa del “cliente rey”
El problema no era solo técnico, era cultural. El equipo de ventas y el de customer experience habían aprendido que “el cliente siempre tiene razón” significaba “decir sí a cualquier capricho”. Cuando propuse frenar esa dinámica, muchos me vieron como el malo de la película: “¿Cómo vamos a decirle no a quien paga la factura?”.
Aquí descubrí el coste de capital social de rectificar malas decisiones pasadas. Convencer a un cliente de renunciar a su atajo favorito es difícil; convencer al account manager que cobró la comisión, aún más. Reuniones interminables, correos de “urgencia máxima” y la sensación de que cada no erosionaba la relación. Sin embargo, el riesgo de seguir igual era mucho mayor: morir de éxito.
La hoja de ruta para salir del laberinto
Bloquear nuevas personalizaciones: A partir de ese momento por más que un cliente nos pedia algo, creábamos una feature estándar en el producto, con parámetros de configuración, sin ifs y elses en código. Cartografiar el territorio: Construimos un inventario exhaustivo de excepciones: qué hacían, por qué existían, cuántos usuarios los usaban realmente y qué revenue generaban. Descubrimos que el 80 % de los casos especiales afectaba a menos de un 10% de la facturación*. Los datos fueron clave para despersonalizar la conversación: no era “el capricho de Marketing”, era un ratio coste/beneficio insostenible. Agrupar patrones: Empezamos a conocer y entrevistar a eses clientes, para entender porque necesitaban esas features y como lo usaban. Definir una política de producto: Redactamos un documento breve —y público— que dictaba cuándo se consideraría una petición “core” (beneficia al 80 % de los clientes), “configurable” (se resuelve con parámetros disponibles) o “especial” (no se atiende). Esa claridad quitó presión a los equipos de cara al cliente. Negociar con transparencia: Para cada cliente con dependencias críticas diseñamos un plan de transición: fechas concretas, acompañamiento y, en algunos casos, features de reemplazo incluso mejores. Algunos se fueron, es cierto. Pero los que se quedaron ganaron un producto más robusto y homogéneo. Celebrar las negaciones: Reforzamos internamente la idea de que decir no también es parte del valor que aportamos. Cada petición rechazada ahorraba decenas de horas futuras. Lo medimos y lo comunicamos.
Resultados (y cicatrices)
Para ser totalmente honesto, no alcanzamos a extinguir todas las llamas, pero sí encendimos la ruta de evacuación adecuada. Empezamos por lo más crítico: refactorizar el flujo de checkout. La misión era clara: arrancar el código no escalable y construir un cimiento que nos permitiera vender en varios países sin arrastrar la losa de las customizaciones heredadas.
Durante mi etapa separamos servicios clave en nuevos microservicios libres de ifs oportunistas, y trazamos un mapa de deuda técnica con prioridades nítidas. Aún les llevará años terminar esa limpieza —lo sé y lo acepto—, pero hoy caminan en la dirección correcta en lugar de acumular parches.
Sí, hubo daños colaterales. Algunos clientes importantes se marcharon (no sabremos nunca si por nuestra cruzada contra las excepciones o por factores externos), pero al cierre del ejercicio la facturación siguió creciendo y, lo más relevante, lo hizo sin volver a vender ni una sola feature “a medida”. Ahora la plataforma opera en varios países con una única base de código, y los nuevos partners se suben directamente a la versión estándar, sin negociaciones infinitas ni promesas que comprometan el futuro.
La cicatriz que me quedó es clara: en los primeros años de vida de una startup, decir sí a una petición exclusiva equivale a firmar una hipoteca de complejidad a tipo variable. El interés compuesto se dispara con cada nueva excepción. Pesa cada concesión con un business case riguroso, calcula el coste de oportunidad y decide con plena conciencia. Y si aun así aceptas personalizar, hazlo sabiendo exactamente cuándo y cómo vas a desmantelarlo más adelante. A veces perder un cliente duele; hipotecar tu escalabilidad, en cambio, puede costarte la empresa entera.
Tres aprendizajes que comparto contigo
Escalar ≠ acumular: Escalar implica multiplicar impactos con el mismo esfuerzo marginal, no sumar parches. Si cada contrato añade complejidad lineal, tu “escala” es ficticia. El coste de oportunidad es real: Cada semana invertida en una feature exclusiva es una semana que no dedicas a algo valioso para todos. Evalúa siempre el Total Addressable Improvement, no solo el Customer Lifetime Value. La cultura debe sostener al producto: Sin un marco explícito que ampare el no, los equipos comerciales terminarán troceando tu visión. El manifiesto de producto no es burocracia: es el escudo que protege tu estrategia.
Mirando hacia el futuro
Las startups solemos glorificar el “customer centricity”, pero ser centrado en el cliente no significa obedecerlo a ciegas. Significa entender problemas comunes y resolverlos de forma elegante, replicable y mantenible. Las empresas que llegan lejos se parecen más a un ferrocarril —mismo ancho de vía para todos— que a un garaje de prototipos.
Si hoy estás tentado de aceptar esa “pequeña” variación que parece la llave de tu próximo Series A, pregúntate:
¿Estoy apostando por un ingreso inmediato a costa de hipotecar mi capacidad de innovar mañana?
A veces perder un cliente es, en realidad, ganar el futuro. Y créeme: decir no a tiempo fue la decisión más rentable que tomamos en aquella “casa” desordenada. Ojalá estas cicatrices ajenas te eviten algunas propias.
*El impacto en la facturación puede ser algo distinto (pero en esa magnitud de grandeza). Durante nuestras análisis llegamos a datos alarmantes. Gran parte del desarrollo ad-hoc no se pagaba, es decir, habían clientes importantes con algo personalizado, pero la gran mayoría eran de clientes de ticket bajo.
