Cuánto cuesta desarrollar una aplicación a medida (y cómo no tirar el dinero)
Por qué dos presupuestos por lo mismo se diferencian en un orden de magnitud, qué costes no aparecen en ninguna propuesta y las preguntas que hay que hacer antes de firmar nada.
· Desarrollo full-stack
Pides presupuesto para una aplicación y recibes cifras que no se parecen entre sí. No es que unos sean caros: es que cada uno ha entendido una cosa distinta, y ninguno lo ha dicho. Este artículo sirve para pedir bien y para leer lo que te llega.
Lo que de verdad mueve el precio
El coste de un desarrollo no depende de «cuántas pantallas tiene». Depende de cinco cosas:
- Cuántos tipos de usuario hay. Una aplicación con un solo tipo de usuario es un proyecto. Con tres —cliente, empleado, administrador— son casi tres proyectos, porque cada rol necesita sus permisos, sus pantallas y sus pruebas.
- Con cuántos sistemas se conecta. Cada integración —pasarela de pago, contabilidad, facturación electrónica, mensajería— es trabajo, y además es trabajo que no controlas: dependes de la documentación y de los cambios del otro.
- Si hay dinero de por medio. Cobrar exige seguridad, trazabilidad, gestión de devoluciones y estados de pago. Multiplica el esfuerzo.
- Si trata datos personales sensibles. Salud, datos de menores, información financiera. Implica requisitos legales que son diseño, no un párrafo en el aviso legal.
- Cuánta gente la va a usar a la vez. Diez usuarios internos y diez mil simultáneos no son la misma arquitectura ni de lejos.
Si el presupuesto que te llega no menciona estas cinco, no está presupuestando tu proyecto: está presupuestando una idea genérica.
Los costes que no aparecen en la propuesta
Y aquí está el motivo por el que muchos proyectos salen al doble de lo previsto:
- El alojamiento y los servicios. Servidor, base de datos, copias, dominio, certificados, correo transaccional. Es un coste mensual, para siempre.
- El mantenimiento correctivo. El software no se estropea solo, pero su entorno cambia: sistemas operativos, navegadores, librerías con vulnerabilidades, sistemas de terceros que modifican su forma de conectarse. Una aplicación sin mantenimiento deja de funcionar sola en dos o tres años.
- La migración de datos. Pasar lo que hoy vive en hojas de cálculo, con veinte años de inconsistencias, casi siempre cuesta más de lo que nadie estimó.
- La formación y el cambio de hábito. Si el equipo no la usa, el proyecto ha fracasado aunque el software sea perfecto.
- Los cambios. Van a existir. Lo que importa es que el contrato diga cómo se piden, cómo se valoran y quién los aprueba.
Una regla práctica: presupuesta el mantenimiento anual como una fracción relevante del desarrollo inicial. Si nadie te la ha mencionado, pregúntala antes de firmar.
El error que más dinero quema
Construir todo antes de que nadie lo use.
Se define el sistema completo, se firma, se desarrolla durante ocho meses y se entrega. Y en la primera semana de uso real aparece que el flujo principal no era ese, que faltaba un caso que ocurre todos los días y que la mitad de las funciones no las abre nadie.
La alternativa: lo mínimo que resuelve el problema principal, en producción y con usuarios reales, lo antes posible. Y a partir de ahí, decidir con datos qué se construye después. No es una moda: es la única forma de que el presupuesto se gaste en lo que se usa.
Antes de firmar, pregunta esto
- ¿De quién es el código? Que quede por escrito. Si no es tuyo, estás alquilando.
- ¿De quién son los datos y cómo los exporto? Pide ver una exportación real antes de empezar, no al final.
- ¿Qué pasa si desaparecéis? Repositorio accesible, documentación de despliegue, accesos a tu nombre. Un proyecto que solo puede tocar quien lo hizo es un proyecto secuestrado.
- ¿Qué incluye el mantenimiento y qué no? Con tiempos de respuesta escritos.
- ¿Cómo se valoran los cambios?
- ¿Qué tecnología y por qué? Si la respuesta no se entiende, hay dos posibilidades y una es mala.
Y la pregunta previa: ¿de verdad hace falta?
Vale la pena decirlo, aunque nos quite trabajo: muchos problemas que parecen requerir una aplicación a medida se resuelven antes con herramientas existentes bien conectadas. Un buen sistema de facturación, una base de datos compartida y dos automatizaciones resuelven una parte enorme de los casos, cuestan una fracción y se mantienen solos.
El desarrollo a medida se justifica cuando lo que haces es tu diferencia competitiva, cuando ninguna herramienta del mercado encaja, o cuando el coste de licencias por usuario ya supera al de construir. Fuera de esos casos, hay caminos más baratos.
Dónde está la frontera lo contamos en cuándo el Excel se queda corto.
Si esto es tu caso
Nosotros empezamos por ver si tu problema se resuelve sin desarrollar: eso es la auditoría de procesos e IA, y sale con un plan por escrito y una estimación honesta, incluida la de no construir nada. Si el desarrollo es la respuesta correcta, es desarrollo a medida. Y si el camino corto es automatizar lo que ya tienes, está en qué automatizar primero.
Somos Mindset & Code: automatización, datos y desarrollo para pymes y autónomos. Puedes ver qué hacemos y a qué precio.
Guía informativa. Cualquier estimación concreta depende del alcance, de las integraciones y del volumen de usuarios, y se hace por escrito antes de comprometer presupuesto.