Qué elementos influyen en el costo de un desarrollo

Pedir cotizaciones para un desarrollo de software y recibir cifras muy distintas por lo que parece ser el mismo proyecto es una experiencia tan común que muchos empresarios la interpretan como una señal de que el mercado es opaco o arbitrario. Pero la dispersión de precios rara vez es aleatoria: responde a variables concretas que afectan el costo de manera predecible, aunque no siempre visibles en una primera conversación.

Este artículo no da cifras —porque cualquier cifra dependería del proyecto, del equipo y del contexto—, sino que explica las variables que determinan por qué un desarrollo cuesta lo que cuesta. Entender estas variables permite dos cosas: comparar cotizaciones con criterio en lugar de solo por precio, y anticipar rubros que una cotización inicial podría estar omitiendo.

La variable que más impacto tiene: el nivel de definición del alcance

La diferencia de costo entre desarrollar con un alcance detallado y desarrollar mientras se define el alcance no es un porcentaje menor: puede multiplicar el presupuesto. Y no se trata solo de tiempo adicional de desarrollo: es retrabajo, funcionalidades que se construyen, se prueban y se descartan porque no eran lo que el negocio necesitaba, y decisiones que se toman y se revierten cuando aparecen nuevas restricciones que no se habían contemplado.

Un alcance bien definido incluye:

• Historias de usuario con criterios de aceptación claros: qué debe hacer cada funcionalidad y cómo se verifica que lo hace.
• Flujos completos de los procesos principales, incluyendo qué pasa en los casos de error o excepción.
• Reglas de negocio documentadas: qué validaciones aplican, qué permisos necesita cada rol, qué condiciones disparan qué acciones.
• Priorización explícita: qué funcionalidades son imprescindibles para la primera versión y cuáles pueden esperar.

Cuando el alcance se define en términos generales —"un sistema para gestionar clientes", "una app como la de X pero con algunos cambios"—, el proveedor tiene que estimar sobre supuestos. Y esos supuestos, cuando se confrontan con la realidad del negocio, rara vez se sostienen. El resultado es un proyecto donde el alcance real se descubre durante el desarrollo, y cada descubrimiento tiene un costo.

La cantidad y complejidad de las integraciones

Integrar un sistema nuevo con herramientas que la empresa ya usa —un ERP, un CRM, una pasarela de pagos, un sistema de facturación electrónica, una API bancaria— es, en muchos proyectos, más costoso que desarrollar la funcionalidad principal del sistema.

Cada integración introduce variables que el equipo de desarrollo no controla:

• APIs que cambian sin aviso o cuya documentación está desactualizada.
• Límites de uso —cantidad de consultas por minuto, volumen de datos por solicitud— que obligan a diseñar mecanismos de control adicionales.
• Sistemas heredados que no fueron diseñados para integrarse con herramientas modernas y requieren adaptaciones costosas.
• Formatos de datos incompatibles que obligan a transformar la información en cada intercambio.

Una integración con un sistema que el proveedor ya conoce y con el que ya trabajó antes cuesta una fracción de lo que cuesta una integración con un sistema desconocido. La diferencia está en el tiempo que el equipo dedica a entender cómo funciona el sistema ajeno, no en el tiempo de construir la conexión.

Conviene preguntar, para cada integración prevista: ¿el proveedor ya trabajó con ese sistema específico? Si la respuesta es "no, pero lo investigamos", esa integración va a costar más de lo estimado, y conviene que ese riesgo esté explicitado en la cotización en lugar de descubrirlo durante el proyecto.

El estado de los datos que necesitan migrarse

Si el proyecto incluye migrar información desde planillas, bases de datos o sistemas anteriores, la calidad de esos datos determina buena parte del esfuerzo total. Datos inconsistentes —el mismo cliente registrado con tres nombres distintos—, duplicados, incompletos o con formatos que varían según quién los cargó requieren un trabajo de limpieza y normalización que puede insumir tanto tiempo como el desarrollo en sí.

Este trabajo, además, rara vez puede hacerlo solo el equipo de desarrollo. Requiere que alguien del negocio defina:

• Qué registros son válidos y cuáles se descartan.
• Cómo se resuelven las inconsistencias: ante dos versiones del mismo dato, ¿cuál prevalece?
• Qué criterio se usa para decidir si un dato es obligatorio u opcional en el nuevo sistema.

Si esa persona del negocio no está identificada y disponible durante la migración, el proyecto se frena o avanza con datos incorrectos. Corregir una migración mal hecha después de que el sistema nuevo ya está en uso es significativamente más costoso que planificarla bien desde el inicio.

La complejidad del dominio y las reglas de negocio

No todos los desarrollos tienen la misma complejidad intrínseca. Una aplicación que gestiona turnos tiene menos reglas y menos casos de borde que una que liquida sueldos con convenios colectivos, calcula impuestos según múltiples jurisdicciones o gestiona la cadena de suministro de una operación logística.

Las variables que aumentan la complejidad del dominio incluyen:

• Múltiples roles de usuario con permisos diferenciados y jerarquías complejas.
• Reglas de negocio que dependen de combinaciones de condiciones —"si el cliente es de categoría A, está en la región B y el pedido supera el monto C, entonces aplica el descuento D, salvo que sea fin de mes y el pedido incluya productos de la línea E".
• Requisitos normativos o regulatorios que varían según la industria, la ubicación geográfica o el tipo de operación.
• Lógica transaccional compleja: operaciones que deben ejecutarse de manera atómica —todas o ninguna— y que requieren mecanismos de compensación si algo falla a mitad del proceso.

