Software a la medida sin pagar precios ni tiempos de fábrica tradicional

El costo de un desarrollo de software a la medida varía según el alcance, el país y la moneda en que cotices, así que no hay un precio fijo para toda América Latina. Lo que sí es medible es el tiempo: la mediana de entrega de un proyecto es de 70 días.

Si llegaste hasta aquí buscando un número fijo, probablemente ya pediste dos o tres cotizaciones y cada una llegó con una cifra distinta, un plazo distinto y una explicación distinta de por qué. Esa dispersión no es señal de que alguien te esté cobrando de más. Es señal de que estás comparando proyectos que no son comparables entre sí, porque el alcance, el país de la agencia y hasta el tipo de contrato cambian el número final. El dato que sí puedes usar como referencia real es el de tiempo, con cifra y fuente: la mediana de 70 días para la entrega de un proyecto de desarrollo a la medida, medida sobre datos propios de Progresus en su pipeline de desarrollo.

¿Qué hace que un desarrollo a la medida termine costando más y tomando más tiempo del esperado?

La mayoría de los sobrecostos y retrasos no nacen del código. Nacen de la información que falta cuando el proyecto ya arrancó.

El 22.4 por ciento de los proyectos de desarrollo se detiene esperando insumos del cliente: un acceso, una decisión de negocio, un dato que solo tiene una persona dentro de la empresa que contrata. Cuando un proyecto se detiene por eso, la diferencia en tiempo es enorme. Los proyectos que se detienen esperando información del cliente tardan 182 por ciento más. Son 161 días contra 57.

Esto cambia la pregunta que deberías hacerte. No es solo cuánto cuesta un desarrollo a la medida. Es qué tan preparada está tu empresa para sostener el ritmo que el proyecto necesita. Un alcance bien definido y una persona interna disponible para responder dudas rápido pueden acortar el proyecto casi a la tercera parte del tiempo, sin cambiar una sola línea del contrato.

También influye el tamaño del corte. Digitalizar todo un proceso de punta a punta en un solo proyecto suele fallar por el tamaño mismo del alcance. Cuando el corte se acota a un tramo específico, el desarrollo a la medida se vuelve compatible con presupuestos más chicos, no solo con proyectos grandes de transformación completa.

¿Cuánto cuesta un desarrollo de software a la medida en América Latina?

No hay una tarifa regional fija que puedas anotar y usar como referencia. El costo depende del alcance del proyecto, el país donde está la agencia o el equipo, y la moneda en la que se cotiza. Cualquier cifra fija que veas en internet corresponde a un caso puntual, no a un estándar de la región.

Lo que sí puedes controlar, y lo que más impacta el número final, es el alcance. Tres variables mueven el precio en cualquier país de América Latina. La primera es cuántas pantallas o flujos distintos tiene el sistema. La segunda es cuántas integraciones necesita con herramientas que ya usas. La tercera es qué tan definidas están las reglas de negocio antes de empezar. Un alcance chico y bien definido cuesta una fracción de un sistema que intenta resolver toda la operación de una vez.

La variable que sí puedes comparar con un número concreto es el tiempo. La mediana de entrega de un proyecto de desarrollo a la medida es de 70 días. Ese dato no depende del país ni de la moneda. Depende de que el alcance esté claro y de que el cliente responda a tiempo cuando el equipo de desarrollo necesita información.

Si una cotización te llega con un plazo muy por debajo de esos 70 días para un alcance similar al tuyo, vale la pena preguntar qué se está dejando fuera. Si te llega muy por encima, vale la pena preguntar si el alcance realmente necesita ser tan grande.

¿Vale la pena seguir pagando licencia por usuario en vez de tener un sistema propio?

Pagar licencia por usuario tiene una ventaja real. No hay que construir nada, el software ya existe y empieza a funcionar el mismo día. El problema aparece con el tiempo, no al inicio.

Pagar licencia por usuario escala el gasto con cada persona nueva que se suma al equipo. Si tu empresa crece, contrata temporadas altas, o rota personal en un área operativa, el costo mensual sube en la misma proporción, sin techo. Un sistema propio no cobra por asiento adicional. Una vez está construido, agregar un usuario más no cambia el costo del sistema.

La otra diferencia es el ajuste a tu proceso real. Un ERP estándar exige que la operación se adapte a sus módulos, con los campos y flujos que el proveedor decidió que todas las empresas necesitan. Un desarrollo a la medida se diseña alrededor del proceso real del negocio, con sus reglas y sus excepciones propias, en lugar de forzar la operación a encajar en una plantilla genérica.

La pregunta que separa un caso de otro es el horizonte. Si el equipo es chico y estable, la licencia por usuario puede seguir siendo la opción más simple. Si el equipo crece, o si el proceso tiene reglas que ningún software estándar contempla, el punto de equilibrio suele llegar más rápido de lo que parece.

¿En qué cambia un desarrollo acelerado con IA frente al desarrollo tradicional?

El desarrollo tradicional divide el proyecto en fases largas y secuenciales: análisis, diseño, construcción, pruebas. Cada una espera a que termine la anterior. Un desarrollo acelerado con apoyo de inteligencia artificial comprime esas mismas fases, análisis, construcción y pruebas, en ciclos mucho más cortos, sin eliminar ninguna de ellas.

Esto no significa que el sistema resultante sea distinto en propiedad ni en calidad. La diferencia está en cuánto tarda en llegar a producción, no en quién es dueño del código ni en qué tan sólido queda el sistema. Un proyecto que con desarrollo tradicional tomaría varios meses puede caber, con el mismo alcance, dentro de la mediana de 70 días. Incluso puede caer por debajo si el alcance es acotado y la información fluye rápido.

