- build-vs-buy
- custom-software
- saas
- software-ownership
- advisory
Análisis completo
Nota editorial: Este artículo describe un patrón de decisión observado repetidamente en compromisos de asesoría. No es una narrativa de proyecto único. El escenario se construye a partir de elementos observados en múltiples situaciones reales. Los números de costes específicos se excluyen porque requerirían fabricación; el análisis describe relaciones de estructura de costes, no cifras inventadas.
Existe una categoría de solicitud de cliente que encontramos regularmente. Un propietario de negocio o responsable de operaciones llega con un problema de software específico que quiere resolver. Ha evaluado herramientas SaaS y ha concluido que ninguna hace lo que necesita. Quiere construir algo a medida.
Nuestro trabajo, tal como ellos lo ven, es confirmar el requisito y comenzar a definir el alcance. Habitualmente, eso es exactamente lo que hacemos. Pero ocasionalmente — con más frecuencia de lo que una agencia de software debería admitir — la respuesta correcta es no construir en absoluto.
La situación habitual
Las situaciones que producen esta recomendación comparten una estructura consistente. El cliente gestiona una operación — logística, servicios profesionales, oficios, agencias de distintos tipos. Tienen un proceso que funciona, pero es manual y fragmentado: hojas de cálculo, correo electrónico, WhatsApp, quizás una herramienta SaaS que no conecta con el resto.
Han tenido malas experiencias con el SaaS. Una herramienta que prometía resolver su flujo de trabajo resultó estar construida para un tipo de negocio diferente. Perdieron datos durante una migración, o pagaron por funciones que nunca usaron, o descubrieron que la hoja de ruta del producto dejó de incluir lo que necesitaban. La conclusión a la que llegaron: necesitan ser dueños de su software.
Lo que encontramos en el descubrimiento
En los casos que llevan a recomendar no construir, generalmente hay una herramienta SaaS que el cliente miró brevemente, encontró algo que no le gustó y descartó. Cuando la examinamos más detenidamente, encontramos que cubre lo que necesitan en su gran mayoría. El resto se divide en dos categorías: cosas que genuinamente requieren funcionalidad personalizada, y cosas que son inusuales en su proceso actual en lugar de requisitos de su negocio subyacente.
La segunda categoría es la importante. Cada empresa tiene flujos de trabajo que han evolucionado en torno a las limitaciones de sus herramientas actuales. Algunos representan diferenciación competitiva genuina. Otros son adaptaciones a limitaciones que no existirían en una herramienta SaaS mejor implementada. Cuando trabajamos esta distinción con el cliente, los requisitos personalizados se reducen — a menudo lo suficiente como para cambiar el caso económico.
El análisis que realizamos
La comparación estándar de construir vs. comprar es: coste del proyecto frente a suscripción anual al SaaS. Esta comparación omite los costes que determinan la economía real a largo plazo.
Para la opción SaaS, añadimos: coste de incorporación (tiempo del personal para migrar, configurar y formarse), coste de integración (cualquier conexión con otros sistemas) y coste de administración anual (quién gestiona la herramienta, tramita casos de soporte, forma a nuevos empleados). Estos son costes reales, a menudo significativos, e invisibles en el precio por usuario.
Para la opción personalizada, añadimos: coste de mantenimiento (quién mantiene este software funcionando, actualizado y seguro tras la entrega), coste de soporte (quién gestiona errores y preguntas de usuarios cuando el equipo original ha pasado a otros proyectos) y coste de desarrollo futuro (cualquier software que encaje con la operación hoy no lo hará perfectamente en 18 meses). Para una empresa sin desarrollador interno, cada uno de estos es una dependencia de un proveedor externo.
Cuando añadimos estas categorías a ambos lados, la economía cambia. La opción SaaS, que parecía cara porque la suscripción anual es visible, incluye muchos de los costes operativos continuos en esa suscripción. La opción personalizada, que parecía una inversión única, lleva costes operativos continuos que eran invisibles en el presupuesto del proyecto.
Lo que le decimos al cliente
La recomendación de no construir no es principalmente un argumento de coste. Es un argumento organizativo.
Todo software personalizado crea una dependencia. Para una empresa con capacidad técnica interna, esto es manejable. Para una empresa sin ella, la dependencia es externa — vive en una relación con una agencia o un freelance que debe mantenerse, financiarse y gestionarse. Cuando esa relación se rompe, el software se convierte en un pasivo. Funciona, probablemente sigue funcionando durante un tiempo, y entonces un día no funciona, y no hay nadie que sepa cómo arreglarlo.
Esto es lo que explicamos cuando recomendamos no construir. No que el software personalizado sea malo, sino que el software personalizado sin capacidad interna es un compromiso a largo plazo que el presupuesto del proyecto no refleja. El presupuesto cubre la construcción. No cubre la dependencia de 36 meses que sigue.
Qué ocurre después
Algunos clientes aceptan este análisis y migran a la herramienta SaaS. Otros no — generalmente porque tienen una razón que no conocemos del descubrimiento: una experiencia anterior con dependencia del proveedor, un requisito de soberanía de datos, un plan futuro que hace real el caso de propiedad. No disputamos a los clientes que eligen diferente. Documentamos el razonamiento, anotamos cuál fue nuestra recomendación y procedemos a construir la mejor versión posible de lo que solicitaron.
En los casos donde recomendamos no construir y el cliente procedió de todas formas, el patrón de lo que siguió es instructivo. El software se construye. Funciona. La relación con la agencia se reduce. El software funciona sin mantenimiento más tiempo del esperado. Entonces deja de funcionar.
En los casos donde recomendamos SaaS y el cliente aceptó, el patrón de seguimiento es diferente. Hay quejas sobre la herramienta — siempre las hay. Pero las quejas son sobre funcionalidades específicas, no sobre un fallo existencial del software. La empresa sigue usando el software dos años después.
Qué nos dice esto sobre cómo se toma la decisión
La decisión de construir vs. comprar no es principalmente una decisión técnica. Tampoco es principalmente una decisión financiera. Es una decisión sobre qué tipo de dependencia operativa es aceptable.
El software personalizado es una dependencia de tu propia capacidad para mantenerlo. El SaaS es una dependencia de la hoja de ruta y las decisiones de precios del proveedor. Ninguna dependencia desaparece eligiendo la otra opción. La pregunta es cuál dependencia puedes gestionar mejor, dados tu equipo real y tus recursos reales.
La mayoría de los análisis de construir vs. comprar comparan los costes visibles e ignoran las dependencias operativas. La recomendación de no construir emerge cuando podemos ver que la dependencia implicada por la propiedad personalizada es una que la organización no está equipada para gestionar — y cuando la alternativa SaaS es lo suficientemente cercana a lo que necesitan que la dependencia del proveedor es más manejable que la dependencia del código personalizado.
¿Cuándo recomienda InfoWebPlus no construir software a medida?
Recomendamos no construir cuando tres condiciones aparecen juntas: el cliente no tiene capacidad técnica interna para mantener el software tras la entrega; una alternativa SaaS cubre la mayoría de sus requisitos genuinos; y los requisitos que parecen personalizados resultan ser adaptaciones a las limitaciones actuales de las herramientas en lugar de diferenciadores empresariales reales. Cuando las tres están presentes, la dependencia creada por la propiedad personalizada suele ser más difícil de gestionar que la dependencia de un proveedor SaaS.
¿Qué costes omite habitualmente una comparación estándar de construir vs. comprar?
En el lado SaaS: coste de incorporación (tiempo del personal para migración, configuración y formación), coste de integración y coste de administración anual. En el lado personalizado: coste de mantenimiento tras la entrega, coste de soporte cuando el equipo de desarrollo original ha pasado a otros proyectos, y coste de desarrollo futuro — porque cualquier software construido para encajar con las operaciones actuales necesitará adaptación a medida que el negocio cambie. Para empresas sin desarrolladores internos, cada uno de estos costes del lado personalizado es una dependencia a largo plazo de un proveedor externo.
¿Es la decisión de construir vs. comprar principalmente una decisión financiera?
No. Las finanzas importan, pero la pregunta central es qué tipo de dependencia operativa es aceptable para la organización. El software personalizado crea una dependencia de tu propia capacidad para mantenerlo. El SaaS crea una dependencia de la hoja de ruta y las decisiones de precios del proveedor. Ninguna dependencia desaparece eligiendo la otra opción. El análisis trata sobre qué dependencia puedes gestionar mejor dados tu equipo y recursos reales — no sobre qué opción parece más barata en la comparación inicial.
¿Qué ocurre con el software a medida cuando el cliente no tiene desarrollador interno?
El patrón es consistente. El software se construye y funciona. La relación con la agencia de desarrollo se reduce gradualmente a medida que el proyecto concluye. El software funciona sin mantenimiento activo más tiempo del esperado — hasta que deja de hacerlo. Cuando algo falla o una dependencia cambia, no hay nadie internamente que entienda el código. La empresa entonces se enfrenta a un compromiso de emergencia costoso, una migración forzada, o a operar con software defectuoso. Este no es un riesgo hipotético — es el resultado observado en la mayoría de los casos donde recomendamos no construir y el cliente procedió de todas formas.