La respuesta corta: horquillas para planificar, no tarifas
Como referencia de planificación a agosto de 2026, el diagnóstico inicial de InDroid tiene un coste de 0 euros; un blueprint puede situarse entre 1.200 y 3.500 euros; una automatización o integración acotada, entre 3.000 y 9.000 euros; un MVP, entre 7.000 y 20.000 euros; y un sistema construido por fases, entre 18.000 y 60.000 euros o más. El mantenimiento y la evolución pueden situarse entre 250 y 2.500 euros al mes, según cobertura, criticidad y ritmo de cambio.
Estas cantidades son horquillas orientativas de planificación, no una tarifa cerrada, presupuesto ni propuesta comercial. Están expresadas sin IVA y los servicios de terceros se presupuestan aparte. Tampoco incluyen automáticamente hardware, campañas, contenido, migraciones extensas ni trabajo de otros proveedores. Un mismo nombre —por ejemplo, «app de técnicos»— puede describir alcances radicalmente distintos.
La forma responsable de utilizar una horquilla es comprobar primero si el proyecto se parece al supuesto que la acompaña. Si faltan usuarios disponibles, datos representativos o documentación de las APIs, la incertidumbre debe reflejarse antes de contratar la construcción completa.
Qué supone cada rango orientativo
El extremo inferior presupone decisiones rápidas, datos disponibles, una experiencia de usuario sencilla y dependencias controladas. El extremo superior aparece cuando hay más excepciones, perfiles, canales, pruebas, seguridad, transición o responsabilidad operativa.
- 0 €: diagnóstico inicial para comprender objetivo, usuarios, flujo actual, restricciones y posible siguiente paso. No produce una especificación ni una estimación cerrada.
- 1.200–3.500 €: blueprint con entrevistas, mapa del proceso, prototipo, riesgos, arquitectura preliminar, fases y horquilla revisada. No incluye el producto terminado.
- 3.000–9.000 €: automatización o integración acotada, con una o pocas fuentes, reglas conocidas y mecanismos de prueba disponibles.
- 7.000–20.000 €: MVP centrado en un perfil y un flujo completo, con administración y seguridad proporcionadas, despliegue y prueba controlada.
- 18.000–60.000 € o más: sistema construido por fases, con varios roles, reglas propias, reporting, integraciones, implantación y pruebas más amplias.
- 250–2.500 €/mes: mantenimiento y evolución según infraestructura, monitorización, tiempos de respuesta, soporte, criticidad y capacidad reservada para cambios.
Por qué no existe un precio único por pantalla
Dos sistemas con diez pantallas pueden tener costes radicalmente distintos. Una pantalla que consulta datos fiables es diferente de otra que debe funcionar sin conexión, reconciliar cambios simultáneos, aplicar permisos por centro, adjuntar evidencias y mantener un registro auditable.
También cambia el trabajo invisible: preparar infraestructura, automatizar despliegues, registrar errores, proteger datos, recuperar copias, probar dispositivos y documentar la operación. Reducir la comparación al número de pantallas premia propuestas que dejan fuera precisamente los elementos que sostienen el sistema después del lanzamiento.
Las variables que más mueven el coste
Algunas variables aumentan horas de construcción; otras añaden riesgo. Una API no documentada puede requerir pocas líneas de código cuando funciona, pero semanas de coordinación si el proveedor no entrega credenciales o cambia las reglas. Ese riesgo debe aparecer como supuesto o fase de validación, no esconderse dentro de una cifra cerrada.
- Número de perfiles, centros, estados y reglas de autorización
- Cantidad de flujos y excepciones que deben quedar resueltos
- Calidad, volumen y responsabilidad sobre los datos que se migran
- Disponibilidad, documentación y límites de APIs de terceros
- Necesidad de uso offline, cámara, ubicación, firma o notificaciones
- Dispositivos, navegadores, sistemas operativos y publicación en tiendas
- Requisitos de privacidad, auditoría, continuidad y recuperación
- Nivel de pruebas, accesibilidad, documentación, formación y soporte
- Velocidad de decisión y disponibilidad de usuarios para validar
Tres ejemplos para entender los supuestos
Una herramienta interna para registrar solicitudes, asignarlas y consultar estado puede acercarse al rango de un MVP si utiliza un único perfil operativo, no migra históricos complejos y evita integraciones críticas. Si incorpora jerarquías, notificaciones, documentos, auditoría y conexión bidireccional con ERP, deja de ser el mismo alcance.
Una aplicación de técnicos puede empezar por agenda, ficha y parte digital. La operación offline, los mapas, el inventario, el cobro, las firmas y la sincronización con facturación pueden multiplicar pruebas y excepciones aunque el número de pantallas apenas cambie.
Un portal de pedidos puede reutilizar catálogo y clientes de un sistema existente. Si ese sistema carece de una API estable, los datos están duplicados o cada cliente tiene condiciones comerciales distintas, la integración y el gobierno del dato pasan a ser el centro del proyecto.
Una forma más segura de presupuestar
Empieza por un diagnóstico breve. Si el problema está claro pero el alcance no, separa un blueprint cerrado. Ese trabajo debería producir un mapa, un prototipo, dependencias, riesgos, fases, exclusiones y una horquilla revisada.
Después puede construirse un piloto con un flujo, un grupo de usuarios y datos representativos. La implantación añade migración, permisos, formación, transición e integraciones que ya hayan sido validadas. Cada fase necesita criterios de aceptación y una decisión explícita de continuar, corregir o detenerse.
Esta estructura no garantiza que nunca haya cambios. Sirve para que los cambios se detecten cuando todavía es posible decidir con información y no después de comprometer todo el presupuesto.
Costes que continúan después del lanzamiento
Pide que los costes recurrentes aparezcan separados de la construcción. Algunos crecen con usuarios, mensajes, almacenamiento o transacciones. Otros dependen del nivel de servicio acordado. El coste total de propiedad debe observar al menos los primeros años y dejar claro quién opera cada componente.
- Hosting, almacenamiento, copias, monitorización y transferencia
- Correo, SMS, mapas, firma, inteligencia artificial, pagos u otras APIs
- Cuentas de tiendas, certificados, dominios y licencias
- Correcciones, actualizaciones de seguridad y compatibilidad
- Atención a usuarios, administración de permisos y mantenimiento de catálogos
- Evolución funcional, analítica y nuevas integraciones
- Plan de recuperación, pruebas de restauración y respuesta a incidentes
Qué comparar entre propuestas además del total
Una propuesta barata puede ser adecuada si reduce el alcance de forma explícita. El problema aparece cuando dos importes parecen comparables pero uno omite implantación, pruebas o integraciones. Solicita una conversación sobre diferencias y no solo una nueva cifra.
- Alcance, exclusiones, supuestos y criterio de aceptación
- Qué entregable existe al final de cada fase
- Quién aporta datos, contenido, cuentas, accesos y decisiones
- Arquitectura, hosting, licencias y servicios de terceros
- Migración, publicación, documentación y formación
- Propiedad del código, acceso a repositorios y posibilidad de exportar datos
- Garantía, mantenimiento, nivel de servicio y respuesta a incidencias
- Tratamiento de cambios y de supuestos que no se cumplen
- Experiencia verificable en problemas o tecnologías relevantes
Calcula también el coste de no cambiar
Registra durante varias semanas el volumen y tiempo de tareas manuales, correcciones, retrasos, llamadas, incidencias y oportunidades perdidas. Añade el coste de licencias actuales y el riesgo de depender de una persona o archivo. Evita monetizar con falsa precisión aquello que todavía no puedes observar.
Una fórmula inicial puede ser: frecuencia mensual por tiempo medio por coste/hora, más errores y gastos directos. Separa ahorro potencial de ahorro realizable: una hora liberada solo produce retorno si el proceso y la organización pueden aprovecharla.
El proyecto compensa cuando reduce un coste o riesgo relevante de forma demostrable y sostenible, no solo cuando «digitaliza». Define una línea base, la fuente y el momento de revisión antes de construir.
Qué preparar para obtener una horquilla más fiable
No necesitas convertir esta información en un documento técnico. La guía sobre preparación de proyectos explica cómo reunirla para que varias propuestas respondan al mismo problema y puedan compararse con menos ambigüedad.
- Un ejemplo real del proceso de principio a fin
- Usuarios, responsables, volúmenes y excepciones frecuentes
- Pantallas, documentos o datos anonimizados que se utilizan hoy
- Sistemas existentes, proveedores y documentación de integración
- Restricciones de plazo, dispositivos, seguridad y presupuesto
- Una señal de éxito con su línea base, aunque sea aproximada