Cuándo NO Construir Software de Construcción a Medida

No construya software de construcción a medida cuando el proceso que quiere soportar es uno que todos los contratistas ejecutan igual, cuando nadie adentro va a hacerse dueño del resultado, cuando lo necesita antes de lo que un desarrollo puede entregar, o cuando la plataforma que lo tiene frustrado está a punto de lanzar justo lo que le falta. Esos cuatro casos cubren la mayoría de los proyectos que no deberían ocurrir, y una empresa que construye software para vivir debería poder nombrarlos.

Resumen rápido

• Casi todas las guías de construir o comprar que posicionan en búsquedas de construcción las publica un proveedor de plataforma, lo que sesga estructuralmente el consejo hacia comprar.
• El sesgo inverso es igual de real: una empresa de desarrollo que nunca recomienda no construir no está dando consejo, está cotizando.
• Solo el 16% de las transformaciones digitales entrega mejoras de rendimiento sostenidas, y los fracasos rara vez son técnicos: son fallas de adopción y de propiedad.
• Los proveedores de plataformas han estado adquiriendo las categorías donde los contratistas construyen a medida, lo que acorta la vida útil de un desarrollo genérico.
• El mejor argumento para construir es un proceso genuinamente específico de cómo su negocio gana dinero. El más débil es un hueco en una plataforma que la plataforma va a cerrar.

Este es el contrapeso del argumento de qué construyen las empresas de construcción cuando su plataforma se queda corta. Las dos cosas son ciertas a la vez, y saber en cuál situación está usted es toda la decisión.

¿Por qué toda guía de construir o comprar está sesgada?

Por quién las publica. Busque consejo sobre construir versus comprar en construcción y los resultados los dominan proveedores de plataformas, empresas cuyos ingresos dependen de que la respuesta sea “comprar”. El consejo no es deshonesto, y parte de él es bueno, pero lo escribe gente con un solo desenlace en juego.

La imagen espejo es igual de sospechosa. Una empresa de desarrollo publicando sobre cuándo construir software a medida tampoco es parte neutral. Así que la prueba útil para cualquier guía, incluida esta, es si nombra casos que le cuestan dinero al autor. Lo que sigue es esa lista.

¿Cuándo el proceso no es realmente suyo?

La razón más fuerte para construir es un proceso específico de cómo su negocio gana dinero. El error más común es creer que un proceso es específico cuando apenas es familiar.

La nómina funciona igual en la mayoría de contratistas. También las cuentas por pagar, casi toda la programación de obra y el grueso de la gestión documental. Si lo que usted hace es un proceso común que resulta que hace de manera inusual, la pregunta es si esa manera inusual se gana su costo. Muchas veces no: es una acumulación de decisiones que nadie ha revisado, y construir software alrededor la vuelve permanente y cara de cambiar.

La prueba: ¿este proceso existe porque produce un resultado que no podría obtener de otra forma, o porque así se ha hecho siempre? Lo primero vale la pena construirlo. Lo segundo vale la pena examinarlo antes de que alguien escriba código. En la práctica, el mejor desenlace de una fase de definición es a veces que un cliente cambie un proceso para encajar en una plataforma en vez de construir software para preservarlo.

¿Quién va a ser dueño de esto después de entregarlo?

El software a medida necesita un dueño interno: alguien con autoridad sobre el proceso que soporta y suficiente fluidez técnica para decidir sobre su futuro. No necesariamente un desarrollador, sino una persona que decida qué pasa cuando cambia un requisito, que arbitre entre solicitudes que compiten, que sepa por qué el sistema hace lo que hace.

Sin esa persona, el software a medida se degrada. Las solicitudes se acumulan sin nadie que las priorice, se olvida la razón original, los rodeos se apilan, y en dos años la herramienta es un pasivo que todos resienten y nadie puede reemplazar.

Las plataformas sobreviven a esa ausencia porque el proveedor hace el papel de dueño: mal para sus necesidades específicas, pero de forma continua. Esa es una ventaja real de comprar y casi nunca se contabiliza. Si no puede nombrar al dueño interno durante la conversación de venta, eso no es un detalle para resolver después; es una razón para reconsiderar todo el enfoque. CodeBranch pide ese nombre durante Product Definition, y una respuesta de “ya lo definiremos” cambia la recomendación.

