El precio inicial no demuestra la calidad de un desarrollo. Reutilizar componentes, limitar funciones o usar un servicio existente puede reducir el coste con criterio. El problema aparece cuando la oferta deja fuera trabajo que alguien tendrá que asumir: corregir datos, actualizar dependencias, atender incidentes o trasladar el sistema a otro proveedor.
Antes de elegir, separo lo que se ahorra de lo que se aplaza. Esta guía sirve para evaluar el coste durante la vida del producto. Para definir entregables y condiciones de contratación, continúa con la guía para comparar presupuestos de software.
Cómo calcular el coste total del software
Elige un horizonte común para todas las opciones: por ejemplo, 24 meses desde el arranque del proyecto. Es un periodo de comparación, no una promesa de vida útil. Anota cuándo empieza cada gasto, el volumen previsto y quién lo paga. Un coste desconocido queda pendiente de validar; no lo conviertas en cero.
Coste del periodo = inversión inicial + gastos recurrentes + cambios previstos + trabajo interno + transición o cierre. Registra las consecuencias de posibles incidentes aparte, como escenarios de riesgo. Si se materializan, incorpora su coste sin contar dos veces las mismas horas o pérdidas.
| Partida | Qué incluir | Cómo comprobarla |
|---|---|---|
| Puesta en marcha | Análisis, desarrollo, migración, pruebas y formación. | Entregables incluidos, tareas del equipo y exclusiones escritas. |
| Operación | Hosting, licencias, almacenamiento, copias, APIs y monitorización. | Unidades facturables, límites y fecha de inicio de cada servicio. |
| Mantenimiento | Correcciones, actualizaciones y adaptación a cambios externos. | Responsable, cobertura, revisión periódica y qué se presupuesta aparte. |
| Trabajo interno | Revisión manual, conciliación de datos, soporte y coordinación. | Horas observadas en un piloto, frecuencia y responsable. |
| Evolución | Cambios ya previstos en procesos, volumen o integraciones. | Supuestos por escenario y decisión que autoriza el gasto. |
| Salida o cierre | Exportar datos, transferir accesos, documentar y retirar servicios. | Una exportación utilizable y un procedimiento de traspaso probado. |
Calcula un escenario con el uso del piloto y otro con el volumen que el negocio quiere evaluar. Utiliza tarifas vigentes verificadas, estimaciones identificadas y tiempo interno medido. El coste de esas horas ayuda a comparar opciones, pero liberarlas no equivale automáticamente a ahorrar nóminas. No aplico un porcentaje universal de mantenimiento ni supongo que el desarrollo propio siempre gana frente a una herramienta existente.
Qué puedes recortar sin aplazar el problema
Recortaría primero usuarios objetivo, integraciones, personalización visual y funciones secundarias. Una revisión manual puede ser razonable con poco volumen si tiene responsable y cabe en la jornada. La guía para pasar de idea a MVP explica cómo reducir la primera entrega a una decisión de negocio comprobable.
Para el flujo que sí vas a poner en producción, deja explícitos permisos, recuperación de datos y tratamiento de errores. Su profundidad depende del riesgo del proceso. Una demo sin datos reales puede tener límites distintos a un sistema que ya atiende pedidos; el presupuesto debe indicar cuál se entrega.
Qué significa incluir mantenimiento
«Mantenimiento incluido» no basta para calcular costes. Yo pediría distinguir estas responsabilidades:
- Correcciones: qué comportamiento acordado se corrige, durante qué periodo y cómo se verifica.
- Actualizaciones: quién revisa dependencias y servicios externos, prueba los cambios y programa su despliegue.
- Soporte operativo: quién recibe una alerta, en qué horario y cómo continúa el negocio mientras se investiga. Tiempo de respuesta y tiempo de resolución son compromisos diferentes.
- Evolución: qué funciones nuevas requieren otra estimación y quién autoriza el trabajo.
Indica límites de cobertura, consumos de terceros y qué ocurre si se agota una bolsa de horas o cambia una API. Una suscripción no elimina esas decisiones; puede repartirlas entre tu equipo y varios proveedores.
El caso Adslyfy muestra registros de ejecución, fallos y capturas que permiten investigar comprobaciones de anuncios. Es evidencia de componentes operativos concretos, no una referencia de precio ni de ahorro. Esa capacidad de revisar qué pasó también necesita un responsable que actúe.
Ejemplo: una herramienta interna para gestionar solicitudes
Imagina una herramienta que recibe solicitudes, asigna un responsable y registra su resolución. Es un ejemplo hipotético. Una primera opción deja la asignación en manos de una persona; otra añade reglas automáticas, historial de cambios y una cola de excepciones. No compararía sus precios como si entregaran lo mismo.
En un piloto mediría cuántas solicitudes requieren revisión, cuánto tarda cada una, qué errores aparecen y quién los resuelve. El trabajo manual del periodo se puede estimar como solicitudes revisadas × minutos por revisión ÷ 60. Para expresarlo en dinero, usa un coste interno por hora documentado. Mantén separado el tiempo fijo de supervisión y evita contarlo de nuevo como soporte.
La opción manual puede ser adecuada si el volumen es bajo y la persona está disponible. La automatización puede merecer una segunda fase cuando la carga medida, los retrasos o los errores superen el límite acordado. La decisión depende de datos del proceso, no de una promesa genérica de ahorro.
Pruebas de continuidad antes de aceptar la entrega
- Desplegar la versión acordada con instrucciones y cuentas controladas por la empresa.
- Restaurar una copia en un entorno aislado y comprobar los registros recuperados.
- Simular un fallo del servicio externo y localizar la solicitud pendiente sin perderla ni procesarla dos veces.
- Verificar que la alerta llega a una persona responsable con información suficiente para actuar.
- Exportar los datos acordados y abrirlos fuera de la herramienta, conservando las relaciones necesarias.
- Comprobar que otra persona autorizada puede seguir el procedimiento operativo y retirar el acceso anterior.
Documenta qué se probó, el resultado y las limitaciones pendientes. El acceso al repositorio por sí solo no demuestra que otro equipo pueda operar el producto. Aclara también las licencias de componentes reutilizados y los accesos necesarios para desplegar.
Si el software ya existe: reparar, mantener o sustituir
Una compra barata que ha dado problemas no obliga a reconstruir todo. Primero revisaría el flujo crítico, los incidentes repetidos, las dependencias y la capacidad de desplegar y restaurar. La auditoría de un proyecto Laravel existente ofrece un punto de partida técnico para ese diagnóstico.
Compara el coste pendiente de cada opción desde hoy, incluyendo migración y operación en paralelo si hacen falta. El dinero ya gastado no demuestra que continuar sea mejor. Tampoco justifica una reescritura sin evidencias. Un parche acotado, una retirada gradual o una herramienta estándar pueden ser opciones válidas.
Qué preparar para revisar tu inversión
Trae el proceso que necesitas resolver, volumen actual, tareas manuales, sistemas implicados y lo que cubre cada propuesta. Marca los costes conocidos, las estimaciones y las partidas sin aclarar. Con eso puedo ayudarte a acotar un proyecto de software a medida y SaaS o revisar una decisión desde mi trabajo como CTO técnico.
Si estás valorando una compra o una recuperación, cuéntame el problema y los límites del presupuesto. El primer paso es identificar qué información falta para decidir, sin compartir credenciales ni datos de clientes.