Desarrollo de software a medida: qué cuesta construirlo y mantenerlo

El desarrollo de aplicaciones web a medida es la creación de software en navegador con lógica interactiva, autenticación por roles y base de datos dinámica. En 2027, el presupuesto europeo va de €12.000 a €25.000 para MVPs, €25.000 a €60.000 para portales B2B y €60.000+ para plataformas empresariales.

Esa frontera arquitectónica decide todo lo demás: el presupuesto de capital, el calendario de entrega, las obligaciones normativas de seguridad y el perfil técnico del equipo que deberías contratar. Tanto si estás definiendo una herramienta operativa interna como si consultas nuestra guía de desarrollo de portales web para una plataforma de clientes, este artículo detalla dónde cae realmente la línea técnica, qué cuesta construir software en producción en 2027 y qué partidas de un presupuesto responden a ingeniería real.

La prueba práctica es si el sistema tiene usuarios que inician sesión y datos que cambian como consecuencia de lo que hacen. Un sistema de reservas, un portal de distribuidores, una herramienta interna de presupuestos y un flujo de siniestros son aplicaciones. Una web corporativa con formulario de contacto no lo es, por muy bien construida que esté, y esta distinción marca el rango de precio.

Tres cosas las separan en términos de ingeniería. Una aplicación tiene autenticación y autorización, es decir, debe decidir no solo quién eres sino qué puedes ver. Tiene estado persistente que varias personas modifican a la vez, lo que trae transacciones, gestión de conflictos y registros de auditoría. Y tiene reglas de negocio que viven en el código y no en un documento, que es donde se va la mayor parte del esfuerzo de pruebas.

Mientras que el desarrollo web a medida se centra en arquitectura de marketing y presentación de contenidos, las aplicaciones gestionan estados autenticados y lógica transaccional. Si no se cumple ninguna de las tres, estás mirando una web y no deberías pagar precios de aplicación.

La mayoría de las empresas llega a esta pregunta por dolor operativo y no por estrategia teórica. Una hoja de cálculo compartida se ha convertido silenciosamente en el sistema de referencia, tres departamentos se envían versiones contradictorias por correo y ya se ha producido un error costoso de facturación o logística. Cuatro patrones operativos se repiten con frecuencia, y cada uno justifica construir una aplicación propia en lugar de seguir parcheando.

Una hoja de cálculo gobierna un proceso crítico. Tarifas dinámicas, asignación de stock, planificación de técnicos de campo. Funciona hasta que dos personas editan a la vez o hasta que se marcha quien programó las fórmulas originales.

Los clientes piden acceso directo de autoservicio a sus propios datos. Historial de pedidos, documentación aduanera, estado del proyecto en vivo y descarga de facturas. Enviar PDF por correo no escala, mientras que desarrollar portales web autenticados resuelve el cuello de botella. Tanto nuestra guía de desarrollo de portales web como nuestra guía del portal de clientes analizan esta arquitectura al detalle.

Entre dos sistemas principales falta un flujo de trabajo gobernado. El ERP conserva el inventario y el CRM gestiona los contratos comerciales, mientras un administrativo reteclea pedidos entre ambos cada tarde.

La herramienta estándar cubre el 70 % del proceso. El 30 % restante es justo donde se genera tu margen operativo, y ninguna configuración estándar llega hasta ahí.

Los presupuestos de ingeniería en Europa durante 2027 se estructuran en tres tramos comerciales principales: de €12.000 a €25.000 para aplicaciones web MVP enfocadas y portales de clientes, de €25.000 a €60.000 para plataformas SaaS B2B multitenant con control de acceso basado en roles y sincronización bidireccional con ERP o CRM, y de €60.000 a €120.000+ para sistemas empresariales de flujo de trabajo con inicio de sesión único (SSO), registros de auditoría inmutables y APIs de alta concurrencia. A diferencia de una web corporativa, el número de pantallas no indica nada. Puedes consultar nuestra tabla de precios para comparar alcances modulares.

Una regla fiable al evaluar propuestas es que el primer flujo funcional representa cerca de la mitad del presupuesto total. La otra mitad financia todo lo que hace que el sistema sobreviva en producción real: gestión idempotente de errores, casos límite de permisos entre organizaciones, migración automatizada de datos históricos desordenados y los informes de dirección que nadie pidió en la reunión inicial.