McKinsey encontró que solo el 16% de las transformaciones digitales entregó mejoras de rendimiento sostenidas, y los factores de fracaso que identificó fueron enfoques que arrancan por la tecnología, pilotos aislados que nunca escalaron, y cambio organizacional descuidado. Ninguno de esos es un problema de código.

¿La plataforma va a lanzarlo antes que usted?

Este riesgo ha crecido de golpe. Solo en el primer semestre de 2026, Autodesk propuso adquirir MaintainX por unos 3.600 millones de dólares, Procore adquirió DataGrid, Autodesk adquirió Rhumbix y Trimble adquirió Document Crunch. Esas cuatro adquisiciones cubren mantenimiento y operaciones, datos, mano de obra de campo y análisis de contratos con IA: precisamente las categorías donde los contratistas estaban construyendo a medida o comprando soluciones puntuales.

La implicación es incómoda para cualquiera que venda desarrollo a medida, y hay que decirla sin rodeos: si el hueco que quiere llenar es una capacidad que la plataforma todavía no tiene, puede estar construyendo algo con dos años de vida útil. La plataforma va a terminar cubriendo la función, en su hoja de ruta y con su forma, no con la de usted, pero la va a cubrir.

La distinción que sobrevive a esto es entre una funcionalidad faltante y un modelo distinto. Un hueco de funcionalidad se cierra. Un desajuste de fondo entre cómo la plataforma estructura su trabajo y cómo opera realmente su negocio no se cierra, porque cerrarlo significaría que la plataforma atiende a un cliente distinto que al resto.

¿Cuándo la urgencia es razón para no construir?

Cuando la necesidad es genuinamente inmediata. Un desarrollo a medida medido en meses no resuelve un problema que tiene este trimestre, y la versión de la historia donde una herramienta interna pequeña tapa el hueco mientras tanto normalmente termina con el parche vuelto permanente.

El matiz es que la urgencia muchas veces es fabricada. Un requisito urgente por una fecha que alguien fijó internamente es distinto de uno que viene de un contrato con un cliente o de una fecha regulatoria. CodeBranch separa las dos antes de dimensionar, porque la primera suele ser negociable y la segunda no, y construir contra una fecha negociable es como el alcance termina recortado en los lugares equivocados.

Entonces, ¿cuándo sí tiene sentido construir?

Por simetría, porque una lista de razones para no construir solo es honesta junto a los casos donde sí corresponde.

Cuando el proceso es de donde sale su margen. Si cómo presupuesta, compra o controla costos es parte de por qué gana contratos, una plataforma que lo estandariza le quita la ventaja.

Cuando el modelo de datos de la plataforma no puede representar su trabajo. No que falte un campo: que estructure el dominio de una forma que no corresponde a cómo opera su negocio.

Cuando la integración es todo el problema. Si los sistemas existen y el hueco es que no se hablan, ese hueco no se va a cerrar comprando otro sistema.

Cuando no hay capacidad técnica interna ni apetito por construirla. Este es contraintuitivo, y viene de un caso real: el trabajo de CodeBranch con un contratista eléctrico empezó con servicios de fractional CTO precisamente porque el cliente no tenía capacidad técnica interna: necesitaba ayuda para elegir un stack antes de poder construir nada. Eso pudo haber sido un argumento en contra de construir. No lo fue, porque la alternativa era una plataforma que no podía modelar su negocio, y el socio aportó la capacidad que al cliente le faltaba. La lección es que “no tenemos equipo técnico” es razón para examinar la decisión con lupa, no un no automático: lo que importa es si alguien va a ser dueño del resultado, no si sabe escribir el código.

¿Qué debería preguntarse antes de decidir?

Cuatro preguntas, y si las respuestas apuntan a comprar, compre.

¿Este proceso es cómo ganamos dinero, o solo cómo lo hemos hecho siempre? ¿Quién dentro de la empresa va a ser dueño de esto en dos años, con nombre propio? ¿El hueco es estructural o es una funcionalidad que la plataforma va a lanzar? Y si no hacemos nada durante seis meses, ¿cuánto nos cuesta?

La última es la más útil y la menos formulada. Mucho software a medida se construye porque una frustración es ruidosa, no porque la inacción sea cara. Ponerle un número a no hacer nada aclara la decisión más rápido que cualquier comparación de funcionalidades.

Y si las respuestas sí apuntan a construir, lo que eso implica es el tema del trabajo de desarrollo de software para construcción de CodeBranch, donde la primera fase es la que todavía puede concluir que no debería hacerlo.