Guía · Coste de una app
Qué encarece una app,y qué te dice primero una demo.
El coste de una app lo marcan las conexiones que necesita, los datos que debe proteger y lo que tiene que hacer bien, no cuántas pantallas tiene. Esta guía explica qué mueve de verdad un presupuesto, cómo abaratar una primera versión, qué muestra una demo básica gratuita antes de gastar y cuándo es posible presupuestar por escrito.
Por qué el número de pantallas no sirve para calcular el precio
Cuando alguien pregunta cuánto cuesta una app, suele contar pantallas: un acceso, una lista, una ficha, unos ajustes. Las pantallas son la parte visible y también la más barata. Dibujar un formulario y mostrar una lista de registros es trabajo rutinario, y el desarrollo asistido por IA lo ha hecho aún más rápido.
Lo que lleva tiempo es todo lo que hay detrás: de dónde salen los datos, quién puede verlos, qué pasa cuando falla un pago o dos personas modifican el mismo registro a la vez. Dos apps con las mismas diez pantallas pueden costar varias veces más una que otra, porque una lee datos de ejemplo y la otra habla con tu programa de contabilidad, gestiona roles y cobra.
Así que, cuando compares presupuestos, compara lo que hay detrás de las pantallas, no cuántas son.
Qué encarece de verdad una aplicación
Cinco cosas mueven un presupuesto más que cualquier otra. Las integraciones con otros sistemas, porque cada programa externo tiene su propia interfaz, sus límites y sus formas de fallar, y cada conexión hay que probarla contra el comportamiento real. Las cuentas de usuario y los roles, porque en cuanto distintas personas ven cosas distintas, cada función tiene que respetar permisos. Los pagos y la normativa, porque cobrar implica devoluciones, recibos, reclamaciones y las normas de tu sector. La migración de datos, porque pasar años de hojas de cálculo o una base de datos antigua a una estructura nueva obliga a limpiar lo que nunca fue coherente. Y los cambios de alcance, porque una función añadida a mitad de proyecto suele tocar lo que ya estaba construido.
Las reglas de negocio quedan en medio: fáciles de describir, pero cada excepción que hoy resuelves a mano hay que escribirla y probarla.
Cómo reducir el coste de una app
La mayor parte del ahorro viene de decidir qué no hace la primera versión. Estas decisiones recortan coste sin recortar calidad:
- Empieza por un solo recorrido: el camino que un usuario hace más a menudo, completo, antes que nada más.
- Usa datos de ejemplo al principio, para que la estructura esté bien antes de conectar cuentas y sistemas reales.
- Reutiliza lo que ya pagas: un acceso existente, un proveedor de pagos, la exportación de tu contabilidad, en lugar de rehacerlos.
- Decide qué sigue siendo manual: una excepción que ocurre dos veces al mes la puede resolver una persona, no el código.
- Deja el alcance por escrito antes de empezar, para que los añadidos sean decisiones visibles y no sorpresas.
Nada de esto hace el producto más pequeño para siempre. Hace que la primera versión sea algo que puedes pagar, usar y ampliar.
Qué te dice una demo básica gratuita antes de gastar
Una demo básica es una pieza funcional de la idea: una pantalla, una página o un paso automatizado, con datos de ejemplo, sin cuentas y sin conexión con tus sistemas. En proyectos que encajan la construyo gratis con un alcance acordado, usando agentes de IA para ir rápido y revisando el resultado yo mismo.
Responde a preguntas que un documento no puede responder. Si el desarrollador te ha entendido. Si la idea sigue teniendo sentido cuando la ves en el móvil o en el navegador. Qué partes que creías imprescindibles resultan opcionales, y qué detalle pequeño resulta importante. Y, para los dos, si trabajar juntos es cómodo. Todo eso sale más barato aprenderlo con una pantalla que con un producto terminado.
- 01 Demo básica gratuita Una pieza, datos de ejemplo, sin cuentas. Alcance acordado, sin compromiso.
- 02 Primera versión o MVP El recorrido principal, completo: cuentas, datos guardados, errores controlados. De pago.
- 03 Proyecto completo Integraciones, roles, pagos, producción y traspaso. Presupuesto por escrito.
¿Cuándo puede darte un presupuesto un desarrollador?
Un presupuesto serio necesita un alcance definido: qué recorridos, qué cuentas, qué integraciones, qué plataformas y qué queda fuera. Mientras no exista, cualquier cifra es una suposición disfrazada de precio, y la suposición tiende a quedarse corta. Por eso no doy una cifra antes de la primera conversación, y por eso la demo suele ir primero: hace concreto el alcance.
Cuando el alcance está claro, recibes las funciones, un plazo orientativo y el precio por escrito. Cada proyecto se presupuesta por separado, porque no hay paquetes fijos que encajen con una app que habla con tus sistemas. Si el alcance cambia más adelante, el cambio también se acuerda por escrito, así el precio se mueve por razones que puedes ver.
Dudas antes de empezar
¿Por qué no puedes dar un precio antes de la primera llamada?
Porque el precio depende de lo que hay detrás de las pantallas: integraciones, cuentas, pagos, datos. Una conversación breve basta para averiguarlo. Después recibes un resumen del alcance por escrito y, cuando está definido, un presupuesto por escrito.
¿Una demo me compromete a algo?
No. La demo básica es gratuita una vez acordado un alcance que encaje, y no hay obligación de continuar. Usarla en tu negocio requeriría la implementación de pago, porque funciona con datos de ejemplo y sin cuentas.
¿Una app móvil es más cara que una app web?
A menudo sí, cuando tiene que publicarse en las tiendas de aplicaciones y funcionar en dos plataformas. Para muchos negocios basta con una app web que se instala en el móvil y cuesta menos; lo decidimos en la primera conversación.
¿Qué cambia el precio después del presupuesto?
Los cambios de alcance: una integración nueva, un tipo de usuario nuevo, una función que no estaba en el alcance escrito. Cada uno se acuerda por escrito antes de construirlo, así el precio no se mueve sin tu decisión.