Cuánto cuesta desarrollar una aplicación

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.

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

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.

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 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, y si quieres poner un número a lo que tienes entre manos, el diagnóstico existe para eso.