--- title: "Cuánto cuesta desarrollar una aplicación" description: "Los únicos números que podemos publicar son los nuestros: qué cuesta un diagnóstico, qué orden de magnitud tiene un proyecto y de qué depende la cifra." canonical: https://caricalia.com/notas/cuanto-cuesta-desarrollar-una-aplicacion last-updated: 2026-09-08 --- # Cuánto cuesta desarrollar una aplicación > Nadie puede darte un precio de mercado honesto. Sí se puede explicar de qué depende la cifra y cómo se compone un presupuesto por fases. Publicado: 2026-09-08 Autor: carlos Temas: precio, presupuesto, producto --- ## La respuesta corta, con nuestros números Aquí un diagnóstico de producto y arquitectura cuesta 2.900 € + IVA y dura tres semanas. Un proyecto de software en producción va de doce a dieciséis semanas y se cierra por fases, con el precio de cada fase por escrito antes de empezarla. Después existe una cuota mensual de evolución, para seguir con el sistema una vez entregado. Su importe se fija al cerrar el proyecto, según lo que se haya construido y cuánto se mueva. Esos son los únicos números que vas a leer aquí. No hay tabla de «una app sencilla cuesta X y una compleja cuesta Y»: quien te la enseñe no ha visto tu sistema, no sabe cuánta gente lo usa y no sabe qué hay ya construido. ## De qué depende de verdad la cifra Casi nunca del número de pantallas. Lo primero que miramos es **qué parte del sistema hay que tocar**. No cuesta lo mismo añadir una pantalla al margen que cambiar cómo se guarda un pedido; lo segundo obliga a revisar todo lo que lee ese pedido, y en un sistema con años encima eso alcanza a buena parte de la aplicación. Después viene la pregunta del dinero. Cobros, facturación, nóminas, conciliación: en cuanto una operación mueve dinero deja de valer que funcione casi siempre. Hay que decidir qué pasa cuando falla a medias, quién se entera y cómo se deshace. También cambia la cifra según cuánta gente dependa de que el sistema siga en pie. Con tres personas dentro y ningún cliente fuera, puedes arreglar en caliente lo que se rompa. Con clientes fuera, cada despliegue necesita poder deshacerse. Y queda el estado de lo ya construido. Un sistema con las reglas de negocio escritas como pruebas se puede tocar sin miedo. Uno donde nadie sabe qué pasa si cambias un campo obliga a averiguarlo primero, y averiguarlo son semanas antes de escribir una línea. ## Qué encarece y qué abarata Sin euros, porque los euros dependen de tu caso. Esta es la lista con la que calibramos cuando leemos un sistema. | Encarece | Abarata | |---|---| | Un fallo puede parar la operación o incumplir una norma | El peor caso es que alguien repita una tarea a mano ese día | | Hay que integrarse con sistemas de terceros que no controlas | Todo vive dentro de tu propia base de datos | | Nadie del equipo original sigue en la empresa | Quien lo escribió está y puede contestar en media hora | | Los datos históricos hay que migrarlos y cuadran mal | Se arranca con datos nuevos | | Arrancar con urgencia, desplazando trabajo ya comprometido | La fecha de inicio es flexible | | El alcance se define sobre la marcha | Hay un diagnóstico previo con el alcance escrito | | Varias personas tienen que aprobar cada decisión | Decide una persona con nombre | La fila que más mueve el número es la primera. Un proceso que te cuesta mucho al año justifica un proyecto grande; uno que te cuesta poco no justifica este servicio, y es mejor saberlo en la semana uno. ## Cómo se compone un presupuesto por fases | Qué es | Duración | Precio | |---|---|---| | Diagnóstico de producto y arquitectura | 3 semanas | Cerrado, al empezar | | Producto en producción | 12 a 16 semanas | Por fases, precio de cada fase antes de empezar | | Evolución | Mensual | Según lo entregado | El diagnóstico es la puerta. Leemos el código y hablamos con quien usa el sistema todos los días. Sales con qué se rompe primero, qué cuesta arreglarlo y el plan por fases con el precio de cada una. Si la conclusión es que este año no toca hacer nada, también sale escrita. De ahí en adelante se cobra por hitos. Cada fase se cierra con una demostración en vivo del software funcionando. Hasta que esa demostración no se hace, el hito no se factura. La razón de partirlo es que el precio de la fase cuatro se calcula con lo que se aprendió en la tres. Un número dado en la semana cero para la semana catorce es una apuesta, y esa apuesta la acaba pagando alguien: o tú con un cambio de alcance, o nosotros bajando la calidad para llegar. ## Qué pasa con los presupuestos que se dan sin leer el código Un presupuesto emitido a partir de una llamada de una hora y un documento de requisitos supone que el sistema por dentro es como lo cuenta quien lo pide. En un sistema con años encima esa suposición falla en la parte cara: el módulo del que nadie se acuerda, la integración que se reconcilia a mano cada mes, el campo que significa dos cosas distintas según quién lo rellenó. Cuando eso aparece a mitad de proyecto hay tres salidas y ninguna es buena. Se amplía el presupuesto, se recorta alcance por debajo de lo que hacía falta, o se entrega algo que funciona en la demo y se cae el primer mes. Por eso separamos el diagnóstico y lo cobramos. Tres semanas de leer el sistema antes de comprometer una cifra no se regalan, y regalarlas obliga a recuperarlas en el precio del proyecto o a hacerlas mal. Si prefieres empezar por ahí, [pide un diagnóstico](/diagnostico). ## Preguntas que sirven para cualquier proveedor Pídele que te nombre las dos cosas que más podrían mover el precio que acaba de darte. Quien lo ha calculado las nombra; quien lo ha estimado a ojo contesta con generalidades. Pregunta qué pasa si en mitad del proyecto aparece algo que nadie sabía. Busca una respuesta que describa un procedimiento. Pregunta a nombre de quién quedan el repositorio, la infraestructura y las claves, y desde qué momento. Aquí van a tu nombre desde el primer hito y está en el contrato. Pregunta qué se enseña al cerrar cada fase. Un documento de estado en lugar del software funcionando delante de ti significa que el riesgo de la última semana lo llevas tú. Y pregunta quién va a escribir el código, con nombre y apellido. Comprueba que la respuesta sea la misma en la venta y en el arranque. ## Si todavía no tienes clientes Si lo que tienes es una idea y ningún cliente pagando, lo que necesitas es un [MVP](/glosario/mvp) montado rápido y barato para descubrir si alguien lo quiere. Eso hoy se hace con herramientas que cuestan una fracción de un proyecto, y ese trabajo queda fuera de lo que hacemos. Donde sí trabajamos es más adelante: cuando el sistema ya está en uso, hay clientes dentro y cada cambio cuesta más que el anterior. Cómo se aborda eso está en [software a medida](/software-a-medida), y si quieres poner un número a lo que tienes entre manos, [el diagnóstico existe para eso](/diagnostico).