El precio de una aplicación a medida no sale de una tarifa, sale del alcance, las integraciones, los usuarios y roles y el modelo de datos. Te desgloso de qué depende cada euro, con horas orientativas.
El precio de una aplicación a medida depende de cuatro variables concretas, no de una tarifa fija: cuánto abarca (el alcance), con cuántos sistemas se tiene que entender (las integraciones), cuánta gente distinta la usa y con qué permisos (usuarios y roles) y cómo de complejo es lo que guarda por dentro (el modelo de datos). Por eso una aplicación a medida puede costar 6.000 euros o pasar de 60.000 sin que ninguna cifra sea un abuso: no estamos hablando del mismo producto. En este artículo te enseño de dónde sale el número, partida a partida y con horas reales, desde el lado de quien construye el software, no de quien te lo intenta vender.
Antes de seguir: si lo que buscas es una web informativa o una tienda estándar, esto no es tu artículo. Para eso te sirve mejor cuánto cuesta una página web, donde desgloso el presupuesto de un sitio. Aquí hablo de otra cosa: una aplicación que hace funcionar un proceso de tu negocio, con su lógica, sus usuarios y sus datos. Un desarrollo de software a medida, no una web con formulario.
La expresión "aplicación a medida" describe una categoría entera, igual que "vehículo" abarca desde una bicicleta hasta un camión articulado. Dentro caben una herramienta interna para que tres personas dejen de pelearse con un Excel compartido y también una plataforma SaaS con miles de usuarios, suscripciones y un panel de administración completo. Las dos son software a medida. No cuestan lo mismo porque no hacen lo mismo.
El precio es casi siempre una función honesta de dos cosas: cuánto trabajo hay dentro y quién lo hace. Un desarrollo montado por alguien que cobra 15 euros la hora sobre una plantilla y una aplicación diseñada por un senior que la lleva hasta producción son productos distintos con un nombre parecido. El error del comprador no es pagar de más ni de menos, es comparar dos cosas que no son la misma. Lo que voy a hacer aquí es enseñarte a mirar dentro del número.
El alcance es el primer multiplicador y el que más se subestima. No es lo mismo "quiero gestionar pedidos" que la lista real de lo que eso significa: crear un pedido, editarlo, anularlo, ver su histórico, filtrar por estado, exportar a Excel, avisar por correo cuando cambia de fase y controlar quién puede hacer cada una de esas cosas. Cada verbo de esa lista son horas. Una aplicación no crece por el número de pantallas, crece por el número de casos que tiene que contemplar, incluidos los raros: qué pasa cuando dos personas editan lo mismo, qué pasa cuando falta un dato, qué pasa cuando alguien se equivoca.
La regla práctica: cuanto más vago es el encargo, más cara sale la sorpresa. "Una app para gestionar el negocio" no se puede presupuestar. "Una app donde el comercial da de alta el pedido, el almacén lo prepara y el administrativo factura, con estos cinco estados y estas tres alertas" sí. La diferencia entre esas dos frases es todo el proyecto.
Las integraciones son la partida más traicionera del presupuesto, porque el precio no lo pongo yo, lo pone el sistema del otro lado. Conectar tu aplicación con una pasarela de pago, tu CRM, tu ERP, un software de facturación o la API de un tercero es fácil de decir y difícil de estimar. Si la API está bien documentada y responde como debe, es cuestión de días. Si la documentación está desactualizada, devuelve errores sin explicación o el proveedor tarda una semana en contestar un correo, esa misma integración se va a semanas. La complejidad no vive en mi código, vive en aquello con lo que me tengo que comunicar.
Y hay un matiz: muchas veces la aplicación a medida existe precisamente para conectar sistemas que hoy no se hablan y para quitar de en medio el trabajo manual que hay entre ellos. Cuando ese es el objetivo, la parte de integración y automatización de procesos con IA no es un extra, es el corazón del proyecto, y pesa en el presupuesto en consecuencia.
Una aplicación que usa una sola persona y una que usan cuarenta con cinco roles distintos no se diferencian en la pantalla, se diferencian por debajo. En cuanto entran varios perfiles (administrador, gestor, comercial, cliente final) aparece toda una capa de trabajo que no se ve: autenticación, control de permisos por cada acción, auditoría de quién hizo qué, y la garantía de que un usuario no pueda ver ni tocar lo que no le corresponde. Eso es seguridad, y es de las cosas que más caro sale recortar, porque el día que un rol accede a datos que no debía, ya no es un bug, es un problema legal.
El salto de precio no es lineal con el número de usuarios, es escalonado con el número de roles y de reglas. Pasar de "todos ven todo" a "cada uno ve lo suyo" es uno de los escalones más caros que existen, y casi nunca aparece en la primera conversación.
El modelo de datos es el esqueleto de la aplicación, y determina si dentro de dos años se puede ampliar o hay que tirarla y empezar de nuevo. Cinco tablas que se relacionan de forma sencilla son una cosa; treinta entidades con dependencias entre ellas, histórico de cambios, versiones y reglas de negocio que dependen de combinaciones de datos son otra muy distinta. Un modelo de datos bien diseñado al principio es invisible y barato de mantener. Uno improvisado es una deuda que pagas cada vez que quieres añadir algo. Por eso dedico horas al diseño antes de escribir la primera línea: es el trabajo que menos se ve y el que más dinero ahorra a medio plazo.
Aquí está lo que casi nadie te enseña, el trabajo traducido a horas y las horas a euros. Uso mi tarifa de trabajo puntual, 45 euros la hora sin IVA, para que el número sea real. Insisto antes de que mires la tabla: esto son órdenes de magnitud, no un presupuesto. Sirven para entender de dónde sale el dinero y para oler cuándo una cifra no cuadra, no para encargar nada. El número de verdad sale de tu proyecto concreto.
| Tipo de aplicación | Horas orientativas | A 45 €/h (sin IVA) |
|---|---|---|
| Herramienta interna sencilla (un proceso, pocos usuarios, sin integraciones) | 130-330 | 6.000 € - 15.000 € |
| Aplicación de gestión media (varios módulos, roles, 1-2 integraciones) | 330-900 | 15.000 € - 40.000 € |
| Plataforma compleja (multiusuario, pagos, varias integraciones, panel completo) | 900 o más | 40.000 € en adelante |
Lee la tabla en vertical y verás las cuatro variables trabajando: cada escalón añade alcance, integraciones, roles y complejidad de datos a la vez. No es que en el escalón de arriba cobre más por lo mismo, es que hay más cosas dentro. Cuando un presupuesto de aplicación te llega en una sola línea con un número final, lo que te están ocultando es precisamente este desglose, y sin él no puedes saber si el precio es alto, bajo o justo.
Un presupuesto serio de aplicación a medida no sale de una tarifa de catálogo, sale de un análisis funcional previo. Antes de darte una cifra firme necesito entender qué procesos vas a mover a la aplicación, quién la va a usar, con qué sistemas se tiene que conectar y qué datos maneja. Ese análisis es lo que convierte "una app para el negocio" en una lista de partidas con horas, y es lo que permite que el número sea discutible en vez de un misterio.
Así es como trabajo yo: el análisis funcional inicial y la primera consulta no te los cobro. De ahí sale el alcance escrito, y sobre ese alcance te doy la forma de facturar que encaje con tu caso:
Tienes los packs y las tarifas desglosados en la página de tarifas. Y algo que va en el precio aunque no sea una línea del presupuesto: el código es tuyo y detrás no hay un equipo rotando ni un junior aprendiendo con tu presupuesto, estoy yo de principio a fin.
El precio de una aplicación a medida no es caro ni barato en abstracto, es coherente o incoherente con el trabajo que hay dentro. La cifra honesta sale de cuatro variables (alcance, integraciones, usuarios y roles, modelo de datos) traducidas a horas reales, no de un número redondo puesto a ojo. Si te llega un presupuesto de aplicación en una sola línea, no lo puedes juzgar: pide que te lo desglosen por partidas y verás enseguida si quien lo firma ha entendido tu proyecto o solo ha puesto un precio.
Si tienes una idea de aplicación entre manos y quieres saber con qué orden de magnitud estamos hablando, cuéntame tu proyecto y salimos de dudas con un análisis inicial sin coste ni compromiso.
Depende del alcance, las integraciones, los usuarios y roles y el modelo de datos. Como orden de magnitud, una herramienta interna sencilla suele partir de unos 6.000 euros, una aplicación de gestión media se mueve entre 15.000 y 40.000, y una plataforma compleja con multiusuario, pagos e integraciones supera los 40.000. La cifra firme sale de un análisis funcional de tu caso concreto, no de una tarifa de catálogo. Mi tarifa de trabajo puntual es de 45 euros la hora sin IVA.
De cuatro variables concretas: el alcance (cuántos casos tiene que contemplar la aplicación), las integraciones (con cuántos sistemas ajenos se tiene que entender, como un CRM o un ERP), los usuarios y roles (cuánta gente la usa y con qué permisos) y el modelo de datos (cómo de complejo es lo que guarda por dentro). Cada una de esas variables multiplica las horas, y las integraciones son la más difícil de estimar porque el coste lo pone el sistema del otro lado, no mi código.
Porque casi nunca describen el mismo trabajo. Un desarrollo montado sobre una plantilla por alguien que cobra 15 euros la hora y una aplicación diseñada por un senior que la lleva hasta producción son productos distintos con un nombre parecido. Cuando un presupuesto viene en una sola línea con un número final, te falta el desglose por partidas para saber si el precio es alto, bajo o justo. Pide siempre ese desglose antes de comparar.
Partiendo de un análisis funcional previo, no de una tarifa fija. Antes de dar una cifra firme hay que entender qué procesos va a mover la aplicación, quién la va a usar, con qué sistemas se conecta y qué datos maneja. Ese análisis convierte una idea vaga en una lista de partidas con horas. En mi caso, el análisis funcional inicial y la primera consulta no se cobran, y de ahí sale una estimación cerrada o una bolsa de horas según tu proyecto.
La estimación cerrada conviene cuando el proyecto está bien definido y quieres previsibilidad: acordamos el alcance con detalle y te doy un precio fijo, asumiendo yo el riesgo de que lleve más horas. La bolsa de horas mensual encaja cuando el trabajo es continuo o el alcance no se puede cerrar de antemano, como evolutivos y mantenimiento. La tarifa por hora baja con el compromiso, de 45 a 28 euros la hora sin IVA, sin permanencia. El detalle está en la página de tarifas.
Si tienes un problema parecido y quieres una opinión técnica, cuéntamelo. Te respondo en menos de 24 h laborables.
