Pides tres presupuestos de desarrollo de software, comparas cifras, eliges la agencia que te da más confianza y firmas un alcance cerrado. Todo parece bajo control: sabes cuánto vas a pagar y cuándo vas a tener el producto. Tres semanas después, en la primera reunión de seguimiento, aparece algo que no estaba en el documento inicial: un flujo que no tenía sentido tal como se diseñó, un requisito legal que nadie mencionó, una integración que pide tu primer cliente. La respuesta de la agencia es educada pero firme: eso es un cambio de alcance y hay que presupuestarlo aparte.
No es mala fe. Es la consecuencia lógica de un modelo que exige fijar el precio antes de construir nada. El problema no es la agencia, es la premisa: nadie puede saber con precisión qué necesita un producto hasta que lo construye y, sobre todo, hasta que lo pone delante de usuarios reales. El presupuesto cerrado da la sensación de control que busca todo fundador, pero es una ilusión: el software no es una obra con planos fijos, es un proceso de aprendizaje, y ese aprendizaje casi siempre obliga a cambiar algo de lo que se firmó.
Este artículo no pretende convencerte de que el presupuesto cerrado sea una estafa. Explica por qué gestiona mal algo inevitable, el cambio, y compara con una forma distinta de repartir ese riesgo. No encontrarás tablas de precios: cualquier cifra sin conocer tu proyecto sería inventada.
Qué variables mueven realmente el coste de desarrollar software
Cuando alguien pregunta cuánto cuesta desarrollar software, la respuesta honesta es «depende», y depende de cosas concretas:
- Complejidad real del problema. No es lo mismo una pantalla de gestión que un flujo con pagos, permisos por rol y reglas de negocio que cambian por cliente. La complejidad suele estar en lo que no se ve en el boceto.
- Equipo necesario y su seniority. Un equipo senior cobra más por hora, pero toma menos decisiones que luego hay que deshacer. El coste de una mala decisión de arquitectura no aparece en la propuesta.
- Plazos exigidos. Comprimir plazos obliga a paralelizar trabajo o a recortar calidad. Ninguna de las dos opciones es gratis.
- Integraciones con sistemas existentes. APIs de terceros, datos heredados, herramientas internas: es donde más sorpresas aparecen y donde peor se estima sin explorar antes.
- Mantenimiento posterior. Casi nadie lo presupuesta al inicio y casi todo producto lo necesita: actualizaciones, errores, cambios de proveedores, nuevas funcionalidades.
Si alguien te da una cifra cerrada sin haber preguntado por estas variables, lo más probable es que sea una estimación optimista para cerrar el contrato, no un presupuesto real.
Agencia con presupuesto cerrado vs desarrollo por suscripción: dos formas distintas de repartir el riesgo
La diferencia de fondo no es el precio, es quién asume el riesgo de haber estimado mal.
En el modelo clásico, la agencia fija alcance, plazo y precio. Si estima corto, o pierde margen, o se protege con contratos rígidos y cláusulas de cambio. Si estima largo, tú pagas ese colchón de entrada. En ambos casos el incentivo apunta a defender el documento firmado, no a que el producto mejore.
En el modelo por suscripción o sprints cortos, pagas por capacidad de trabajo sostenida y recibes entregas continuas. No compras un alcance congelado; compras un equipo que cada semana trabaja en lo más valioso que sabes en ese momento. El riesgo de estimar mal se reparte distinto: tú decides la prioridad, el equipo se compromete con la calidad y el ritmo, y puedes parar cuando el valor ya no compense.
No es magia ni es siempre mejor. Si tu proyecto está muy acotado, es estable y los requisitos son realmente conocidos (algo menos habitual de lo que parece), un alcance cerrado puede funcionar bien. Pero si estás construyendo producto, es decir, aprendiendo, el modelo cerrado paga mal ese aprendizaje.
Cambios de alcance: el coste oculto que el modelo clásico no sabe gestionar
Aquí está el verdadero problema de fondo. Los cambios de alcance no son una anomalía, son la norma. Cualquier equipo que haya construido producto sabe que el primer diseño nunca sobrevive intacto al contacto con usuarios reales. La pregunta no es si habrá cambios, sino cómo está diseñado el modelo de trabajo para absorberlos.
En una agencia con presupuesto cerrado, un cambio activa un proceso casi burocrático: documentarlo, valorarlo, negociarlo, firmarlo en un anexo y, muchas veces, pausar el desarrollo mientras se resuelve el papeleo. Todo eso tiene un coste que no aparece en ninguna factura pero que pagas igualmente: semanas muertas, fricción con el equipo y la incómoda sensación de negociar constantemente con quien se supone que está de tu lado. Además, el contrato incentiva la rigidez: lo que está en el documento se entrega; lo que no, se factura aparte. Se premia cumplir el pliego, no que el producto mejore con lo que se aprende.
En un modelo por sprints o por suscripción, el cambio se gestiona distinto porque el modelo está pensado para iterar. No hay un documento de doscientas páginas que proteger: hay un ciclo corto, una demo y una conversación sobre qué priorizar ahora que sabes más que hace dos semanas. Si algo cambia, se reordena el backlog del siguiente sprint. No hay anexo que firmar ni negociación que reabrir, porque el compromiso es con la capacidad del equipo, no con un alcance congelado.
Esto no significa que en suscripción todo valga. Hay que priorizar con criterio, y alguien tiene que decir que no. Significa que el coste de adaptarse al aprendizaje real del negocio es mucho menor, porque la estructura del acuerdo no lo penaliza.
Qué preguntar antes de contratar una agencia de software (y qué señales de alerta buscar)
Si vas a contratar una agencia de software, hay preguntas que conviene hacer antes de firmar, no después del primer conflicto.
1. ¿Cómo gestionáis un cambio de alcance a mitad de proyecto? Pide un ejemplo concreto. Si la respuesta es vaga o se limita a «lo valoramos en su momento», ya sabes lo que te espera.
2. ¿Qué pasa si el proyecto tarda más de lo previsto? No porque vaya a pasar necesariamente, sino porque la respuesta te dice quién asume el riesgo de una mala estimación. Si lo traslada automáticamente a tu bolsillo o a tu calendario, el presupuesto cerrado es más una herramienta comercial que una estimación realista.
3. ¿Quién va a escribir el código? Pide nombres, seniority y disponibilidad real, no el perfil de la propuesta comercial. Es habitual que la reunión de venta la lidere alguien muy senior y que el trabajo diario lo ejecute un equipo junior con poca supervisión. No tiene por qué ser un problema si está bien gestionado, pero tienes derecho a saberlo.
4. ¿Habéis hecho descubrimiento técnico antes de darme la cifra? Desconfía de los presupuestos muy cerrados y muy baratos entregados sin que nadie preguntara por tus integraciones, tus restricciones legales o tu infraestructura. Esa cifra es una apuesta, no un presupuesto de desarrollo de software serio, y las apuestas, cuando fallan, las pagas tú.
Cómo lo planteamos en Divolut
No creemos que el objetivo sea ofrecerte el presupuesto más bajo sobre el papel. Creemos que cada euro que inviertas en desarrollo debe responder a un objetivo de negocio claro y que puedas ajustarlo cuando el contexto cambie, porque siempre cambia. Por eso trabajamos con desarrollo por suscripción: sprints semanales, demos reales y sin permanencias forzadas. Pagas por capacidad de trabajo senior, no por un pliego que se rompe en la primera reunión de seguimiento.
Eso implica liderazgo técnico senior desde la primera semana, no un comercial que vende el proyecto y un equipo junior que lo ejecuta sin supervisión. Si necesitas ese acompañamiento estratégico de forma más continuada, también lo planteamos como Fractional CTO: alguien con criterio técnico senior que toma contigo las decisiones de arquitectura y priorización, no solo entrega tareas.
No prometemos que nunca haya cambios de alcance; prometemos que cuando aparezcan no se convertirán en una negociación tensa, sino en parte natural del siguiente sprint.
Si quieres comentar cómo presupuestar tu proyecto sin atarte a un alcance que no sobrevivirá, hablemos.