En proyectos productivos, el presupuesto técnico se reparte en proporciones estables: la ingeniería de API backend, base de datos y autenticación absorbe el 30 %; la arquitectura frontend en React o Next.js y la gestión de estado requieren el 25 %; la fase de descubrimiento, modelado de dominio y diseño del sistema supone el 15 %; las integraciones con ERP, CRM y pasarelas de pago ocupan un 15 %; y las pruebas automatizadas, el blindaje OWASP y las canalizaciones CI/CD completan el 15 % final.

La palanca más directa para contener el coste consiste en reducir roles de usuario antes que recortar pantallas. Cada rol adicional multiplica las matrices de autorización que deben diseñarse, validarse en el servidor y verificarse mediante pruebas automáticas. Un sistema con un único rol y veinte pantallas resulta sistemáticamente más económico que otro con cuatro roles y ocho pantallas.

Los clientes suelen imaginar las pantallas, pero los componentes visuales apenas representan entre un cuarto y un tercio del esfuerzo total de ingeniería. Por debajo se sitúan tres pilares arquitectónicos esenciales que determinan la estabilidad, la seguridad y los costes operativos a largo plazo. Conocer estos elementos permite evaluar cualquier propuesta con rigor técnico.

1. Pasarela de API y servicios de dominio. Las aplicaciones web modernas desacoplan la interfaz del navegador de la computación backend mediante un API gateway, utilizando REST, GraphQL o tRPC con contratos estrictos de TypeScript de extremo a extremo. La pasarela gestiona límites de peticiones, validación de cargas útiles con esquemas en tiempo de ejecución como Zod, claves de idempotencia en operaciones financieras y colas de reintento para webhooks externos. Los contratos tipados evitan roturas entre despliegues de frontend y backend.

2. Identidad empresarial y control de acceso basado en roles. Una aplicación multiusuario requiere una gestión de identidades apoyada en estándares OAuth 2.0, OpenID Connect (OIDC) y SAML 2.0 Single Sign-On (SSO). La canalización de autenticación controla tokens JWT de corta duración, rotación de tokens de refresco y autenticación multifactor. El control de acceso basado en roles (RBAC) valida permisos tanto en el middleware perimetral como en las consultas a base de datos, garantizando que clientes, gestores y administradores accedan únicamente a los registros autorizados.

3. Persistencia escalable y aislamiento multitenant en base de datos. La integridad relacional se fundamenta en almacenamiento compatible con ACID mediante PostgreSQL gestionado con Supabase o Prisma ORM. Las políticas de Row-Level Security (RLS) imponen el aislamiento criptográfico y lógico entre organizaciones directamente en el motor SQL, impidiendo fugas de datos incluso en consultas analíticas complejas. Las copias de seguridad point-in-time (PITR) y las migraciones versionadas protegen los registros sin dependencia cautiva de un proveedor.

Las pruebas automatizadas atraviesan los tres pilares. En un sistema transaccional lo decisivo no es solo que funcione el camino nominal, sino cómo responde ante fallos: un cobro enviado dos veces por doble clic, una sesión que caduca a mitad de un formulario largo, dos operadores editando el mismo pedido o una integración ERP que agota el tiempo de espera.

De tres a seis meses hasta una primera versión en producción es lo normal para una aplicación de tamaño medio. El calendario se desvía por razones bastante predecibles, y según nuestra experiencia dos de ellas causan la mayor parte del daño. Ambas se neutralizan barato antes de firmar.

La primera es el análisis hecho por entrevista y no por observación. Las personas describen el proceso que creen seguir. El real tiene excepciones, y las excepciones son los requisitos. Mirar el trabajo durante un día las encuentra; un taller normalmente no.

La segunda es la integración con un sistema que no tiene dueño. La estimación da por hecho que existe una API y está documentada. En la semana seis se descubre que no, y una conversación con un proveedor pasa a estar en el camino crítico.

Una prueba técnica de una semana antes de cerrar el precio detecta casi todo esto.

Comprar software comercial gana a construir desde cero la mayor parte de las veces, y cualquier agencia que afirme lo contrario está intentando vender. El modelo SaaS gana en coste inicial, en rapidez de puesta en marcha y en mantenimiento delegado. Sin embargo, existen tres escenarios cuantificables donde el SaaS deja de compensar en cuanto se calcula el coste total de propiedad (TCO) a cinco años.

El flujo operativo es tu ventaja competitiva. Si tu forma de tarificar riesgos, asignar rutas logísticas o configurar presupuestos complejos es la razón por la que los clientes te eligen frente a la competencia, encajar ese proceso en una plantilla SaaS idéntica a la de tus rivales elimina tu diferenciación.

