Software estándar o software a medida: coste total y señales para decidir
Cómo comparar un software como servicio con un desarrollo a medida por coste total, ajuste al proceso y dependencia, y por qué la respuesta suele ser combinar ambos.
Como desarrollador, tendría motivos para recomendar siempre software a medida. Como consultor, la mayoría de las veces recomiendo empezar por lo estándar e integrarlo bien, y desarrollar solo la parte del proceso que es propia de tu empresa.
La decisión depende de cuatro factores: ajuste al proceso, coste total, dependencia y ritmo de cambio.
Por qué el precio de la licencia engaña
Comparar «40 € al mes por usuario» con un presupuesto de desarrollo es comparar dos cosas distintas. El coste real de cada opción incluye más partidas.
Software estándar, normalmente software como servicio (SaaS)
- Licencias por usuario o por volumen, que crecen con la empresa.
- Configuración, migración de datos y formación.
- Integraciones con el resto de herramientas.
- Trabajo alrededor de lo que la herramienta no permite, como hojas de cálculo paralelas, campos reutilizados o pasos manuales.
- Coste de salida si algún día hay que cambiar.
Software a medida
- Fase de descubrimiento y desarrollo inicial.
- Infraestructura, copias de seguridad y monitorización.
- Mantenimiento, actualizaciones de seguridad y evolución.
- Dependencia de quien lo mantiene, si no hay documentación ni código bajo tu control.
El coste que casi nadie calcula es el trabajo alrededor de la herramienta. Si tres personas dedican media hora al día a compensar lo que el software no hace, ese tiempo también forma parte de lo que cuesta la licencia.
Señales de que lo estándar es suficiente
- Tu proceso se parece al de la mayoría de empresas de tu sector.
- La herramienta cubre casi todo lo que necesitas y lo que falta es secundario.
- Hay integraciones o API para conectar lo que falta.
- El proceso no te diferencia de la competencia, como facturación, contabilidad, nóminas o correo.
- Necesitas empezar ya y no puedes dedicar tiempo a definir requisitos.
En estos casos, lo sensato es elegir bien, configurar bien e integrar bien.
Señales de que conviene desarrollar
- Tu hoja de cálculo ya funciona como una aplicación: tiene lógica, permisos informales y varias personas dependen de ella, pero sin historial ni controles.
- Pagas varias herramientas que cubren partes del proceso y ninguna comparte datos con las demás.
- El proceso forma parte de cómo compites o de lo que tus clientes valoran.
- Necesitas un portal para clientes, proveedores o socios que no existe como producto.
- Las licencias crecen más rápido que lo que aportan.
La respuesta habitual: combinar
En la práctica, el planteamiento más sensato para muchas pymes es este:
- Estándar para lo común. ERP, contabilidad, correo y CRM si encaja.
- Integración para que compartan datos. Un sistema que manda en cada dato y sincronizaciones con registro de errores.
- A medida para lo propio. Una herramienta interna, un portal o un panel de gestión que resuelve lo que ningún producto cubre bien.
Así se reduce el código propio que hay que mantener y el equipo no tiene que trabajar alrededor de una herramienta.
Cómo reducir la dependencia del proveedor
La objeción razonable al software a medida es qué ocurre si mañana no está quien lo hizo. Se reduce con condiciones que conviene pedir desde el principio:
- Código en tu repositorio y accesos a la infraestructura a nombre de tu empresa.
- Documentación técnica y de las decisiones de arquitectura.
- Tecnologías extendidas, con profesionales disponibles en el mercado.
- Entornos reproducibles y despliegues automatizados.
- Copias de seguridad comprobadas y un procedimiento de recuperación escrito.
Con eso, cambiar de proveedor tiene un coste asumible y no pone en riesgo la operación.
Por qué empiezo con una fase de descubrimiento
Un presupuesto cerrado de software sin fase de descubrimiento traslada toda la incertidumbre a una cifra. O se infla para cubrir riesgos, o se queda corto y termina en conflicto. Una fase de descubrimiento de dos a cuatro semanas define objetivos, usuarios, flujos, requisitos de rendimiento y seguridad, arquitectura, riesgos y un presupuesto por fases.
También sirve para responder a la pregunta de esta guía con información real. A veces la conclusión es que no hace falta desarrollar, y ese también es un buen resultado.
Una comprobación rápida
Antes de pedir presupuesto para un desarrollo, responde a estas preguntas:
- ¿He probado en serio al menos dos productos estándar?
- ¿Qué parte exacta del proceso no cubren y cuánto cuesta ese hueco al año?
- ¿Esa parte es propia de mi empresa o solo resulta incómoda?
- ¿Hay alguien interno que pueda validar flujos y probar entregas?
- ¿Qué pasaría si dentro de tres años tuviera que cambiar de proveedor?
Si después de esto el desarrollo sigue teniendo sentido, el siguiente paso es valorar una herramienta interna con un alcance acotado.
He preparado esta guía con ayuda de herramientas de IA para la estructura y la redacción. La he revisado y editado personalmente. Más información en la política editorial.