Cuánto cuesta un software a medida: rangos reales y qué los mueve

Un sitio institucional bien hecho arranca cerca de los USD 3.000. Una plataforma con integraciones, roles y migración de datos supera sin esfuerzo los USD 100.000. La mayoría de los proyectos que cotizamos cae entre USD 8.000 y USD 40.000, y un MVP funcional suele tomar entre 4 y 10 semanas.

Esos números sirven para empezar a pensar un presupuesto, que es más de lo que casi cualquier proveedor pone por escrito antes de una reunión. Pero el número no es lo importante. Lo importante es qué mueve un proyecto dentro de ese rango, y qué lo hace saltar fuera a mitad de camino. Eso es lo que decide si el presupuesto que firmas es el que vas a terminar pagando.

Por qué "depende" es una respuesta honesta y aun así inútilEnlace a esta sección#

Un presupuesto de software es una estimación de trabajo, y el trabajo depende de cinco cosas que rara vez están sobre la mesa en la primera conversación:

• El alcance real, medido en flujos y no en funcionalidades. "Un panel de administración" puede ser una tabla con filtros o un sistema de permisos por rol con auditoría de cambios y exportaciones. La distancia entre esas dos frases es un mes de trabajo.
• Las integraciones con sistemas ajenos. Conectarse con un ERP viejo, con una API sin documentación o con un servicio que solo entrega archivos por FTP cuesta más que construir la funcionalidad propia. No por dificultad técnica, sino por la cantidad de sorpresas que aparecen recién cuando uno lo toca de verdad.
• La migración de datos. Los datos que existen nunca están como se describen: duplicados, campos usados para dos cosas distintas, fechas en tres formatos, un Excel paralelo que resulta ser la fuente de verdad. Migrar mal es la razón más común por la que un sistema nuevo se abandona a los tres meses.
• El cumplimiento y la seguridad. Facturación electrónica, datos de salud, pagos con tarjeta, GDPR. Cada requisito de este tipo agrega trabajo que el usuario no ve pero que no es opcional.
• El diseño. Diseñar desde cero (investigación, sistema de componentes, varias iteraciones con revisiones tuyas) puede ser un 20% a 30% del proyecto. Partir de un sistema de diseño existente lo reduce a una fracción.

¿Cuánto sale cada tipo de proyecto?Enlace a esta sección#

Estos son los rangos con los que trabajamos, ordenados por forma de proyecto en vez de por industria. Son orientativos: sirven para saber si el orden de magnitud que tienes en la cabeza es el correcto.

Un proyecto se va al piso del rango cuando el alcance está escrito, hay una sola persona que decide, no hay que migrar nada y las integraciones tienen documentación y ambiente de prueba. Se va al techo cuando pasa lo contrario, y sobre todo cuando el diseño se define recién al verlo funcionando.

¿Por hora, precio cerrado o presupuesto por fase?Enlace a esta sección#

Las tres formas existen y ninguna es una estafa, pero reparten el riesgo de manera muy distinta.

Por hora. El proveedor no asume ninguno: si algo tarda el triple, ese tiempo lo pagas igual. Funciona cuando el trabajo es genuinamente exploratorio o cuando ya hay confianza de proyectos anteriores. Con un proveedor nuevo es un cheque en blanco que además premia la lentitud.

Un único precio cerrado por todo el proyecto. Suena a la máxima protección y es lo contrario. Para cerrar un número sobre algo que todavía no está definido, el proveedor mete un colchón por incertidumbre, y ese colchón lo pagas aunque no haga falta. Peor: desde la firma, cada conversación se vuelve una negociación de alcance. "Eso no estaba en el contrato" mata más proyectos que cualquier problema técnico.

Presupuesto cerrado por fase. Es como cotizamos: fases de dos a cuatro semanas, cada una con un precio fijo y un entregable que funciona y se puede usar. La ventaja no es nuestra, es tuya:

• Solo estás comprometido con la fase actual. Si algo no te convence, te vas al final de ella con software funcionando y con el código fuente, que es tuyo desde el principio.
• La incertidumbre se cotiza cuando ya no es incertidumbre. La fase tres se presupuesta sabiendo lo que se aprendió en la uno y la dos, así que no hay colchón por miedo.
• Cambiar de idea deja de ser un conflicto. Lo que aprendiste viendo la fase anterior funcionando entra en la planificación de la siguiente, que es exactamente para lo que sirve entregar seguido.

¿Qué hace que un presupuesto se dispare a mitad de camino?Enlace a esta sección#

Casi siempre lo mismo, en este orden:

