Cómo dimensionar el costo de software a medida antes de cotizarlo
Un método para estimar el costo de software a medida desde lo que realmente mueve el número, para cuestionar una propuesta en vez de comparar totales.
La mayoría de los artículos sobre esto abre con un rango: "espera entre 50.000 y 500.000 dólares". Ese rango es técnicamente cierto y completamente inútil, porque abarca desde una herramienta interna pequeña hasta una plataforma que hace funcionar a una empresa.
El costo lo mueven seis factores, y solo dos son de funcionalidades
El instinto es estimar desde la lista de funcionalidades. La cantidad importa, pero rara vez es el término dominante. Estos seis factores, aproximadamente en orden de cuánto mueven un total:
1. Superficie de integración. ¿Con cuántos sistemas tiene que hablar esto, y cuántos tienen una API real? Cada integración carga investigación, manejo de errores, gestión de credenciales y una obligación continua de mantenimiento. Una integración con un sistema heredado sin documentación puede costar más que la funcionalidad que habilita. Es la razón más común de estimaciones equivocadas.
2. Migración de datos. Mover el histórico casi siempre se subestima, porque el costo no está en la transferencia. Está en reconciliar veinte años de datos inconsistentes que el sistema viejo toleraba y el nuevo no va a tolerar. Si nadie sabe decirte qué porcentaje de los registros existentes está limpio, eso es una tarea de discovery antes que una estimación.
3. Requisitos regulatorios y de auditoría. HIPAA, SOC 2 y regímenes similares no son una casilla al final. Cambian la arquitectura, el registro, el modelo de acceso y el pipeline de despliegue. Añadirlos a mitad de proyecto cuesta múltiplos de haberlos diseñado desde el inicio. Si manejas información de salud protegida, lee qué obliga realmente un BAA antes de definir el alcance.
4. Cantidad de roles de usuario distintos. Cada rol con permisos y flujos genuinamente diferentes es casi una superficie de aplicación aparte. Cinco roles no es cinco veces uno, pero es bastante más que uno.
5. Exigencia de disponibilidad y exactitud. Un sistema que puede caerse una hora un domingo es un problema de ingeniería distinto de uno que no puede. Y uno donde un número equivocado es embarazoso es distinto de uno donde es una reexpresión financiera.
6. Cantidad de funcionalidades y complejidad de interfaz. Aquí es donde empieza la mayoría de las conversaciones, y donde vive la menor varianza.
Una prueba que puedes correr tú mismo
Evalúa tu proyecto en cada factor. El objetivo no es la puntuación, es descubrir dónde no puedes responder.
| Factor | Pregunta a responder | Señal de que costará más |
|---|---|---|
| Integraciones | ¿Cuántos sistemas, y cuántos tienen API documentada? | Cualquier sistema donde la respuesta sea "habría que preguntarle al proveedor" |
| Migración de datos | ¿Cuántos registros, y qué proporción está limpia? | Nadie ha perfilado los datos existentes |
| Cumplimiento | ¿Qué régimen aplica, y hay un acuerdo firmado? | El cumplimiento se describe como "eso lo vemos después" |
| Roles | ¿Cuántos roles tienen permisos genuinamente distintos? | Más de tres, o roles que actúan en nombre de otros |
| Disponibilidad | ¿Cuánto cuesta una hora de caída? | La respuesta es "no puede caerse" sin presupuesto asociado |
| Alcance | ¿Cuál es la versión más pequeña que sigue siendo útil? | Nadie sabe describir una |
Esa última fila es la pregunta de mayor apalancamiento de todo el ejercicio, y está directamente ligada a si deberías estar construyendo. Un equipo que no puede describir una versión más pequeña útil va a construir la grande, y la grande es donde mueren los presupuestos.
Qué hace confiable a una propuesta
No vas a poder verificar el número. Sí puedes verificar el razonamiento detrás.
- Declara los supuestos explícitamente. "Asume que el ERP expone una API REST de pedidos" es una propuesta que puedes corregir. Un total sin supuestos es un total que no puedes discutir.
- Separa discovery de construcción. Quien cotiza precio cerrado por un sistema que no ha examinado, o está inflando bastante o planea renegociar. Ambas cosas te cuestan.
- Nombra lo que queda fuera. Limpieza de datos, capacitación, licencias de terceros y soporte post-lanzamiento son las cuatro sorpresas más comunes.
- Las fases tienen puntos de decisión, no solo entregables. Deberías poder parar después del discovery con algo útil en la mano. Qué es ese algo está en qué debe entregar un discovery de dos semanas.
El costo después del lanzamiento
La construcción es la mitad menor del costo total de propiedad. Un sistema en funcionamiento necesita actualizaciones de dependencias, parches de seguridad, reparaciones de integración cuando un proveedor cambia su API, y cambios conforme cambia el negocio.
No presupuestar nada para eso el primer año es la forma más fiable de terminar con un sistema sin mantenimiento el segundo, momento en el que estás pagando una modernización. Si una propuesta no aborda qué pasa después del lanzamiento, pregunta.
Dónde se hace el trabajo también cambia la aritmética de formas que la tarifa por hora esconde. Es el tema de nearshore, offshore o EE. UU., y saber si un proveedor puede construirlo es evaluar profundidad de ingeniería.
Publicamos cómo trabajamos y qué protegemos en nuestras prácticas de seguridad, y cómo definimos el alcance está en desarrollo a medida.