Cuánto cuesta un software a medida: qué pesa en el precio

Cuánto cuesta un software a medida: la respuesta corta

El costo de un software a medida es, en el fondo, el costo del tiempo de un equipo. Personas que analizan, diseñan, programan, prueban y publican, durante un cierto número de semanas o meses. Todo lo demás (tecnología, hosting, herramientas) es secundario en la mayoría de los proyectos.

Por eso la pregunta útil no es cuál es el precio de un sistema, sino cuántas semanas de trabajo, y de qué tipo de equipo, exige tu problema. Un registro con tres pantallas y un informe es un problema pequeño. Un sistema con facturación, inventario, aplicación de campo e integración con el ERP de la empresa es algo muy distinto, aunque ambos se llamen sistema.

En la práctica, proyectos que parecen similares pueden tener precios muy distantes, y proyectos con precios parecidos pueden entregar cosas muy diferentes. Por eso el precio de un sistema a medida solo tiene sentido cuando viene acompañado de un alcance y de un plazo.

De qué depende realmente el precio de un sistema a medida

Estos son los factores que, según nuestra experiencia, más mueven el presupuesto, más o menos en orden de peso. El orden cambia según el proyecto, pero las reglas de negocio y las integraciones casi siempre aparecen en los primeros lugares.

Las pantallas son lo que el cliente ve, por eso reciben demasiada atención. Lo que cuesta de verdad suele estar debajo de ellas.

• Reglas de negocio: cálculo de comisiones, aprobación en varias etapas, excepciones por tipo de cliente. Cada regla debe ser entendida, implementada y probada, y las excepciones multiplican los casos de prueba.
• Número de perfiles de usuario: administrador, gerente, operador y cliente final ven y pueden hacer cosas distintas. Cada perfil añade pantallas, permisos y pruebas.
• Cantidad y complejidad de las pantallas: una pantalla de listado simple es barata; una pantalla con filtros combinados, edición en lote y gráficos no lo es.
• Integraciones: conectar con ERP, medios de pago, factura electrónica, correo electrónico, mensajería o sistemas de terceros. Cada integración depende de la calidad de la documentación del otro lado y de la estabilidad de su API.
• Migración de datos: traer la base del sistema anterior suele subestimarse. Datos sucios, duplicados y sin estándar dan trabajo.
• Plataformas: web, Android, iOS o todas. Una aplicación para tiendas de aplicaciones también implica publicación, revisión de las tiendas y actualizaciones.
• Requisitos no funcionales: seguridad, auditoría, rendimiento con muchos usuarios, funcionamiento sin conexión, cumplimiento de las normas de protección de datos.
• Equipo y senioridad: un equipo con más experiencia cobra más por hora, pero suele gastar menos horas y equivocarse menos en las decisiones de arquitectura.
• Plazo: querer todo rápido exige más gente en paralelo, y eso aumenta el costo de coordinación. Un plazo ajustado casi nunca sale gratis.
• Infraestructura y mantenimiento: dónde corre el sistema, quién lo monitorea, quién lo corrige, quién lo evoluciona. Hablamos de esto más adelante.

Modelos de contratación: precio cerrado, tiempo y materiales y squad dedicado

El modelo de contratación define quién asume el riesgo de que el proyecto cueste más de lo previsto. No existe el mejor modelo; existe el que se adapta al grado de incertidumbre de tu proyecto.

En el precio cerrado, la software house se compromete con un valor para un alcance definido. La ventaja es la previsibilidad: sabes cuánto vas a pagar. El punto débil es que cualquier cambio se convierte en una solicitud de modificación, con negociación y costo extra. Y, como el proveedor asume el riesgo, incluye un margen de seguridad en el precio. Funciona bien cuando el alcance es claro y estable, como un módulo bien especificado o la reconstrucción de algo que ya existe y que todos conocen.

En tiempo y materiales, pagas por las horas o semanas efectivamente trabajadas, con un valor acordado por profesional. La ventaja es la flexibilidad: el alcance puede cambiar en cada ciclo y pagas solo por lo que se hizo. El punto débil es que el presupuesto final es una estimación y, sin un seguimiento cercano, puede crecer. Funciona bien cuando hay incertidumbre real, como un producto nuevo cuyo camino se descubrirá durante el desarrollo. Exige un cliente presente, que priorice y sepa decir que no.