1. El alcance se escribió como lista de funcionalidades. "Reportes" no es un entregable. "Un reporte de ventas por mes y por vendedor, exportable a Excel, para tres roles" sí lo es.
2. Una integración sin ambiente de prueba. Si el sistema con el que hay que conectarse no tiene sandbox, la integración se prueba en producción, y eso se paga en tiempo.
3. Los datos reales aparecen tarde. Cuando la migración se ve en la semana ocho de un proyecto de diez, el problema ya no es técnico, es de calendario.
4. Las decisiones no tienen dueño. Un proyecto que aprueba un comité se detiene entre reunión y reunión, y el tiempo detenido también se paga.
5. El "ya que estamos". El cambio chico que parece trivial y que en realidad reabre una decisión de arquitectura tomada tres semanas antes.

Cómo protegerte, en concreto: pide el alcance escrito como entregables verificables, no como features. Da acceso a los datos y a las integraciones antes de cerrar el precio, no después. Nombra a una sola persona que decide. Y asegúrate de que el contrato diga qué pasa cuando hay un cambio (cómo se cotiza, cuándo entra), en vez de intentar prohibirlo: los cambios van a existir igual, y un contrato que los niega solo garantiza una pelea.

¿Por qué la cotización más barata suele terminar siendo la más cara?Enlace a esta sección#

Si tres proveedores serios cotizan un mismo pliego en USD 22.000, USD 19.000 y USD 6.000, el tercero no encontró una manera más eficiente de hacerlo. Entendió otra cosa. En general entendió menos: sin migración, sin permisos, sin los casos raros, sin las pruebas, sin los estados de error, sin nada de lo que aparece cuando el sistema se usa de verdad.

La cuenta completa de un proyecto barato mal hecho no es el precio que pagaste: es ese precio, más los meses que el equipo perdió usándolo, más rehacerlo. Y rehacer siempre sale más caro que construir, porque además hay que migrar los datos que se generaron mientras tanto.

¿Por qué un equipo argentino puede cobrar menos por la misma ingeniería?Enlace a esta sección#

Acá es donde conviene ser explícitos, porque es la parte que un cliente de Estados Unidos o Europa tiene todo el derecho a mirar con desconfianza.

La diferencia de precio es geografía y macroeconomía, no seniority. Un sueldo de ingeniería competitivo en Argentina, que le permite a alguien bueno quedarse en el equipo, sigue siendo una fracción del sueldo equivalente en San Francisco, Londres o Berlín. A eso se suma que nuestra estructura es chica: no hay capas de gestión, ni oficinas comerciales, ni un vendedor entre el cliente y quien escribe el código. Ese diferencial es real y es sostenible.

Lo que no explica la diferencia: gente más junior, procesos más flojos o menos pruebas. Si un proveedor es barato por eso, el precio no es una ventaja, es una advertencia — y aplica igual en Argentina, en India o en Ohio.

Como eso no se puede demostrar con un adjetivo, se verifica preguntando. Cuatro cosas que puedes pedir en la primera llamada, a nosotros o a cualquiera:

• Hablar con la persona que va a escribir el código, no solo con quien vende.
• Ver código real: un repositorio, un fragmento, algo que hayan construido.
• Que expliquen una decisión técnica del proyecto y por qué descartaron la alternativa. Quien no puede nombrar la alternativa, no la evaluó.
• Que digan qué no harían en tu caso. Un proveedor que dice que sí a todo te está cotizando lo que quieres escuchar.

Lo que sí cambia con la distancia, y es justo saberlo de antemano: la zona horaria (Argentina está en UTC−3 todo el año, sin horario de verano: se superpone con toda la jornada de la costa este de Estados Unidos, con media jornada de la costa oeste y con la tarde europea, pero no con Asia), y que no vamos a estar físicamente en tu oficina. Si tu proyecto necesita a alguien presente todos los días, ningún equipo remoto es la respuesta correcta, cobre lo que cobre.

Qué pedir en cualquier presupuestoEnlace a esta sección#

Independientemente de a quién contrates:

1. El alcance como lista de entregables, con una definición de "terminado" para cada uno.
2. El precio partido por fases, con lo que se entrega al final de cada una.
3. Qué queda afuera, escrito de forma explícita.
4. Qué pasa con el código, las cuentas y la infraestructura si la relación termina. La respuesta correcta es que ya son tuyos.
5. Qué cuesta el mantenimiento después del lanzamiento. Un sistema vivo tiene un costo mensual; un presupuesto que no lo menciona lo está escondiendo, no lo está evitando.

Si el presupuesto que te llega no contesta esas cinco cosas, el problema no es el número: es que todavía no hay suficiente información como para que ese número signifique algo.

Así trabajamos las fases nosotros, y está detallado en nuestro proceso. Si quieres un rango para un caso concreto, cuéntanos qué necesitas resolver: respondemos con un rango y con las preguntas que faltan para afinarlo, no con una invitación a una reunión de descubrimiento.