Cómo presupuestar un proyecto de software cuando usas IA
Cómo presupuestar un proyecto de software cuando la IA escribe la mitad del código: tarifa mínima, tallas por entregable, colchón de riesgo e hitos de pago.
Te escribe un posible cliente: quiere un portal de reservas para su clínica, con pagos online y conectado a la agenda que ya usa. Y remata: "Como ahora programas con IA, saldrá bastante más barato, ¿no?".
Hace un año habrías estimado unas 150 horas. Ahora el agente genera un CRUD en diez minutos. La tentación es partir las horas por la mitad y cerrar el trato.
Saber cómo presupuestar un proyecto de software en este contexto es la diferencia entre cobrar lo que vale y pagar de tu bolsillo cada imprevisto. Porque la mitad del código no es la mitad del proyecto.
En corto: la IA abarata escribir código, pero no abarata entender el problema, decidir, revisar, integrar con los sistemas del cliente, probar, desplegar ni mantener. Si descuentas horas a ciegas, cobras de menos y te quedas con todo el riesgo. Presupuesta por entregable y por riesgo, con una tarifa mínima calculada y un alcance cerrado, no por horas de tecleo.
¿Qué es un presupuesto de software y qué incluye?
Un presupuesto de software es un compromiso de precio y alcance: qué vas a entregar, con qué criterio de aceptación, en qué plazo, por cuánto dinero y qué pasa cuando algo cambia.
No es una estimación de horas. La estimación es tu cálculo interno; el presupuesto es lo que firmas. Y lo que firmas cubre todo lo que puede salir mal, aunque la IA abarate algunas tareas. Incluye alcance, entregables, exclusiones, hitos de pago y una regla para los cambios.
Por qué la IA no abarata el proyecto entero
La IA acelera la parte del trabajo que más se ve: teclear. Y deja casi igual la que más tiempo consume en un proyecto con cliente real: averiguar qué quiere, decidir cómo hacerlo y demostrar que funciona.
Además, ni siquiera la parte de código se acelera tanto como crees. En el estudio de METR publicado en julio de 2025, 16 developers experimentados resolvieron 246 issues reales de sus repositorios. Con IA tardaron un 19% más. Antes de empezar esperaban ir un 24% más rápido y, al terminar, seguían creyendo que habían ganado un 20% (paper en arXiv).
El estudio tiene límites que el propio METR enumera: muestra pequeña, repositorios grandes que conocían a fondo y herramientas de principios de 2025. De hecho, METR cree que ya no refleja la situación actual: en su continuación de febrero de 2026 cree probable que hoy la IA sí acelere, aunque con datos débiles (los detalles, en el post sobre el estudio METR de productividad con IA). Para presupuestar, la lección sigue en pie: tu sensación de velocidad no es un dato. En un precio cerrado, cada hora mal descontada sale de tu margen.
Cómo presupuestar un proyecto de software paso a paso
El método tiene seis pasos:
- Calcula tu tarifa mínima por hora.
- Divide el proyecto en entregables con tallas.
- Marca qué acelera la IA y qué no.
- Añade el colchón de riesgo.
- Cobra por hitos.
- Cierra el alcance y cobra los cambios aparte.
Todas las cifras que siguen son un ejemplo inventado para ilustrar el cálculo, no datos de mercado. Sustitúyelas por las tuyas.
Paso 1: calcula tu tarifa mínima por hora
Tu tarifa mínima es lo que necesitas facturar por cada hora vendible para cubrir gastos y sueldo objetivo; por debajo de ella, pierdes dinero aunque el cliente esté contento.
Ejemplo: quieres ingresar 36.000 USD al año antes de impuestos y tu negocio gasta 6.000 USD (equipo, software, suscripciones de IA, gestoría, seguros). Necesitas 42.000 USD.
Trabajas 45 semanas de 40 horas: 1.800 horas. No todas se facturan: ventas, administración y formación se comen tiempo. Con un 60% facturable te quedan 1.080 horas. 42.000 / 1.080 = 38,89 USD. Redondea hacia arriba: 40 USD/h es tu suelo, no tu precio.
Si tu tarifa por hora como developer está por debajo, ningún método te salva. En cómo pasar de consumir tutoriales a facturar con código tienes el marco para elegir qué proyectos aceptar.
Paso 2: divide el proyecto en entregables con tallas
No estimes "el portal". Estima piezas que el cliente pueda ver y aceptar. Asigna a cada una una talla: S (hasta 6 h), M (7-12 h), L (13-24 h) y XL (más de 24 h). Si algo sale XL, pártelo o trátalo como riesgo.
Paso 3: marca qué acelera la IA y qué no
Repasa cada entregable y pregúntate qué parte es escribir código conocido. Boilerplate, CRUD, formularios, tests de casos claros y plantillas de email se aceleran. Descubrimiento, decisiones de arquitectura, integración con sistemas del cliente, QA, despliegue y reuniones, apenas.
Y añade una tarea que antes no existía: revisar lo que genera la IA. Si no la presupuestas, la haces gratis. Un método para que esa revisión sea rápida y verificable es la Revisión por Contrato.
Este es el ejemplo completo del portal de reservas. Las horas con IA son un supuesto del ejemplo, no una medición:
| Entregable | Talla (con IA) | Horas sin IA | Horas con IA | Nota |
|---|---|---|---|---|
| Descubrimiento y especificación | L | 16 | 16 | Hablar con el cliente no se acelera |
| Modelo de datos y arquitectura | M | 8 | 8 | Decisión tuya, la IA solo propone |
| Autenticación y roles | M | 12 | 8 | Patrón conocido |
| CRUD de citas y panel de administración | M | 24 | 12 | Boilerplate puro: donde más ahorra |
| Integración con la agenda actual del cliente | XL | 28 | 26 | API sin documentar: el riesgo real |
| Pasarela de pago | M | 12 | 10 | Webhooks y casos límite a mano |
| Notificaciones por email | S | 6 | 3 | Plantillas |
| Tests automatizados | M | 12 | 8 | Los casos los decides tú |
| Revisión del código generado por IA | M | 0 | 10 | Tarea nueva |
| QA con el cliente y correcciones | L | 16 | 16 | Depende del cliente, no de ti |
| Despliegue, CI y monitorización | M | 8 | 7 | Poco código, mucha configuración |
| Reuniones y gestión | M | 10 | 10 | Igual que siempre |
| Total | 152 | 134 | 18 h menos (11,8%) |
La IA "escribe la mitad del código", pero el proyecto baja un 11,8% en este supuesto. Si hubieras partido las 152 horas por la mitad, habrías presupuestado 76 horas: 3.040 USD. El trabajo real con IA son 134 horas: 5.360 USD sin colchón.
Pasar de idea a producto con un agente sin perder el control de estas fases es lo que trabajamos en el curso Construye con IA.
Paso 4: añade el colchón de riesgo
Añade un colchón sobre las horas con IA, mayor cuanto más incierto sea el proyecto. En el ejemplo, un 25% por la integración XL: 134 × 1,25 = 167,5 horas. A 40 USD/h, el presupuesto es 6.700 USD.
Compáralo con los 3.040 USD del descuento a ciegas: la diferencia son 3.660 USD: 2.320 de trabajo que harías gratis seguro (5.360 − 3.040) y 1.340 de riesgo que asumirías sin cobrarlo.
Paso 5: cobra por hitos
Liga cada pago a un entregable aceptado, no a una fecha. En el ejemplo: 30% a la firma (2.010 USD), 40% con la versión de pruebas funcionando (2.680 USD) y 30% en la aceptación final (2.010 USD). Total: 6.700 USD. Si el cliente desaparece a mitad, no has trabajado gratis.
Paso 6: cierra el alcance y cobra los cambios aparte
El precio fijo solo funciona con un alcance escrito: qué entra, qué no entra y cómo se acepta cada pieza. Eso es una especificación, y es lo que trabajamos en el workshop SDD + Agentic Engineering: la misma spec que guía al agente sirve de contrato con el cliente.
Todo lo que esté fuera de ese documento es un cambio y se presupuesta aparte. Sin esa regla, el colchón se gasta en peticiones nuevas.
Precio fijo, por horas o por valor: cuál elegir
Si el alcance se puede escribir, cobra a precio fijo por entregable: es el único modelo en el que el ahorro de la IA se queda en tu margen. Cobra por horas solo el descubrimiento o lo que no tenga alcance claro.
| Precio fijo | Por horas | Por valor | |
|---|---|---|---|
| Qué cobras | Entregables cerrados | Tiempo trabajado | Parte del resultado para el negocio |
| Efecto de la IA | El ahorro real es tu margen | El ahorro se lo queda el cliente | Irrelevante para el precio |
| Encaja cuando | El alcance se puede escribir | El alcance no está claro | El impacto se puede medir |
| Limitación / riesgo | Si estimas mal, pierdes tú | Te penaliza ser rápido; el cliente discute cada hora | Difícil de vender y de medir en un MVP |
Mi opinión: para un freelance que trabaja con IA, el precio fijo por entregable con cambios aparte es el modelo por defecto. Es el único donde ser más rápido te beneficia a ti.
El debate es anterior a la IA. En un hilo de Hacker News de 2013 sobre precio fijo frente a horas, un usuario escribía: "Something that use to take me 10 hours to design may now take me 2 hours. Should I discount the knowledge and skill it took to learn that?".
Otro describía su modelo: precio fijo según el alcance inicial y facturación aparte para soporte y para "additions to scope or changes that occur after sign-offs" (comentario).
La IA ha añadido un giro. En un comentario de diciembre de 2025, un developer que arreglaba apps generadas con IA explicaba que esos trabajos están mal pagados porque el cliente espera que "mostly everything is now done" y que tú, con IA a tu disposición, solo escribas "a better magic prompt". Esa expectativa es la que tu presupuesto tiene que desmontar.
Qué responder cuando el cliente pregunta por qué no es más barato
Esta respuesta está lista para copiar y adaptar:
"Uso IA, y por eso este presupuesto ya es más ajustado. Pero la IA acelera escribir código, que es solo una parte. No acelera entender tu negocio, integrar con tu agenda actual, probar con tus datos ni desplegar con garantías. Y todo lo que genera lo reviso yo, porque el responsable de que funcione sigo siendo yo.
Te doy un precio cerrado por entregables: si surge un imprevisto, lo asumo yo. Solo se presupuestan aparte los cambios de alcance."
El argumento clave es el último: con precio cerrado, el riesgo lo asumes tú, y eso tiene un precio.
Límites de presupuestar así
Este método para presupuestar un proyecto de software no elimina la incertidumbre; tiene cuatro límites.
La estimación sigue siendo incierta. El cono de incertidumbre de Steve McConnell y Construx sitúa el error de una estimación en fase de concepto inicial entre 0,25x y 4x del resultado real, y aun así lo presenta como el mejor caso: "results can easily be worse". Con una definición de producto aprobada, el rango baja a 0,5x-2x. Por eso no se presupuesta sin especificación.
Los proyectos legacy rompen las tallas. Sin tests ni documentación, la IA ayuda poco y estimar por entregable es adivinar. Cobra primero un diagnóstico por horas y presupuesta después.
Hay clientes que no saben lo que quieren. Con ellos el precio fijo es una trampa: vende primero un descubrimiento pagado y cierra el precio cuando el alcance esté escrito.
El colchón no cubre un cambio de alcance. El 25% está para imprevistos de lo pactado, no para funcionalidades nuevas. Si los mezclas, regalas trabajo. Y si el proyecto incluye agentes de IA en producción, calcula también su coste de fallo: está explicado en cuánto cuesta de verdad un agente que falla.
Por dónde empezar a presupuestar un proyecto de software
En tu próximo presupuesto, añade una fila de revisión del código generado y otra de colchón, y separa por escrito el alcance de los cambios. Si quieres que esa especificación sea sólida, el libro de Spec-Driven Development explica cómo escribirla. Y si buscas más fuentes de ingreso, repasa las tres vías para ganar dinero en internet.
La IA te hace más rápido escribiendo. Cobra por el resultado y por el riesgo que asumes, no por lo rápido que escribes.
Preguntas frecuentes
¿Debo cobrar menos si uso IA para programar?
No necesariamente. La IA reduce el tiempo de escribir código, no el de descubrimiento, integración, QA ni despliegue, y añade revisión. Aplica el ahorro solo donde sea real.
¿Cómo calculo mi tarifa por hora como developer freelance?
Suma tu ingreso objetivo anual y tus gastos del negocio, y divide entre tus horas facturables reales. En el ejemplo del post: 42.000 USD entre 1.080 horas da 38,89 USD, que se redondea a una tarifa mínima de 40 USD/h.
¿Es mejor presupuestar a precio fijo o por horas?
Con un alcance escrito, el precio fijo por entregables suele ser mejor para quien trabaja con IA, porque el ahorro se convierte en margen. Si el alcance no está claro, cobra el descubrimiento por horas.
¿Cuánto colchón de imprevistos debo añadir a un presupuesto de software?
No hay un porcentaje universal: el colchón crece con la incertidumbre del proyecto. El ejemplo del post usa un 25% por una integración sin documentar. Si el alcance es muy incierto, no cierres precio todavía: vende primero un descubrimiento pagado.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Quieres construir con agentes en serio?
Curso «Construye con IA» con Claude Code, de la idea al producto.
Developer con más de 15 años en frontend y creador de Dominicode. Escribe sobre IA aplicada al desarrollo de software.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.