En el squad dedicado, un equipo queda asignado a tu producto durante un período largo, con un costo mensual previsible. La ventaja es el conocimiento acumulado y la velocidad constante. El punto débil es que pagas el equipo completo incluso en los meses en que la cola de demandas es menor. Funciona bien para productos en evolución continua, no para proyectos con inicio, desarrollo y final bien definidos.

Un esquema que vemos funcionar con frecuencia es el híbrido: precio cerrado para una primera versión bien delimitada, y después tiempo y materiales o mensualidad para evolucionar y mantener. Ganas previsibilidad al comienzo, cuando la confianza entre las partes aún se está construyendo, y flexibilidad después, cuando el uso real muestra qué importa.

Cómo escribir el alcance y el plazo del software sin terminar en un contrato de 200 páginas

Casi todo desvío de costos empieza en un alcance vago. El alcance y el plazo del software van juntos: sin el primero, el segundo es una conjetura. Y el alcance no es una lista de deseos; es una descripción de lo que se entregará, en qué condiciones, y de lo que queda fuera.

No necesitas un documento técnico. Necesitas claridad sobre el problema y sobre lo que significa estar terminado.

• Empieza por el problema, no por la solución: quién sufre hoy, con qué proceso, y qué cambia cuando el sistema exista.
• Enumera los perfiles de usuario y lo que cada uno necesita hacer, en frases simples como el operador registra una entrada de material y el gerente aprueba.
• Describe los flujos principales de principio a fin, incluidas las excepciones que ocurren todas las semanas. Las excepciones raras pueden esperar.
• Separa lo que es indispensable en la primera versión de lo que es deseable. Esa separación es la herramienta de control de costos más eficiente que existe.
• Enumera las integraciones por nombre y pide acceso a su documentación antes de cerrar el plazo.
• Di qué queda fuera del alcance. Escribir que los informes avanzados y la aplicación para iOS quedan para una segunda fase evita muchas discusiones después.
• Define el criterio de aceptación: cómo van a concluir juntos que cada entrega está lista.
• Registra las premisas: por ejemplo, que el cliente responde las dudas en un máximo de dos días hábiles y entrega los datos para la migración hasta cierta fecha.

Cómo pedir y comparar presupuestos de desarrollo de software

El error más común que se ve es pedir tres presupuestos con tres descripciones distintas, de forma verbal, y después comparar los números. El resultado es comparar cosas que no son comparables. Un presupuesto de desarrollo de software solo ayuda si todos los proveedores parten del mismo material.

Entrega el mismo documento de alcance a todos, aunque sea de una página, y responde las mismas dudas a todos. Después, mira más allá del valor total.

Al leer las propuestas, pregunta y compara estos puntos:

• Qué está dentro y qué está fuera, ítem por ítem. Una propuesta barata muchas veces deja fuera pruebas, publicación en las tiendas, migración de datos o capacitación.
• Cómo se compuso el valor: número de personas, perfiles, semanas. Una propuesta sin ese detalle esconde premisas.
• Cómo se tratarán los cambios de alcance y cuánto cuesta una hora o semana adicional.
• Quién es dueño del código y de la documentación al final, y si puedes llevar el proyecto a otro equipo.
• Cómo funcionan las entregas: cada cuánto tiempo ves algo funcionando, y no solo informes de avance.
• Qué ocurre después de la entrega: garantía, corrección de errores, soporte y evolución.
• Quién va a trabajar realmente en el proyecto, y no solo quién aparece en la reunión comercial.

Qué hace que se desvíen el plazo y el costo en los proyectos de software

El desvío casi nunca viene de programadores lentos. Viene de decisiones que quedaron para después. Los motivos más frecuentes son siempre los mismos, y todos pueden reducirse con una conversación franca al comienzo.

El primero es el alcance que crece sin registrarse. Cada pequeño solo una cosa más parece inofensivo, y la suma de veinte de ellos cambia el proyecto. La salida es tener una forma simple de registrar cada pedido nuevo y decir qué desplaza o cuánto cuesta.

El segundo es la demora del lado del cliente. Aprobaciones detenidas, dudas sin respuesta y datos que no llegan traban al equipo, y el reloj sigue corriendo. Si el equipo se queda parado esperando, alguien paga por eso.