Donde sí cambia el juego es en la posibilidad de iterar. Al comprimir los ciclos, es más fácil mostrar avances parciales, ajustar el rumbo con retroalimentación real del equipo que va a usar el sistema, y llegar a la versión final habiendo validado más decisiones en el camino, en vez de descubrir un desajuste hasta el final del proyecto.

¿Cómo se comparan un ERP, una licencia por usuario y un desarrollo a la medida?

Cada camino resuelve el mismo problema de forma distinta, y ninguno es superior en todos los casos. La tabla siguiente resume las cuatro variables que más pesan a la hora de decidir.

La fila que más suele sorprender es la de costo a mediano plazo. Un ERP o una licencia por usuario parecen más baratos el primer mes, pero un sistema propio deja de sumar costo por cada persona que se integra al equipo. Y en tiempo, la brecha entre un desarrollo tradicional y uno acelerado con IA no está en la calidad del resultado, sino en cuántas semanas toma llegar a él.

Qué preguntar a una agencia antes de firmar un desarrollo a la medida

Antes de firmar, hay cuatro preguntas que separan un proyecto bien planteado de uno que se va a estirar en tiempo y en presupuesto.

La primera es el alcance exacto de la primera entrega: qué pantallas, qué flujos y qué integraciones quedan incluidas, por escrito, no como una descripción general del problema que se quiere resolver.

La segunda es el plan de entregas parciales: si vas a ver avances cada dos semanas o solo vas a ver el resultado al final del proyecto. Un plan sin entregas intermedias dificulta corregir el rumbo a tiempo.

La tercera es quién es dueño del código una vez termina el proyecto. Esto debería estar explícito en el contrato, no asumido por ninguna de las dos partes.

La cuarta es qué pasa con el cronograma si el proyecto se detiene esperando información de tu lado. El 22.4 por ciento de los proyectos se detiene por esta razón, y el impacto en tiempo es de 182 por ciento. Vale la pena saber de antemano cómo se maneja esa pausa: si el plazo se corre automáticamente, si hay un costo asociado, o si el equipo reserva capacidad para retomar rápido.

¿Qué hacer con una aplicación que quedó a medias?

Terminar una aplicación que quedó a medias empieza por documentar qué existe hoy, no por reescribirla desde cero. Antes de decidir si se completa, se reemplaza o se abandona, alguien tiene que dejar por escrito qué partes funcionan, qué partes no, y qué reglas de negocio quedaron implementadas en el código, aunque nadie las haya escrito en ningún documento.

Ese paso de documentar no es un capricho de proceso. Cuando un proyecto de desarrollo se entrega a alguien externo sin esa información, y esa persona tiene que detenerse a preguntar qué hace cada parte, el proyecto se atrasa de forma medible: los proyectos de desarrollo que se detienen esperando información del cliente tardan 182 por ciento más, 161 días contra 57. Documentar antes de pedir ayuda externa no es solo prolijidad, es la diferencia entre un proyecto de dos meses y uno de cinco.

Reescribir sin ese paso repite los mismos errores con otro código, porque el problema no fue la herramienta usada la primera vez, fue la falta de un alcance claro desde el inicio. Acotar el alcance a la función crítica del negocio suele ser más rápido que intentar salvar toda la aplicación de una vez. Si la aplicación resuelve cinco cosas y solo una es crítica, esa es la que se revisa y se asegura primero.

Si el diagnóstico termina en que la función crítica necesita un desarrollo propiamente hecho, con revisión y pruebas, vale la pena saber el orden de magnitud del tiempo que toma: la mediana de entrega de un proyecto de desarrollo a la medida acotado es de 70 días. No es una cifra para toda reescritura completa de un sistema grande, es la referencia para un alcance bien definido, que es justamente lo que este diagnóstico busca dejar listo.

¿Por qué el equipo no usa la nueva herramienta interna?

Una herramienta interna que el equipo no adopta casi siempre falla por fricción de uso o por no resolver el problema real, no por falta de funcionalidades. Antes de agregar una función más, vale la pena confirmar cuál de las dos cosas está pasando.

La fricción de uso se nota rápido: la gente prefiere volver a la hoja de cálculo, al WhatsApp o al método anterior porque es más rápido para ellos, aunque sea menos ordenado para el negocio. Cuando el problema es que la herramienta no resuelve lo que el equipo necesita, en cambio, el síntoma es distinto: la usan al principio, por presión, y la abandonan en cuanto nadie está mirando. Distinguir cuál de las dos cosas está pasando cambia por completo qué se corrige primero.

La forma más simple de distinguirlo es preguntar, no adivinar. Sentarse con dos o tres personas que deberían usar la herramienta y pedirles que la usen frente a ti, en un caso real de su trabajo diario. Si dudan, retroceden o piden ayuda en pasos que deberían ser obvios, es fricción de uso. Si la usan sin problema pero después admiten que igual resuelven el caso por otro lado, la herramienta no está resolviendo el problema real, por bien construida que esté.

Checklist para retomar el control de tus apps hechas con IA

Esta tabla resume, por cada señal de riesgo, qué revisar y qué acción tomar primero.

Si después de leer esto prefieres que alguien externo haga esta revisión por ti, en vez de hacerla internamente sin certeza de qué buscar, la forma más directa es agendar una llamada con el equipo de desarrollo y llevarles el checklist ya recorrido.