El impuesto por licencia y usuario supera al desarrollo. Con 200 usuarios entre plantilla interna y socios externos, una cuota de €45 por asiento al mes supone €108.000 anuales, o €540.000 en cinco años, sin contar sobrecostes por límites de llamadas API ni el salto obligatorio al plan Enterprise solo para activar el inicio de sesión único SAML. En cambio, una aplicación web a medida de €45.000 con €9.000 anuales de alojamiento y mantenimiento suma €90.000 en cinco años, permitiendo añadir usuarios, distribuidores o clientes sin penalización por asiento.

La residencia de datos y el control normativo no admiten cesiones. Las exigencias sectoriales o los acuerdos de tratamiento bajo el RGPD descartan a menudo plataformas multitenant alojadas fuera de la Unión Europea, mientras que una infraestructura cloud europea bajo control propio garantiza residencia geográfica exacta y trazabilidad completa.

También existe una arquitectura intermedia muy rentable que suele pasarse por alto: mantener el ERP o CRM comercial como base de registros y construir encima una aplicación web a medida ligera conectada por API que resuelva exactamente la lógica propia de tu negocio.

Los portafolios muestran pantallas acabadas, que es la parte de una aplicación que menos revela sobre su solidez de ingeniería. Cuatro preguntas prácticas separan a los equipos que han operado software en producción de aquellos que solo han entregado prototipos, y ninguna requiere a un desarrollador delante.

"Enséñame algo que sigáis manteniendo hoy." Construir es sencillo; convivir con una decisión técnica durante tres años es donde se demuestra el criterio.

"¿Qué salió mal en el último proyecto?" Un equipo sin respuesta o no ha entregado suficiente software o no está siendo transparente contigo.

"¿De quién son el código y las cuentas de infraestructura?" La respuesta debe ser tuya, por escrito, incluyendo acceso al repositorio desde el primer día.

"¿Qué pasa cuando dejemos de trabajar juntos?" Documentación, traspaso y credenciales. Según el Stack Overflow Developer Survey, la deuda técnica es la principal fuente de frustración entre desarrolladores, y gran parte proviene de sistemas heredados que nadie sabe explicar.

La seguridad nunca es un módulo opcional que se añade tras el lanzamiento, y tratarla como un añadido tardío es la vía más rápida para que un proyecto de €30.000 se convierta en un proyecto de €30.000 más un incidente regulatorio público. La línea base de producción no es negociable y un equipo de ingeniería solvente la incorpora de serie en la arquitectura.

El estándar OWASP Top 10 constituye la referencia real del sector para certificar el blindaje de aplicaciones: mitigación de control de acceso roto a nivel de objeto, prevención de inyecciones SQL y de comandos, gestión segura de sesiones y cabeceras Content Security Policy estrictas. Exige saber si el desarrollo ejecuta análisis automatizados SAST y DAST dentro de su pipeline CI/CD y pide los informes que lo acrediten.

Por encima de esa base, el esfuerzo de ingeniería escala según tres exigencias normativas concretas. Primero, la federación de identidad corporativa mediante OAuth 2.0, OpenID Connect (OIDC) o SAML 2.0 Single Sign-On (SSO) con aprovisionamiento automático SCIM garantiza que cualquier empleado que cause baja pierda el acceso en el acto. Segundo, la residencia de datos bajo el RGPD exige alojar bases de datos en regiones de la UE, cifrar campos personales en reposo con AES-256 y en tránsito mediante TLS 1.3, e implementar endpoints auditables de exportación y borrado. Tercero, cumplir con la norma de accesibilidad WCAG 2.2 AA y el Acta Europea de Accesibilidad requiere navegación completa por teclado, gestión del foco en modales dinámicos y tablas de datos, avisos semánticos ARIA en formularios y ratios de contraste mínimos de 4,5:1. Calcula entre un 10 % y un 20 % adicional sobre el presupuesto base cuando intervengan datos regulados, cobros tokenizados bajo normativa PCI o registros de auditoría inmutables.

Existe además un compromiso operativo ineludible: aplicar parches de seguridad de forma continua tras la puesta en producción. Deja asignado por contrato qué equipo gestiona las actualizaciones antes de firmar. Antes de comprometer el presupuesto completo de ingeniería, valida el alcance con nuestra guía sobre PoC vs prototipo vs MVP y la definición arquitectónica de portal web.