Construir lo que se podía comprar sale caro, y comprar lo que había que construir también. Cinco criterios para decidir antes de cotizar.
Pocas decisiones de tecnología se toman con tanta intuición y tan poco método como la de construir o comprar. Hay gerencias que encargan un desarrollo de software a medida para algo que resuelve una suscripción mensual, y otras que pasan años forzando un ERP a hacer lo que su negocio necesita, con una capa de parches que nadie quiere tocar.
Ninguna de las dos opciones es mejor en general. Desde una empresa que vive de construir software puede sonar raro, pero es lo primero que decimos en un diagnóstico: si existe un producto que resuelve casi todo lo que necesitas, cómpralo. Este artículo es para reconocer cuándo ese producto no existe.
¿Qué es un software de catálogo y qué es uno a medida?
Software de catálogo es todo lo que se contrata tal como viene: un SaaS, un ERP con su configuración estándar, una plataforma de comercio electrónico, un CRM de mercado. Lo usa mucha gente, el proveedor lo mantiene y tú te adaptas a su forma de trabajar.
Software a medida es el que se construye para tu proceso. Hace exactamente lo que necesitas, el código es tuyo y nadie más lo tiene. También es tuyo el mantenimiento, para siempre.
Entre medio hay una zona gris donde se toman las peores decisiones: el producto de catálogo personalizado tanto que ya no se puede actualizar, o el desarrollo a medida que reimplementa algo que el mercado ya resolvía mejor.
Hay una pregunta que conviene hacerle a cualquier producto de catálogo antes de firmar: ¿cómo me llevo mis datos si me voy? Si la respuesta es un archivo incompleto o un servicio de exportación con costo, el producto es más difícil de dejar de lo que parece, y eso también es un costo, aunque no aparezca en la cotización.
Cinco preguntas para decidir entre construir o comprar
- ¿El proceso es lo que te diferencia de la competencia? Si es la forma en que cotizas, despachas o atiendes, y es la razón por la que te eligen, adaptarlo a un producto genérico es renunciar a esa ventaja.
- ¿Qué parte de tu proceso cubre el producto sin modificarlo? Medida con tus casos reales, no con la demo del vendedor.
- ¿Cuántas integraciones necesitas? Un producto que cubre todo pero no conversa con tu facturación, tu bodega o tu banco obliga a digitar dos veces.
- ¿Cuánto cambia tu proceso? Si cambia todos los trimestres, depender del roadmap de otro se vuelve caro.
- ¿Tienes quién mantenga lo que construyas? Un desarrollo a medida sin equipo que lo cuide envejece rápido.
Si las dos primeras respuestas dicen que el proceso es estándar y que el producto lo cubre casi entero, la conversación termina ahí: compra. Si dicen lo contrario, sigue leyendo.
Responder estas preguntas con honestidad requiere sentar en la misma mesa a quien opera el proceso y a quien conoce la tecnología. La decisión suele fallar cuando la toma solo una de las dos partes: el área usuaria se enamora de una demo, o el área de TI se entusiasma con construir algo que el negocio no necesitaba.
¿Cuánto cuesta un software a medida, de verdad?
La comparación habitual pone el costo del desarrollo frente a la suscripción anual. Es la comparación equivocada, porque el desarrollo es solo la primera fila de una planilla de varios años:
- Construcción: el proyecto en sí, que conviene presupuestar por fases y no como un solo número.
- Infraestructura: servidores o servicios cloud, ambientes de prueba, respaldos y monitoreo.
- Mantenimiento: actualizaciones de dependencias, parches de seguridad y correcciones. Es un costo permanente, no un imprevisto.
- Evolución: las mejoras que el negocio va a pedir apenas el sistema esté en uso.
- Conocimiento: documentación y traspaso, para no depender de una sola persona ni de un solo proveedor.
Del lado del producto de catálogo, la planilla también tiene más filas que la suscripción: licencias por usuario que crecen con la empresa, módulos adicionales, implementación, consultoría de configuración, integraciones y el costo de cambiar tu proceso para que calce con el sistema.
Una buena práctica es presupuestar el desarrollo por fases cortas, con un primer bloque funcional que entre a producción pronto. Así la decisión de seguir invirtiendo se toma con el sistema en uso y no con una estimación de meses atrás, y si el proyecto no rinde lo esperado puedes detenerte habiendo gastado una fracción del total.
Compara cinco años de costo total, no el primer mes. Es el único horizonte donde las dos opciones se ven completas.
Las señales de que necesitas desarrollo a medida
- Tu equipo mantiene planillas paralelas porque el sistema no hace lo que el proceso necesita.
- Las personalizaciones del producto bloquean sus actualizaciones y quedaste atrapado en una versión vieja.
- Pagas licencias de usuarios que solo entran a consultar un dato o a aprobar una solicitud.
- La integración entre dos productos es un proceso manual que alguien hace todos los días.
- El proceso que te distingue no existe en ningún producto del mercado.
Una sola de estas señales no justifica construir. Tres o más, sostenidas en el tiempo, son un buen motivo para al menos evaluarlo con números.
Ojo también con la señal contraria: si quieres construir porque el producto «no se adapta» a un proceso que en realidad nadie ha revisado en años, quizás lo que hay que cambiar es el proceso. Un desarrollo a medida que automatiza un proceso ineficiente solo lo hace ineficiente más rápido.
El camino del medio: comprar el núcleo y construir los bordes
En muchos casos la mejor respuesta no es una ni la otra. Se compra lo que es estándar —contabilidad, remuneraciones, correo, facturación electrónica— y se construye lo que es propio, conectado a lo anterior por APIs.
Este modelo tiene dos condiciones para funcionar. La primera es que los productos que compres tengan una API documentada y estable; si solo se integran exportando archivos, el borde a medida va a ser frágil. La segunda es que el desarrollo propio se diseñe sabiendo que los productos de alrededor pueden cambiar: la integración se aísla en una capa propia, para que reemplazar a un proveedor no obligue a reescribir todo.
Un ejemplo típico en Chile es la facturación electrónica: casi nunca conviene construirla desde cero, porque hay proveedores que ya resuelven la relación con el SII y la mantienen al día con sus cambios. Lo que sí suele valer la pena construir es el flujo propio que termina en una factura, como la cotización, la aprobación o el despacho, y conectarlo al proveedor por su API.
Qué exigir si decides construir
Si la respuesta es desarrollo a medida, estas condiciones no deberían ser negociables con ningún proveedor, nosotros incluidos:
- El repositorio está en tu organización desde el primer día y la propiedad intelectual queda en el contrato.
- Ves software funcionando en ciclos cortos, no presentaciones de avance.
- Las pruebas automatizadas y el despliegue continuo vienen incluidos, no como un extra.
- Hay documentación de arquitectura y un plan de traspaso por si mañana cambias de proveedor.
- El presupuesto se cierra por fases, para que puedas detenerte o cambiar de rumbo con lo que ya está construido.
Un proveedor que no acepta alguna de estas condiciones te está vendiendo dependencia junto con el software.
Ninguna de estas exigencias encarece el proyecto de forma significativa si se acuerda al inicio. Lo que sale caro es descubrir al final que no estaban: un sistema sin pruebas que nadie se atreve a modificar, o un repositorio que hay que pedirle al proveedor cuando la relación ya se terminó.
Si estás frente a esta decisión, te ayudamos a tomarla con números. En un diagnóstico de 45 minutos sin costo, dos ingenieros senior revisan tu proceso y te dicen con franqueza si conviene construir, comprar o combinar. Si ya decidiste construir, en desarrollo de software a medida está cómo trabajamos, y en consultoría tecnológica cómo hacemos la evaluación cuando todavía hay dudas.