El tercero es la integración que resulta peor de lo que parecía. Documentación desactualizada, entorno de pruebas inexistente, API que se cae. Por eso recomendamos validar las integraciones críticas en las primeras semanas, y no al final.

El cuarto es la regla de negocio que nadie sabía que existía. En empresas con años de operación, buena parte del proceso está en la cabeza de las personas y en hojas de cálculo. Aparece durante las pruebas, cuando el usuario dice que ahí no es exactamente así. Conversar con quien opera el proceso día a día, y no solo con quien lo gestiona, evita buena parte de esas sorpresas.

El quinto es decidirlo todo de una vez y ver el resultado solo al final. Cuanto más tiempo pasa sin ver el software funcionando, mayor es el riesgo de construir la cosa equivocada a la perfección. Las entregas cortas y frecuentes, con el usuario real probando, son el mejor antídoto.

Costos que casi nadie cuenta: mantenimiento, hosting y evolución

El presupuesto inicial es solo una parte del costo total. El software no es una obra que se entrega y se olvida; necesita mantenimiento, porque los sistemas operativos cambian, las bibliotecas se desactualizan, las tiendas de aplicaciones modifican sus reglas y los usuarios descubren cosas que quieren distintas. Ese costo es recurrente: acompaña al sistema mientras esté en uso y debe entrar en el presupuesto desde el inicio, no después.

Al planificar el presupuesto, considera al menos estos ítems:

• Hosting e infraestructura: servidores o nube, base de datos, almacenamiento, copias de seguridad, certificados y monitoreo. El costo crece con el uso.
• Mantenimiento correctivo: errores que aparecen con el uso real y necesitan arreglo.
• Mantenimiento preventivo: actualización de dependencias, correcciones de seguridad, compatibilidad con nuevas versiones de Android e iOS.
• Servicios de terceros: envío de correo electrónico y SMS, mapas, medios de pago, notificaciones. Muchos cobran por volumen.
• Cuentas de desarrollador en las tiendas de aplicaciones, cuando hay aplicación.
• Evolución: nuevas funcionalidades solicitadas después de que el sistema entra en uso. Es la señal de que el software está siendo útil, y debe tener presupuesto propio.
• Soporte y capacitación de nuevos usuarios.

Cómo reducir el riesgo empezando pequeño

La forma más segura de gastar bien en software es no comprarlo todo de una vez. Empieza por la versión más pequeña que ya resuelva un dolor real, ponla en manos de los usuarios y deja que el uso decida lo que viene después. Eso es más barato de lo que parece, porque la mayor parte del desperdicio en software viene de funcionalidades construidas y nunca usadas.

Antes del código, vale la pena ver el producto. Un prototipo navegable muestra pantallas y flujos en pocos días, y es ahí donde el cliente descubre que faltaba un perfil de usuario o que un flujo no funciona como imaginaba. Corregir eso en un prototipo cuesta casi nada; corregirlo después de programado cuesta semanas. Por eso, en SKAD puedes ver tu aplicación en el prototipo gratis con presupuesto aproximado antes de decidir contratar cualquier cosa.

Si ya tienes un sistema antiguo, el camino más barato muchas veces no es reescribirlo todo. Es reemplazarlo por partes, manteniendo la operación en marcha, con cada módulo nuevo entrando en lugar de uno viejo. Es lo que hacemos en la modernización de sistemas legados, de forma incremental y acelerada con IA, sin detener la empresa. El riesgo queda distribuido en etapas pequeñas, y puedes parar o cambiar de dirección en cada una.

Por último, elegir bien quién va a construir pesa tanto como el modelo. Reunimos las preguntas que importan en cómo elegir una software house, y vale la pena leerlas antes de firmar. Y, para planificar lo que viene después de la entrega, mira qué suele incluirse en contratos de mantenimiento de software.

Preguntas frecuentes

Conclusión

Antes de pedir cualquier presupuesto, escribe en una página el problema, los perfiles de usuario y las tres cosas que el sistema necesita hacer en la primera versión. Con eso en la mano, podrás comparar propuestas de forma justa y sabrás qué recortar si el valor supera lo que puedes invertir. El siguiente paso más económico es ver la aplicación antes de contratarla: pide el prototipo gratis de SKAD y recibe, junto con él, un presupuesto aproximado para decidir con algo concreto en la mano.