Saltar al contenido

Software a la medida4 min de lectura

Software a la medida: cuándo conviene y cuándo no

Cuatro preguntas para decidir entre comprar, configurar o construir, y por qué el costo de un desarrollo a la medida no está donde se suele mirar.

Camilo RincónFundador e ingeniero principal
En este artículo (6)
  1. 1. ¿Es esto lo que te hace ganar?
  2. 2. ¿Cuánto llevas peleándote con la herramienta?
  3. 3. ¿Es estable lo que quieres construir?
  4. 4. ¿Quién lo mantiene el año que viene?
  5. 05La opción intermedia que casi nadie considera
  6. 06Cómo lo decidimos con un cliente

Nos dedicamos a construir software a la medida, así que lo honesto es empezar por lo otro: la mayoría de las veces no conviene.

Un ERP, un CRM o una herramienta de facturación ya existen, cuestan una fracción y vienen con soporte, actualizaciones y certificaciones que tú tendrías que conseguir aparte. Construir tu propia versión de un producto maduro es una de las formas más caras de perder dos años.

Hay casos en los que sí conviene. Estas son las cuatro preguntas con las que los separamos.

1. ¿Es esto lo que te hace ganar?

Separa tus procesos en dos montones. En uno, aquello por lo que tus clientes te eligen a ti y no al de al lado. En el otro, todo lo demás: nómina, contabilidad, correo, soporte, control de accesos.

El segundo montón se compra. Siempre. No importa lo particular que te parezca tu forma de llevar la contabilidad: no es por eso que te compran.

El primer montón es el candidato. Si tu ventaja es cómo enrutas los pedidos, cómo cotizas, cómo programas las rutas o cómo priorizas la producción, un producto de catálogo te va a obligar a trabajar como trabajan los demás. Que es exactamente lo contrario de lo que te dio la ventaja.

2. ¿Cuánto llevas peleándote con la herramienta?

Un producto de catálogo que no encaja no se nota como un error. Se nota como una capa de trabajo alrededor: la hoja de cálculo paralela, el campo «observaciones» donde en realidad va el dato importante, el paso manual entre dos sistemas, la persona que se sabe el truco.

Esa capa tiene un costo y casi nunca está en ningún presupuesto. Antes de decidir nada, mídela: cuántas horas al mes, de cuánta gente, y qué pasa cuando esa persona se va de vacaciones.

Si la respuesta son dos horas al mes, aguanta. Si son dos personas de tiempo completo, ya estás pagando un desarrollo a la medida todos los años; solo que sin quedarte con nada.

3. ¿Es estable lo que quieres construir?

El software a la medida funciona bien cuando las reglas cambian despacio. Si el proceso se está inventando todavía, cualquier cosa que construyas va a ir un trimestre por detrás.

En esos casos preferimos empezar por lo más barato que resuelva: una configuración, una integración, una automatización sobre las herramientas que ya tienes. Cuando el proceso se asiente —y se nota, porque dejan de cambiar las reglas y empiezan a cambiar solo los volúmenes— se construye.

Construir antes de que el proceso esté estable es la razón número uno por la que un proyecto a medida se entrega tarde y llega desactualizado.

4. ¿Quién lo mantiene el año que viene?

Aquí es donde se decide de verdad el costo, y es lo que menos se mira.

Un desarrollo a la medida no termina cuando se entrega. Necesita actualizaciones de dependencias, parches de seguridad, un sitio donde correr, alguien que atienda cuando falle un martes a las 11 de la noche. Un producto de catálogo incluye todo eso en la suscripción.

Si vas a construir, el presupuesto tiene que incluir el mantenimiento desde el primer día, y la respuesta a «quién» tiene que ser un nombre, no «ya veremos». Sin eso, el sistema que te dio ventaja en el año uno es deuda en el año tres.

La opción intermedia que casi nadie considera

Comprar o construir no son las únicas dos casillas. Entre medias está construir solo la pieza que te distingue y comprar el resto.

Usar la facturación de catálogo, pero con tu motor de cotización encima. Mantener el ERP como fuente de verdad, y construir la aplicación de campo que tus técnicos usan de verdad. Integrar, no reemplazar.

Sale más barato, se entrega antes y se puede deshacer. Y casi siempre resuelve el 80 % del dolor, que es lo que estabas buscando.

Cómo lo decidimos con un cliente

No hacemos esta conversación en abstracto. La secuencia que seguimos:

  1. Medir la capa de trabajo alrededor de la herramienta actual: horas, personas, errores.
  2. Escribir el proceso en una página. Si no cabe, el problema no es la herramienta.
  3. Mirar el catálogo otra vez, ahora con el proceso escrito delante. A veces sí existe, y simplemente nadie lo había buscado con las palabras correctas.
  4. Si no existe, acotar la pieza mínima que hay que construir y qué se integra con lo que ya está.
  5. Poner número al mantenimiento antes de empezar, no después.

Si al final del paso 3 la respuesta es comprar, lo decimos. Perdemos el proyecto y ganamos la conversación siguiente, que suele ser más interesante.

Temas: #producto #arquitectura #decisiones

Escrito por

Camilo Rincón · Fundador e ingeniero principal

Ver perfil
  1. 23 sept 2026Migración y modernización

    Seis fugas de dinero en AWS y cómo cerrarlas

    Las facturas de nube no se disparan por una decisión grande, sino por seis pequeñas que nadie revisa. Dónde mirar y qué cuesta cada una.

  2. 23 sept 2026Integración y automatización

    Qué automatizar primero y cómo evitar que falle en silencio

    Un criterio simple para elegir el primer proceso a automatizar, y las tres señales de que un proceso todavía no está listo para serlo.