Guía

Qué cuesta desarrollar un software a medida: guía sin rodeos

"¿Y esto, más o menos, cuánto cuesta?" Es la primera pregunta de casi todas las conversaciones que tenemos, y la que menos respuestas honestas encuentra en internet. La respuesta estándar del sector es "depende", que es verdad, pero dicha a secas es una evasiva. Este artículo es nuestro intento de responder como nos gustaría que nos respondieran a nosotros: con la estructura del coste, órdenes de magnitud reales y las trampas señaladas con el dedo.

Por qué nadie publica precios (y por qué damos rangos igualmente)

No hay conspiración: es que no existe "un software a medida", igual que no existe "una reforma". Una cocina de tres metros y una casa entera son reformas, y sus precios no se parecen en nada. Publicar cifras cerradas sin conocer el proyecto sería mentir en una dirección u otra.

Pero el silencio total tiene un coste que paga siempre el cliente: sin ninguna referencia, no puedes distinguir un presupuesto serio de un abuso, ni saber si tu idea es de mil euros o de cien mil antes de sentarte con nadie. Por eso creemos que lo honesto es dar rangos orientativos y explicar qué los mueve. Vamos a ello.

Lo que de verdad mueve el precio

• Número de flujos y de roles. Es el factor más subestimado. "Una app para gestionar pedidos" puede ser un flujo con un rol, o doce flujos con cliente, repartidor, cocina y administración. Cada rol multiplica pantallas, permisos y casos límite. Cuando pedimos que nos cuenten el proyecto por flujos (quién hace qué, paso a paso), estamos calculando esto.
• Integraciones. Cada sistema externo con el que hay que hablar (tu ERP, la pasarela de pago, esa API del proveedor) añade trabajo y, sobre todo, incertidumbre: la calidad de la documentación ajena no la controlamos ni nosotros ni tú.
• IA. Añadir extracción de documentos o un asistente no es "activar una casilla": exige evaluar el modelo con tus casos reales, diseñar la revisión humana y medir el acierto. Aporta muchísimo valor cuando la tarea lo pide, y suma coste siempre.
• Volumen de datos y usuarios. No cuesta lo mismo un sistema para diez usuarios internos que uno que debe aguantar a cientos de personas a la vez. La escalabilidad que no se necesita es dinero tirado; la que se necesita y no se puso, mucho más.
• Diseño. Entre "interfaz limpia y funcional" y "experiencia con identidad propia hasta el último detalle" hay un mundo de horas. Ninguna opción es incorrecta; conviene decidirla a conciencia y no por inercia.

Rangos orientativos, con todas las cautelas

Lo que sigue son órdenes de magnitud del mercado español, puramente orientativos. No son un presupuesto, ni el nuestro ni el de nadie: son la referencia mínima para que no entres a ciegas a la primera reunión.

• Herramienta interna sencilla (un flujo claro, pocos usuarios, sin integraciones raras): se mueve en los miles de euros bajos. Si te piden mucho más para esto, pregunta por qué; si te piden cientos de euros, pregunta también, porque algo no han entendido.
• Portal o backoffice completo (varios roles, varios flujos, alguna integración, panel de administración): hablamos de decenas de miles, en la banda baja-media.
• Plataforma tipo campus o producto con IA (muchos roles, motor propio para exámenes, reservas o lo que sea tu núcleo, IA integrada, volumen real de usuarios): decenas de miles, en la banda alta.

Y una regla para leer cualquier cifra, incluidas estas: si alguien te da un precio cerrado sin haber entendido tus flujos, desconfía en las dos direcciones. El barato improvisado y el caro improvisado fallan igual; solo cambia cuánto duele.

El coste que casi nadie te cuenta

El desarrollo inicial es la entrada; el software es la casa, y las casas se mantienen. Dependencias que hay que actualizar, seguridad que vigilar, pequeños ajustes cuando el negocio cambia (que cambiará). Un software sin mantenimiento no se queda quieto: se degrada, porque el mundo alrededor se mueve.

Como regla orientativa, reserva cada año una fracción del coste inicial (del orden del 10 al 20 %) para mantenimiento y evolución. Si una propuesta no menciona este capítulo, no es más barata: es menos honesta.

Cómo abaratar sin romper nada

Hay dos maneras buenas de bajar el precio y varias malas. Las buenas:

• Fase 1 con el núcleo viable. Identificar el 20 % de funcionalidades que hace el 80 % del trabajo y construir solo eso. El resto se decide después, con el sistema en marcha y datos reales (y la mitad de esa lista, curiosamente, deja de parecer urgente).
• Reutilizar donde no te diferencias. Pagos, correo transaccional, facturación, autenticación: existen servicios excelentes por poco dinero al mes. Reconstruirlos a medida es pagar por reinventar la rueda. El desarrollo a medida debe concentrarse donde está tu diferencia, no en la fontanería estándar.

Las malas: recortar en el diseño de los datos, en las pruebas o en la seguridad. Ahí no se ahorra: se aplaza el pago, con intereses.

Qué debe incluir un presupuesto serio

Para comparar peras con peras, exige que cada propuesta responda a esto por escrito:

1. Alcance descrito por flujos, no por tecnologías. "Gestión de pedidos con estos cuatro pasos y estos tres roles" se puede verificar; "desarrollo web full-stack" no significa nada.
2. Qué queda explícitamente fuera. Es el párrafo más valioso del documento y el que más presupuestos omiten.
3. Quién desarrolla de verdad: si el equipo que te vende es el que programa, o hay subcontratación de por medio.
4. Propiedad del código y de los datos. Tuya, por contrato, sin ambigüedad.
5. Plan de mantenimiento con precio, no un "ya lo hablaremos".
6. Cómo se gestionan los cambios de alcance, porque los habrá: cómo se estiman, cómo se aprueban, cuánto cuestan.

Con esas seis respuestas delante, dos presupuestos se pueden comparar de verdad. Sin ellas, estás comparando números que no miden lo mismo, y el más barato sobre el papel es, con demasiada frecuencia, el más caro al final.

---

¿Hablamos? Si esto te suena a tu situación, cuéntanos tu caso (te respondemos nosotros).