Presupuesto de software a medida: cómo se calculan los costes de desarrollo

Pedir el precio de una aplicación sin definir el problema suele devolver cifras poco útiles. No porque falte voluntad de presupuestar, sino porque el coste depende de decisiones que todavía no están tomadas: usuarios, procesos, datos, integraciones, seguridad y mantenimiento. Un presupuesto útil no intenta adivinar el producto final. Convierte una necesidad de negocio en un alcance que se pueda construir, probar y revisar.

La información que cambia una estimación

No necesitas un documento técnico para empezar. Sí ayuda responder con claridad a estas preguntas:

1. ¿Quién usará el sistema y qué tarea necesita completar?
2. ¿Qué ocurre hoy y dónde se producen esperas, errores o duplicados?
3. ¿Qué datos entran, quién puede verlos y dónde deben quedar guardados?
4. ¿Qué herramientas actuales deben conectarse al proyecto?
5. ¿Qué tiene que estar listo en la primera entrega y qué puede esperar?

Con estas respuestas se puede distinguir entre una automatización puntual, un panel interno, una aplicación para clientes o una plataforma más amplia.

Partidas que conviene separar

Un proyecto de software a medida no es solo escribir código. Para evitar comparaciones engañosas, separa al menos:

• descubrimiento y definición de alcance;
• diseño de flujos y experiencia de usuario;
• desarrollo e integraciones;
• pruebas, seguridad y puesta en marcha;
• mantenimiento, evolución y soporte posterior.

Esta estructura deja visible qué se está comprando. También permite reducir el alcance inicial sin ocultar tareas necesarias para que la solución sea usable.

Un presupuesto completo, con el alcance a la vista

Un presupuesto de software debe explicar qué resultado se construye, qué incluye la entrega, qué queda fuera y qué costes continúan después. El importe puede cambiar si se añaden usuarios o permisos, una integración, datos que migrar o un nivel de soporte distinto. Lo útil al comparar ofertas es saber qué condiciones explican la diferencia y qué sigue pendiente de concretar. Puedes plantear esa conversación con una idea inicial o con requisitos ya preparados; no necesitas calcular las horas por tu cuenta.

El desglose siguiente enseña a leer una propuesta con esas preguntas en mente. Puedes quedarte con la respuesta anterior y consultar los números solo si te ayudan a revisar partidas o supuestos.

Vamos a poner números a Cuaderno de equipo, una aplicación interna para guardar decisiones de proyectos. El encargo, las propuestas, las horas y los importes son ficticios y sirven para aprender a leer una cuenta; no son una tarifa de Ricardo ni una muestra de precios de mercado.

El alcance del ejercicio incluye una organización, tres roles, proyectos y decisiones, búsqueda, guardado en servidor, acceso del equipo, exportación, recuperación comprobada y entrega documentada. Quedan fuera vender a varias organizaciones, cobrar suscripciones, publicar aplicaciones móviles, migrar un histórico masivo y conectar sistemas de terceros.

Si cambian esas condiciones, cambia la comparación. Una demo que permite elegir un personaje de prueba no equivale a implementar el acceso real de un equipo; una exportación tampoco sustituye por sí sola a una recuperación comprobada.

Construcción inicial

En este desglose suponemos 140 horas a 50 € por hora, antes de impuestos:

Las partidas explican el cálculo. Para convertirse en una propuesta, además deben describir qué se recibirá y qué se considerará terminado. «24 horas de pruebas y entrega» no sustituye a acordar recorridos, errores relevantes y forma de revisar el resultado.

Lo que se repite después

El ejemplo añade estas partidas recurrentes, con importes netos:

La partida de mantenimiento debe decir para qué son esas horas, cómo se solicitan las tareas y qué ocurre si no bastan. No implica atención continua, mejoras ilimitadas ni una garantía de que cualquier incidencia se resuelva dentro de esa bolsa.

Tampoco hay que pagar dos veces la misma prestación: si las copias están incluidas en el alojamiento, se anotan como incluidas y no se suman otra vez. En nuestro ejercicio son partidas separadas.

Primer año, segundo año e impuestos

Con esos supuestos, el primer año suma 7.000 + 1.734 = 8.734 € netos. Dos años completos suman 7.000 + 2 × 1.734 = 10.468 € netos: la construcción no se repite cada año.

Para enseñar la conversión, el ejercicio aplica un impuesto del 21 % a todas las partidas. El resultado del primer año sería 10.568,14 € y el de dos años 12.666,28 €. En una propuesta real hay que leer la base y el impuesto de cada partida; no copiar el porcentaje del ejemplo por defecto.

Esto es una comparación de coste para un periodo, no un calendario de pagos. Los hitos de facturación, las fechas de renovación y la disponibilidad de caja se acuerdan aparte.

Qué ocurre cuando cambian las horas supuestas

Antes de cerrar el alcance puede haber incertidumbre. En vez de esconderla dentro de una cifra, muestra qué partidas pueden variar y por qué.

Manteniendo los 50 €/h del ejercicio, la construcción estaría entre 5.600 y 8.500 € netos. Son extremos de hipótesis didácticas, no un intervalo estadístico ni una promesa de que un proyecto real caerá dentro. Las partidas pueden depender unas de otras: añadir un permiso puede cambiar también interfaz y pruebas.

Para comprender una diferencia, modifica primero una variable. Si el trabajo de interfaz pasa de 24 a 28 horas y todo lo demás permanece, añade 4 × 50 = 200 € netos. Si incorporas una integración nueva, tendrás que describir sus reglas, errores y comprobaciones antes de asignarle horas.

La guía de estimación de costes de GAO incluye alcance, desglose, supuestos y análisis de sensibilidad entre los elementos de una estimación documentada. No aporta las horas ni los precios de este ejercicio; ayuda a entender qué debe poder explicarse detrás de una cifra.

Pasar del ejemplo a tu presupuesto

Usa el desglose editable para recoger partidas, qué cubren, exclusiones y frecuencia. El simulador de alcance e inversión permite conservar escenarios con tus propias hipótesis. Las horas describen esfuerzo; para hablar de calendario también necesitas disponibilidad, orden del trabajo y decisiones pendientes.

Si recibes varias propuestas, pasa a compararlas sobre el mismo alcance. Una suma de importes conocidos puede ser menor porque falta algo por valorar. Antes de tratarla como ahorro, pregunta qué queda sin concretar.

La guía para encargar software a medida reúne el recorrido desde la alternativa inicial hasta la entrega.

Cómo reducir incertidumbre antes de construir

La forma más segura de controlar presupuesto y calendario es trabajar por etapas. Primero se decide el problema y el flujo principal. Después se construye una versión que permita a usuarios reales completar esa tarea. Finalmente se incorporan mejoras basadas en el uso, no en una lista de deseos inicial.

Qué puedes preparar antes de una primera conversación

Reúne un ejemplo real del proceso: una plantilla, una captura anonimizada, los pasos de una tarea o la explicación de una incidencia frecuente. No hace falta compartir datos personales ni credenciales. El objetivo es entender el flujo, no recopilar información sensible.

También es útil identificar el resultado mínimo: por ejemplo, que un equipo pueda registrar una solicitud, asignarla y conocer su estado sin recurrir a mensajes dispersos. Esa definición evita que el primer proyecto intente resolver toda la empresa de una vez.

El siguiente paso

Si tienes una idea de producto o un proceso que ya no encaja en las herramientas actuales, revisa el servicio de desarrollo de software a medida. A partir de ahí se puede convertir el problema en un alcance comprensible antes de hablar de una propuesta.