Cuándo conviene desarrollar software a la medida

La decisión entre comprar y construir se plantea mal cuando se compara solo el precio inicial. Una licencia mensual parece siempre más barata que un desarrollo, hasta que se suman cinco años de suscripción para cuarenta usuarios más las integraciones y las concesiones en el proceso.

Y al revés: desarrollar algo que ya existe resuelto y estandarizado es una forma cara de reinventar la rueda.

Las tres opciones reales

Suele plantearse como binaria, pero hay tres caminos, y el intermedio se subestima:

La opción intermedia —configurar una plataforma existente— resuelve una gran parte de los casos y suele ser la más eficiente. Vale la pena agotarla antes de decidir construir desde cero.

El criterio central: ¿es distintivo o es común?

La pregunta que ordena la decisión es esta: ¿este proceso es parte de lo que hace diferente a tu empresa, o es algo que toda empresa hace igual?

La contabilidad se rige por normas iguales para todos. No hay ventaja competitiva en llevarla de forma distinta, y desarrollar un sistema contable propio es casi siempre un error.

Ahora, si tu empresa cotiza proyectos con un método de cálculo propio que desarrollaste durante quince años, que combina variables que tus competidores no consideran y que es parte de por qué ganas licitaciones, ese proceso sí es distintivo. Forzarlo dentro de un CRM genérico significa renunciar precisamente a lo que te diferencia.

Señales de que el estándar ya no alcanza

• Pagas por un sistema y mantienes hojas de cálculo paralelas. Es la señal más clara: la herramienta no cubre el proceso real y el equipo compensa por fuera.
• El costo de licencias crece más rápido que el uso. Modelos por usuario que se vuelven desproporcionados al crecer el equipo.
• Necesitas tres sistemas para un solo proceso. Y alguien pasa datos entre ellos manualmente.
• Las personalizaciones ya cuestan más que un desarrollo. Cuando llevas años pagando ajustes sobre una plataforma, conviene sumar ese gasto acumulado.
• La herramienta condiciona decisiones de negocio. Frases como "no podemos ofrecer eso porque el sistema no lo permite" indican que la cola mueve al perro.

Costo total de propiedad, no precio inicial

La comparación correcta se hace a cinco años e incluye todo:

Las variables que inclinan la balanza

• Número de usuarios. Es la más determinante. El SaaS escala su costo linealmente con los usuarios; el desarrollo propio, no. Con muchos usuarios, el punto de equilibrio llega antes.
• Horizonte de vida del proceso. Si el proceso va a cambiar radicalmente en dos años, no construyas para diez.
• Cuánto de la herramienta usarías. Pagar una suite completa para usar el 15% es común y caro.
• Costo de las integraciones. A veces integrar el producto estándar cuesta más que construir la pieza a medida.

Los riesgos del desarrollo a la medida

Conviene nombrarlos con claridad, porque son reales:

Dependencia del proveedor

Si quien lo construyó desaparece y no dejó documentación ni código accesible, quedas atrapado. Es el riesgo más serio y el más fácil de mitigar contractualmente.

Subestimación del alcance

Los requerimientos crecen durante el proyecto. Es normal y hay que preverlo con una reserva de contingencia realista, no fingir que no ocurrirá.

El mantenimiento no termina

Un sistema propio requiere actualizaciones de seguridad, adaptación a cambios de otros sistemas y corrección de errores. Es un compromiso permanente, no un pago único.

Deuda técnica

Si se construye con prisa y sin criterios de calidad, cada cambio futuro cuesta más que el anterior. Es un costo que se paga en cuotas crecientes.

Cómo reducir el riesgo

Si decides desarrollar, estas condiciones deberían estar en el acuerdo desde el inicio:

1. El código es tuyo. Propiedad intelectual explícita en el contrato y acceso al repositorio desde el primer día, no al entregar.
2. Tecnologías conocidas. Construido sobre lenguajes y marcos de trabajo con comunidad amplia, para que otro equipo pueda continuarlo. Evita lo exótico salvo que haya una razón muy fuerte.
3. Documentación como entregable. Arquitectura, decisiones de diseño y guía de despliegue. Debe formar parte de lo que se entrega, no ser un favor.
4. Entregas incrementales. Algo funcionando cada pocas semanas, en lugar de un único entregable al final. Permite corregir el rumbo mientras aún es barato.
5. Pruebas automatizadas. Al menos sobre la lógica de negocio crítica. Es lo que permite modificar el sistema después sin romperlo.
6. Sin secretos en el despliegue. Que puedas desplegar el sistema sin depender de conocimiento que solo tiene el proveedor.

Construye lo que te diferencia. Compra lo que te iguala.

En resumen

Separa los procesos comunes de los distintivos, calcula el costo total a cinco años en lugar del precio inicial, agota la opción de configurar antes de construir, y si desarrollas, asegura la propiedad del código y la documentación desde el contrato.