TL;DR: Un presupuesto de software excesivamente barato no es una oportunidad: es una señal de alerta. Las causas más comunes: alcance incompleto, equipo sin experiencia, plantillas mal adaptadas o promesas que no se pueden cumplir. Esta guía explica cómo identificarlo antes de firmar.
Señales de que un presupuesto de software es demasiado barato
En el mercado de software, recibir un presupuesto muy por debajo de los demás es raro que sea suerte. Casi siempre tiene una explicación que vale la pena entender antes de firmarlo.
Esto no significa que el más caro sea siempre el mejor. Pero hay un piso de costo por debajo del cual el trabajo simplemente no puede hacerse bien.
Puntos clave
- Un presupuesto 50% más bajo que los demás para el mismo alcance casi siempre tiene una explicación problemática
- Las causas más comunes: alcance incompleto, equipo junior, uso de plantillas no declarado, o modelo de negocio por mantenimiento
- El costo de rehacer un proyecto mal hecho es mayor que haberlo hecho bien desde el inicio
- Un presupuesto bajo con alcance correcto existe: el objetivo es distinguir el ahorro real del riesgo disfrazado
- Las señales se identifican haciendo preguntas concretas sobre el equipo, el proceso y el alcance
Por qué los presupuestos no pueden ser demasiado bajos
El costo de un proyecto de software tiene un piso determinado por:
- Las horas reales que toma construirlo
- El costo de las personas que lo construyen
- El overhead de gestión, testing y deploy
Si un proveedor puede cotizar USD 5.000 para lo que todos los demás cotizan en USD 20.000, hay solo algunas explicaciones posibles:
- El alcance no es el mismo
- El equipo gana significativamente menos (y generalmente hay una razón)
- Están usando atajos que van a costar más adelante
- El modelo de negocio no es el proyecto en sí sino el mantenimiento posterior
- Es demasiado bueno para ser verdad
Las señales concretas
Señal 1: El presupuesto llegó en menos de 24 horas sin preguntas
Presupuestar un proyecto de software con seriedad requiere entender el alcance, hacer preguntas, estimar horas y contemplar riesgos. Eso tarda días, no horas.
Un presupuesto que llegó el mismo día sin una sola pregunta adicional es una estimación a ciegas. Cualquier número que salga de ese proceso es un número inventado, no estimado.
Lo que podés preguntar: "¿Cómo estimaron este número?" La respuesta te va a decir mucho sobre el rigor del proceso.
Señal 2: No hay desglose por componentes o fases
Un presupuesto serio desglosa: diseño, desarrollo frontend, desarrollo backend, testing, deploy. Si lo que recibiste es un número único sin desglose, no podés saber qué incluye y qué no.
Los presupuestos "todo por USD X" casi siempre tienen exclusiones implícitas que van a aparecer como adicionales durante el proyecto.
Lo que podés preguntar: "¿Podés desglosar esto por fases? ¿Qué está incluido y qué no?"
Señal 3: El diseño no está mencionado
Si el presupuesto menciona desarrollo pero no diseño UX/UI, probablemente el diseño no está incluido. Muchos proyectos baratos asumen que el cliente va a traer los diseños o que el desarrollador va a hacer "algo básico" sin un proceso de diseño real.
Un proyecto sin diseño UX termina siendo un producto que no lo usa nadie porque nadie lo entiende.
Señal 4: No hay mención de testing o QA
El testing es entre el 10% y el 15% del costo total de un proyecto bien hecho. Si no está en el presupuesto, o bien no lo hacen, o bien lo están absorbiendo en el precio de desarrollo (lo que significa menos horas de desarrollo).
Señal 5: El precio cae significativamente si pedís descuento
Un proveedor que cotizó USD 10.000 y acepta USD 6.000 sin preguntas no estaba cobrando lo que necesitaba: estaba cobrando lo que creía que ibas a pagar. Eso significa que hay margen oculto en algún lado, y probablemente ese margen es la calidad del trabajo.
Señal 6: No pueden mostrar proyectos similares en producción
"Similar" no significa del mismo rubro. Significa: similar complejidad técnica, similar tipo de funcionalidades, similar escala. Si no pueden mostrar ese trabajo, probablemente no lo hicieron antes.
Señal 7: No tienen referencias de clientes dispuestos a hablar
Ya lo mencionamos en la guía de checklist, pero vale repetirlo: un proveedor con trabajo real tiene clientes que dan referencias. Sin eso, el historial es puro marketing.
Señal 8: El modelo de negocio es el mantenimiento, no el proyecto
Algunos proveedores cotizan el desarrollo barato (o gratis) para después cobrar mantenimiento mensual obligatorio por años. En el total a 3 años, el costo puede ser el doble o el triple del proyecto cotizado a precio justo.
Lo que podés preguntar: "¿Qué pasa si después del lanzamiento quiero cambiar de proveedor de mantenimiento? ¿El código es mío y puedo hacerlo?"
Señal 9: Usan plantillas sin declararlo
Hay proveedores que bajan el costo inicial usando plantillas o código de terceros y facturan como si fuera desarrollo propio. Esto no es necesariamente un problema (las plantillas pueden ser buenas), pero tiene que ser declarado.
Lo que podés preguntar: "¿Van a usar algún boilerplate, starter kit o plantilla de base para este proyecto?" Una respuesta afirmativa y transparente no es mala; la falta de respuesta sí lo es.
El contraste: presupuesto barato legítimo vs señal de alerta
No todo presupuesto bajo es malo. Estas son situaciones donde un precio más bajo es genuino:
| Situación | ¿El bajo precio es legítimo? | Por qué |
|---|---|---|
| Freelancer senior con menos overhead que una agencia | Sí | No tiene los costos de estructura de una empresa |
| Equipo con experiencia en proyectos idénticos (reutilización legítima) | Sí | La curva de aprendizaje ya fue pagada en otro proyecto |
| Alcance más acotado que los demás presupuestos | Sí, pero hay que verificar qué falta | Están cotizando menos funcionalidades |
| Proveedor que quiere conseguir un caso de portfolio | Con precaución | El precio bajo puede no cubrir el trabajo real |
| Presupuesto sin diseño, QA ni testing declarados | No | El precio bajo esconde componentes faltantes |
| Presupuesto que cae 40%+ ante cualquier negociación | No | El precio inicial no era el precio real |
⚠️ Atención
El costo de un software mal hecho no es solo el dinero pagado. Es también: el tiempo perdido en el mercado, el daño a la confianza de los primeros usuarios, el costo de reescribir, y el dinero gastado en marketing de un producto que no funciona. El presupuesto más barato puede ser el más caro en el total.
Cómo verificar antes de firmar
Si recibiste un presupuesto muy bajo y querés entender si es legítimo o no:
-
Pedí el desglose por fases. ¿Qué incluye y qué no? Comparalo con los otros presupuestos.
-
Preguntá cómo estimaron el número. Un proceso serio tiene una respuesta seria.
-
Pedí referencias de proyectos similares. Contactalas directamente.
-
Preguntá sobre el equipo específico. ¿Quiénes son, qué experiencia tienen?
-
Hacé un mini-proyecto de prueba. USD 500–1.000 en un módulo pequeño te dice más sobre la calidad que cualquier reunión de ventas.
Preguntas frecuentes
- No siempre. Un freelancer senior con menos overhead que una agencia puede cotizar 20–30% más barato y dar el mismo resultado. Un equipo con experiencia muy específica en proyectos idénticos puede reutilizar trabajo legítimamente. El problema es cuando el precio es 50%+ más bajo que todos los demás para el mismo alcance, cuando no hay desglose, o cuando el precio baja fácilmente ante cualquier negociación.
- Las causas más comunes: alcance incompleto (no cotizan diseño, testing ni deploy), equipo sin experiencia que subestima la complejidad, uso de plantillas o código de terceros que no declaran, o un modelo de negocio donde el margen está en el mantenimiento posterior obligatorio. En algunos casos es inexperiencia genuina: el proveedor no sabe cuánto tarda hasta que lo hace.
- Es uno de los escenarios más costosos. El proyecto queda a mitad: el código parcial puede ser difícil de continuar con otro proveedor (especialmente si no está en un repositorio tuyo), el tiempo perdido no se recupera, y hay que pagar de nuevo para retomar o rehacer. Por eso la propiedad del repositorio desde el inicio es tan importante: al menos si el proyecto se detiene, tenés el código que se hizo hasta ese momento.
- Pedí que cada proveedor explique explícitamente qué incluye y qué no. Comparativamente, si uno incluye diseño UX/UI y testing y otro no, los precios no son comparables aunque parezca que sí. Una forma práctica es pedirles a todos que respondan la misma lista de preguntas: ¿Incluye diseño? ¿Incluye QA? ¿Incluye deploy? ¿Cuántas pantallas cotizan? ¿Cuántos roles de usuario?
- En el alcance, sí. En la calidad del equipo, no. Es perfectamente razonable negociar recortando funcionalidades del MVP para ajustar el presupuesto: 'Si sacamos el módulo de reportes avanzados para la versión 1, ¿cuánto baja el precio?' Lo que no conviene es pedir que bajen el precio manteniendo el mismo alcance, porque el ajuste se va a hacer en algún lado — generalmente en el tiempo de desarrollo o en la calidad del testing.