Todo directivo acaba enfrentándose a la pregunta en una reunión de presupuesto: ¿esto lo construimos o lo compramos? Suena a comparación de costes. Casi nunca lo es. La hoja de cálculo que compara una cuota de licencia con una estimación de desarrollo está comparando dos tipos de objeto distintos - un gasto y un activo - como si fueran lo mismo.
La comparación falla en las dos direcciones. Infravalora el coste de comprar, porque la cuota de licencia es la única línea que llega a la hoja de cálculo - los apaños, el pegamento de integración y las concesiones en el flujo de trabajo no llegan nunca. E infravalora el valor de construir, porque un activo que mejora cada trimestre no cabe en una celda diseñada para alojar el precio de una suscripción. Dos cifras, ambas equivocadas, discutidas en una reunión donde gana la voz más alta.
Este es el marco que usamos con nuestros propios clientes, y con las empresas donde está en juego nuestra propia participación: no pregunte qué es más barato. Pregunte qué acumula valor.
El software alquilado se deprecia el día que usted firma
Una suscripción SaaS resuelve la versión de hoy de su problema con la versión de hoy del producto de otro. A menudo es exactamente lo correcto - nóminas, correo, CRM para un proceso comercial estándar. Son problemas genéricos, y los problemas genéricos merecen soluciones genéricas. Comprarlas no es una concesión; es disciplina.
Pero fíjese en lo que alquila de verdad: un flujo de trabajo diseñado para la media de todos los clientes del proveedor. Cada trimestre en que su operación se aleja de esa media - una regla de precios aquí, un proceso de excepción allá - usted paga una segunda cuota, invisible: la capa de hojas de cálculo. Exportaciones, reintroducción de datos, apaños, «el fichero que mantiene Sanja». Nadie la presupuesta, y crece en proporción exacta a lo diferenciado que sea su negocio.
El alquiler tiene cláusulas ocultas
La cuota de licencia es la parte visible del precio. Las partes invisibles merecen que se las nombre, porque son las que duelen justo en los momentos en que menos se lo puede permitir. El precio por usuario es un impuesto sobre el crecimiento - la herramienta cuesta más en el trimestre en que usted más contrata. La escalada de precios sigue al bloqueo tecnológico - los presupuestos de renovación tienen la costumbre de duplicarse en cuanto sus datos, sus integraciones y los hábitos de su equipo viven dentro del producto. La hoja de ruta no es suya - la funcionalidad de la que depende su operación puede descatalogarse, moverse a un plan más caro o sencillamente no construirse nunca, y su único recurso es un ticket de soporte.
Luego está la gravedad de los datos. Al cabo de tres años, el coste de abandonar una herramienta SaaS profundamente integrada suele ser mayor que el coste de haber construido esa capacidad desde el principio - no porque el software sea bueno, sino porque salir de él implica una exportación, una migración, una reformación del equipo y un trimestre de riesgo operativo. El bloqueo tecnológico no es una conspiración; es el modelo de negocio. Solo merece una línea en la hoja de comparación, y nunca la tiene.
El software propio acumula valor - si construye las cosas correctas
El software a medida se comporta de otra manera en el balance y en la operación. Cada flujo de trabajo que absorbe, cada integración que gana, cada excepción que aprende a tratar abarata la siguiente mejora. Eso es acumulación de valor - el mismo mecanismo que los beneficios no distribuidos, aplicado al conocimiento de proceso.
El bucle es concreto. El sistema captura sus datos con su forma, lo que convierte la siguiente integración en una semana en lugar de un mes. La integración pone otro flujo de trabajo bajo el mismo techo, lo que hace aflorar el siguiente candidato a automatización. Cada incremento aterriza encima del anterior en vez de al lado. A los cinco años, la diferencia entre una pila alquilada y una plataforma propia no es una lista de funcionalidades - es que una lleva todo ese tiempo acumulando el conocimiento de su operación y la otra lleva todo ese tiempo acumulando la hoja de ruta de otro.
Los efectos de segundo orden están infravalorados. Las nuevas incorporaciones aprenden su proceso real, no una herramienta genérica más una carpeta de documentos de apaños. La diligencia debida en una venta o una ronda de financiación va más rápido cuando la operación se lee en un solo sistema - los compradores pagan por operaciones que pueden leer. Y el software en sí es un activo con un valor, que es más de lo que puede decirse de un montón de suscripciones.
Construya solo donde su proceso sea el producto. Compre en todo aquello donde su proceso sea igual que el de los demás.
La prueba es una sola pregunta: si este flujo de trabajo fuera el doble de bueno que el estándar del sector, ¿lo notarían los clientes? Si la respuesta es sí - la velocidad de presupuestación en una empresa de transporte, el tiempo de resolución de siniestros en una aseguradora, la experiencia de admisión en un grupo de clínicas -, ese flujo de trabajo es un activo que acumula valor y merece software propio. Si es no, compre lo genérico y siga adelante.
Dos de los cuadrantes merecen una nota. «Comprar y luego adaptar» es donde la mayoría de las empresas medianas deberían vivir más a menudo de lo que lo hacen: conserve el núcleo genérico y construya solo la capa fina que codifica lo que le hace distinto - el motor de tarificación sobre el CRM estándar, la gestión de excepciones sobre el ERP estándar. Y «comprar lo mejor» conviene tomarlo al pie de la letra: para los flujos de trabajo genéricos, la herramienta premium casi siempre sale más barata que la herramienta barata más la fricción que genera.
La aritmética que de verdad lo decide
Cuando el flujo de trabajo supera la prueba, la decisión de construir se convierte en una cuestión de amortización, y debe calcularse con honestidad: coste de desarrollo más coste de funcionamiento, frente a horas eliminadas, errores evitados e ingresos desbloqueados. En nuestras propias propuestas, si esa amortización supera los doce meses, recomendamos no construir - y ponemos esa recomendación por escrito.
Haga las cuentas con números reales, no con esperanzas. En el lado del coste: la estimación de desarrollo, luego el mantenimiento - una cifra razonable de planificación es el 15-20 % del coste de desarrollo al año - más el alojamiento y el tiempo interno de hacerse cargo. En el lado del retorno: las horas totalmente cargadas que consume hoy el flujo de trabajo, el coste de los errores que produce y los ingresos que desbloquean unos ciclos más rápidos. Si el lado del retorno lo domina una línea blanda de «valor estratégico» y los números duros no la sostienen, son las cuentas diciéndole que compre.
Tres modos de fallo que conviene evitar. Construir software genérico por orgullo - «somos especiales» no es cierto para las nóminas, y el desarrollo competirá contra productos con mil personas de ventaja. Comprar software diferenciador por impaciencia - la suscripción arranca rápido y luego la capa de hojas de cálculo crece a su alrededor hasta que la ventaja de velocidad desaparece. Y construir lo correcto con el alcance equivocado - una v1 que intenta cubrirlo todo se entrega tarde y aterriza en una operación que ya ha dejado de creer en ella. La v1 debería ser vergonzosamente estrecha y usarse de verdad.
Las objeciones habituales, respondidas con honestidad
«No somos una empresa de software». No hace falta que lo sea. Necesita un responsable en su lado de la mesa y un socio que responda del resto - igual que usted posee un edificio sin ser una constructora. Lo que no debería hacer es construir sin dejar cerrada por escrito la cuestión del mantenimiento.
«El software a medida acaba convertido en sistema heredado». El software a medida mal construido, sí. Y también cualquier herramienta SaaS que se le quede pequeña - solo que a un proveedor no se le puede refactorizar. El software construido sobre tecnología aburrida y mayoritaria, documentado y cubierto por pruebas, sigue siendo mantenible una década. Eso es un criterio de selección de proveedor, no un argumento contra tener software propio.
«¿Y si el proveedor publica nuestra funcionalidad el año que viene?» Entonces su herramienta alquilada mejora - para usted y para todos los competidores que la alquilan esa misma tarde. Las funcionalidades que publica un proveedor son, por definición, las que no le diferencian. La capacidad por la que los clientes le eligen es precisamente aquella que no puede permitirse esperar.
Cómo envejece la decisión
Construir o comprar no es una decisión que se tome una vez; es una cartera que se reequilibra. Un flujo de trabajo que hace tres años era genérico puede ser hoy donde usted compite - el alta de clientes hace ese viaje a menudo - y una capacidad que construyó en 2019 puede haberse convertido en algo genérico que tres proveedores venden mejor. Ponga la cartera en cadencia anual: para cada sistema propio, pregunte si sigue superando la prueba del valor acumulado; para cada suscripción significativa, pregunte cuánto cuesta ya la capa de hojas de cálculo que la rodea.
Esté tan dispuesto a retirar software propio como a construirlo. Apagar una herramienta a medida cuyo flujo de trabajo se ha vuelto genérico no es admitir un fracaso - es la cartera funcionando. El modo de fallo es la inercia en cualquiera de las dos direcciones: alquilar aquello que le diferencia porque construir da vértigo, o mantener su sistema heredado porque un día fue caro. Al balance no le importa lo que costó aprender algo; le importa qué acumula valor de aquí en adelante.
Por dónde empezar
Haga inventario de su capa de hojas de cálculo. Cada apaño es un voto - su operación diciéndole dónde se le han quedado ya pequeñas las herramientas alquiladas. Ponga precio honesto a esas horas, aplique la prueba del valor acumulado, y la decisión de construir o comprar suele tomarse sola. La lista será más larga que su apetito, que es el estado sano: ordene por amortización, construya desde arriba y deje que el retorno medido de cada proyecto financie la voluntad para el siguiente.
Y cuando un desarrollo sí supere el listón, exíjale el estándar que justificó su caso: una métrica de negocio nombrada antes de la primera línea de código, software en funcionamiento en semanas y no en trimestres, y un alcance lo bastante estrecho como para dar vergüenza. El software propio solo acumula valor si se entrega, se usa y sigue absorbiendo la operación que lo rodea. Esa parte no es una cuestión de estrategia. Es de ejecución.