Cuanto más específico y regulado sea el dominio, más tiempo demanda entenderlo antes de empezar a construir. Y ese tiempo de comprensión no es opcional: si el equipo de desarrollo no entiende las reglas del negocio, lo que construye va a funcionar técnicamente pero va a producir resultados incorrectos desde la perspectiva del negocio.

La composición y experiencia del equipo

Dos equipos pueden cotizar el mismo proyecto con metodologías similares y llegar a cifras distintas porque la composición del equipo —y la experiencia de quienes lo integran— afecta tanto la velocidad de desarrollo como la calidad del resultado.

Un equipo con experiencia específica en el dominio del proyecto —logística, finanzas, salud, educación— comete menos errores de interpretación, anticipa casos de borde que alguien sin experiencia en el dominio no vería venir y necesita menos iteraciones de corrección. Eso se traduce en menos horas totales, aunque la tarifa por hora pueda ser más alta.

Un equipo con desarrolladores senior resuelve problemas de arquitectura y diseño en horas que un equipo con perfiles más junior podría tardar días en resolver, con el riesgo adicional de tomar decisiones técnicas que después son caras de deshacer. La tarifa por hora más alta puede resultar en un costo total menor si la experiencia del equipo reduce la cantidad total de horas necesarias.

La variable relevante no es la tarifa horaria sino el costo total estimado, y ese depende tanto de cuánto cobra el equipo por hora como de cuántas horas necesita para llegar al resultado.

El nivel de madurez del producto

No es lo mismo desarrollar la primera versión de un producto que agregar funcionalidades a un sistema que ya está en producción y tiene usuarios activos. El estado actual del producto —si es que ya existe algo— afecta el costo de varias maneras:

• Si hay un sistema anterior funcionando, el desarrollo nuevo debe convivir con él durante un período de transición. Mantener dos sistemas en paralelo —el viejo y el nuevo— duplica temporalmente los costos de operación y requiere mecanismos de sincronización que no serían necesarios si se partiera de cero.
• Si el producto ya tiene usuarios, cada cambio introduce el riesgo de romper algo que hoy funciona. Eso obliga a invertir más tiempo en testing y en mecanismos de despliegue que minimicen el impacto de los errores.
• Si el código existente tiene deuda técnica acumulada, cualquier modificación sobre esa base es más lenta y más riesgosa que si se partiera de una base sólida.

Un desarrollo sobre un sistema existente con deuda técnica puede costar más que desarrollar la misma funcionalidad desde cero, simplemente porque cada cambio requiere entender un código que no fue diseñado para ser modificado en esa dirección.

El entorno regulatorio y los requisitos de compliance

Ciertas industrias —finanzas, salud, seguros, gobierno— imponen requisitos que afectan el costo del desarrollo de manera significativa, aunque no se traduzcan en funcionalidades visibles para el usuario final:

• Auditoría y trazabilidad: cada acción sobre datos sensibles debe quedar registrada con detalle de quién la hizo, cuándo y desde dónde.
• Cifrado y protección de datos: requisitos específicos sobre cómo se almacenan, transmiten y respaldan los datos personales o financieros.
• Certificaciones y homologaciones: en algunos sectores, el software debe pasar por procesos formales de validación antes de poder operar, lo cual agrega tiempo y costo que no están relacionados con el desarrollo en sí.
• Accesibilidad: en ciertos contextos regulatorios, las aplicaciones deben cumplir estándares de accesibilidad que requieren trabajo adicional de diseño y desarrollo.

Estos requisitos no son opcionales, pero con frecuencia no aparecen en una primera cotización porque el proveedor asume —equivocadamente— que el cliente los conoce y los tiene contemplados. Preguntar explícitamente si la cotización incluye los costos asociados a los requisitos regulatorios de la industria evita sorpresas cuando el proyecto ya está avanzado.

Cómo usar estas variables para evaluar una cotización

Con estas variables en mente, evaluar una cotización no es solo mirar el número final sino preguntar:

1. ¿Qué nivel de definición del alcance asume esta cotización? ¿Está contemplado el trabajo de relevamiento y documentación o se asume que ya está hecho?
2. ¿Cuántas integraciones incluye y el proveedor ya tiene experiencia con esos sistemas específicos?
3. ¿Incluye la migración de datos? ¿En qué estado se asume que están esos datos?
4. ¿Qué perfil de equipo está asignado al proyecto y cuánta experiencia tiene en este dominio?
5. ¿La cotización contempla los requisitos regulatorios específicos de la industria?

Dos cotizaciones por el mismo proyecto pueden diferir enormemente porque asumen respuestas distintas a estas cinco preguntas. La que tiene el número más bajo no necesariamente es la más conveniente: puede estar omitiendo rubros que la otra incluye, o asumiendo condiciones ideales —datos limpios, integraciones simples, alcance cristalino— que rara vez se dan en un proyecto real.

Entender qué variables influyen en el costo no elimina la incertidumbre, pero permite hacer las preguntas correctas antes de firmar. Y esas preguntas son, con frecuencia, más valiosas que la cifra que aparece al final de la cotización.

Si querés profundizar en cómo se arma una estimación de costos más realista, el artículo sobre cómo estimar el costo real de un proyecto de software ofrece un marco paso a paso. Y si lo que te llama la atención es por qué dos cotizaciones por el mismo proyecto pueden ser tan distintas, revisá por qué dos presupuestos de software llegan a precios tan diferentes.

Más sobre planificación y presupuesto en la categoría de costos y presupuestos.