La semana pasada me llamó un gerente de operaciones con la misma frustración que escuchamos todo el tiempo: había pedido cotizaciones a tres empresas para un sistema de gestión interno. Una llegó en horas con un número redondo. Otra llegó dos días después con cuarenta páginas de texto técnico que no le decía nada útil. La tercera nunca llegó. Me preguntó: ¿cómo sé cuál es la buena?
Es la pregunta correcta. Y la respuesta no tiene que ver con el precio.
Una propuesta de software a medida no es una factura proforma — es el contrato moral de lo que te van a construir. Si la propuesta que recibes no dice con claridad qué incluye, qué no incluye, quién lo hace y cómo sabrás que está listo, entonces no tienes información para decidir. Tienes solo un número.
Antes de pedir una cotización: qué debes tener listo
El peor escenario es escribirle a cinco proveedores “necesito un sistema, ¿cuánto cuesta?” sin más información. Las cotizaciones que recibirás serán inútiles, porque no están respondiendo a tu problema real, están rellenando un formulario.
Para que una propuesta sirva, el proveedor tiene que entender al menos cinco cosas:
- El problema que resuelves, no la solución que imaginas. “Necesito que los vendedores vean en tiempo real el stock de bodega” es mucho mejor que “necesito una app móvil”.
- Quiénes lo van a usar y cuántos son. Diez usuarios internos no es lo mismo que mil clientes externos.
- Con qué sistemas tiene que convivir. Si hay un ERP, un CRM o alguna integración de sistemas existente, eso cambia todo.
- Cuál es el plazo real. No el ideal, el real. Si hay una fecha límite inamovible, dilo desde el principio.
- Cuál es el presupuesto aproximado. Sé que cuesta decirlo, pero un proveedor serio no te va a cobrar más por mencionarlo. Te va a ahorrar tiempo si tu rango no calza con lo que necesitas.
Con esa información, una propuesta seria debería llegar en 3 a 7 días hábiles para proyectos de complejidad media.
Qué debe incluir una propuesta seria: el checklist completo
Cuando revises una cotización, verifica cada uno de estos puntos. Una propuesta que no tiene la mayoría de esto no está lista para firmar.
✓ Alcance detallado — lo que sí incluye No “un sistema de gestión” sino módulos, flujos y pantallas específicas. Si es una aplicación, ¿cuántas pantallas? ¿Cuáles exactamente? Si tiene panel de administrador, ¿qué puede hacer el administrador y qué no?
✓ Exclusiones explícitas — lo que no incluye Esto es tan importante como el alcance. ¿El diseño es a medida o usa plantillas? ¿Incluye QA o solo desarrollo? ¿Está incluida la infraestructura — servidor, dominio, certificados SSL? ¿Cómo se gestionan los bugs después de la entrega?
✓ Partidas desglosadas por fase o módulo No un número total, sino líneas. Fase 1: levantamiento y diseño. Fase 2: desarrollo del módulo de clientes. Fase 3: integración con ERP. Así sabes exactamente a qué le pones la firma.
✓ Equipo propuesto ¿Quién desarrolla? No la empresa — las personas: perfil, seniority, dedicación semanal. Un proyecto de 500 UF ejecutado por una persona junior a medio tiempo es muy distinto del mismo precio con un senior dedicado.
✓ Plazos con hitos verificables No “3 a 4 meses”. Semana X: entrega de wireframes. Semana Y: primer módulo funcional en staging. Semana Z: período de UAT. Semana W: producción. Cada hito debe ser verificable antes de pagar el siguiente.
✓ Modalidad de cobro y distribución de pagos ¿Cómo se distribuye el pago? Lo más razonable: 30–40% al inicio, el resto ligado a hitos de entrega. Nadie debería pedirte el 100% por adelantado.
✓ Proceso de change requests ¿Qué pasa si necesitas cambiar algo después de firmar? Una propuesta seria define el proceso: cómo se cotiza un cambio, quién lo aprueba, cómo afecta el plazo y el costo.
✓ Criterios de aceptación ¿Cómo sabes que el sistema está listo y que funciona? “Que funcione bien” no es un criterio. “Que el módulo de pagos procese una transacción de prueba sin errores en menos de 3 segundos” sí lo es.
✓ Garantía post-entrega ¿Cuánto tiempo tienen para corregir bugs del alcance original sin costo adicional? 30, 60 o 90 días es lo estándar en Chile.
✓ Propiedad del código y transferencia ¿El código es tuyo al final? ¿En qué repositorio vive? ¿Las librerías que usan tienen licencia comercial o son open source? Estas preguntas parecen técnicas, pero son tuyas como cliente.
Las partidas de costo: qué estás pagando realmente
Una propuesta de software a medida cubre varias categorías de trabajo. Esto es lo que debería estar desglosado — y lo que suele quedar oculto en los precios “todo incluido”:
| Partida | Descripción | % típico del proyecto |
|---|---|---|
| Levantamiento y diseño UX | Entrevistas, wireframes, prototipo navegable | 10–20% |
| Desarrollo backend | Lógica de negocio, base de datos, APIs | 30–40% |
| Desarrollo frontend / UI | Interfaz de usuario, pantallas, componentes | 20–30% |
| QA y pruebas | Testing manual y automatizado | 10–15% |
| Integraciones externas | Conexión con ERP, CRM, pasarelas, APIs | Variable (0–30%) |
| Infraestructura y deploy | Servidores, CI/CD, staging, DNS | 5–10% |
| Gestión de proyecto | PM, reuniones, documentación | 5–10% |
| Mantención post-lanzamiento | Soporte, correcciones, updates de seguridad | ≠ va aparte, ~15–20% anual |
Valores referenciales de mercado en Chile 2026. Los porcentajes varían según tipo y complejidad del proyecto.
Para que tengas una referencia concreta, estos son rangos típicos por partida en proyectos de tamaño medio (400–800 UF total):
| Partida | Rango referencial (UF) | Aprox. CLP | Aprox. USD |
|---|---|---|---|
| Levantamiento + diseño UX/UI | 40 – 120 UF | $1,6M – $4,7M | US$1.700 – 5.000 |
| Desarrollo backend | 120 – 320 UF | $4,7M – $12,6M | US$5.000 – 13.300 |
| Desarrollo frontend | 80 – 200 UF | $3,1M – $7,9M | US$3.300 – 8.300 |
| QA | 40 – 100 UF | $1,6M – $3,9M | US$1.700 – 4.200 |
| Mantención anual (post-proyecto) | 80 – 160 UF/año | $3,1M – $6,3M/año | US$3.300 – 6.700/año |
UF referencial: ~$39.300 (julio 2026); USD referencial: ~$950. Valores referenciales — el precio final depende del alcance específico.
Lo que más me sorprende al comparar propuestas del mercado chileno es que muchas no separan la mantención. El desarrollo y la mantención son cosas distintas: uno es el costo de construir, el otro es el costo de que viva. Un proyecto de 800 UF implicará del orden de 120–160 UF al año para mantenerlo sano. Mézclate ese número en el TCO a 3 años antes de comparar opciones.
Banderas rojas que te deben hacer dudar
Después de revisar decenas de propuestas del mercado local, estas son las señales que me hacen retroceder:
🚩 Llega el mismo día sin preguntas previas Si cotizaron sin entender el alcance, el número no significa nada. O es una cifra inventada, o subcontrataron todo sin ni siquiera leer el correo.
🚩 El alcance está escrito en jerga técnica que el cliente no entiende Una propuesta está escrita para quien paga, no para quien construye. Si no entiendes con claridad qué vas a recibir, no firmes.
🚩 No hay exclusiones Toda propuesta que dice incluir “todo lo necesario para el correcto funcionamiento del sistema” está diciendo que incluye nada definido. El scope creep más caro siempre viene de las exclusiones que no se mencionaron.
🚩 Precio fijo sin alcance fijo El precio fijo solo tiene sentido si el alcance también está fijo. Si hay ambigüedad en lo que se construye y aun así te ofrecen precio fijo, alguien va a perder — y generalmente no es el proveedor.
🚩 Sin hitos intermedios — entrega “al final” Un proyecto que dura meses sin visibilidad intermedia es un proyecto sin control. Exige revisiones cada 2 a 4 semanas con avances verificables.
🚩 El equipo es “nuestro equipo de desarrollo” Sin perfiles, seniority ni dedicación concreta, no sabes quién va a construir tu sistema. Pregunta con nombre y apellido si es necesario.
🚩 El precio es menos de la mitad que los otros Puede ser eficiencia real. Puede ser que van a subcontratar a alguien sin experiencia o que cotizaron la mitad del alcance. Pide que justifiquen el desglose partida por partida.
Cómo comparar cotizaciones de distinto precio
Cuando tienes dos propuestas — una de 400 UF y otra de 700 UF para “lo mismo” — la forma incorrecta de comparar es ver cuál es más barata. La forma correcta es hacer una tabla de diferencias:
| Ítem | Propuesta A (400 UF) | Propuesta B (700 UF) |
|---|---|---|
| Diseño UX/UI | Plantilla estándar | A medida con prototipo |
| QA incluido | No especificado | Sí, 10% del presupuesto |
| Integraciones | ”Según requerimiento” | ERP + pasarela de pago incluidas |
| Mantención post-lanzamiento | No incluida | 3 meses incluidos |
| Equipo | 1 desarrollador | Tech lead + developer + PM |
| Hitos intermedios | Solo entrega final | Sprints quincenales |
| Código fuente | Consultar | Repositorio del cliente desde el día 1 |
Ejemplo ilustrativo. Adapta la tabla a las propuestas que recibas.
Cuando llevas ese análisis a números reales, la diferencia raramente es de 300 UF. Suele ser que la propuesta más barata asume que el cliente va a hacer parte del trabajo, o que hay funciones que se cobrarán como “adicionales” después de firmar.
Lo que le digo siempre a los clientes: el precio es lo último que hay que mirar. Primero el alcance, luego el equipo, luego la metodología. El precio viene al final, cuando ya sabes que estás comparando lo mismo.
Cómo lo hacemos en Apollo.TI
Cuando alguien nos escribe para pedir una cotización, lo primero que hacemos no es enviar un número — es agendar una sesión de levantamiento. Puede durar 30 minutos o dos horas según la complejidad del proyecto. El objetivo es entender el problema real antes de proponer nada.
Nuestra propuesta siempre incluye el alcance desglosado por módulo o fase, con criterios de aceptación claros, hitos de pago ligados a entregas verificables y exclusiones explícitas. No porque queramos protegernos legalmente, sino porque es la única manera de que el cliente sepa exactamente lo que está contratando — y de que nosotros nos comprometamos con algo alcanzable.
Somos un equipo AI-native: usamos inteligencia artificial en el desarrollo en el día a día — generación de código asistida, QA automatizado, documentación. Eso nos permite comprimir entre un 20% y un 40% el tiempo en fases de prototipado, generación de CRUD y pruebas repetitivas. Menos horas de ingeniería senior en tareas que la IA acelera se traduce directamente en el presupuesto del cliente.
Si llegaste acá porque tienes cotizaciones en mano y no sabes cómo evaluarlas, lo más práctico que puedo ofrecerte es una sesión de consultoría donde las revisamos juntos. Sin compromiso. Si hay algo raro, te lo digo. Si todo está bien, también.
Para entender mejor los rangos de precios según tipo de proyecto, revisa la guía de costos de software a medida en Chile. Y si quieres ver cómo se ve un proyecto bien ejecutado — con plazos, alcance y entrega real — los casos de Apollo.TI muestran exactamente eso.
Preguntas frecuentes
¿Cuánto tiempo debería tardar en llegar una cotización seria de software a medida?
Entre 3 y 7 días hábiles para proyectos medianos. Si llega el mismo día que enviaste el brief, es una señal de alerta: cotizaron sin entender bien el alcance. Si tarda más de dos semanas sin que haya un taller de levantamiento de por medio, también es problema.
¿Es normal pagar por recibir una propuesta de software?
Para un brief básico, no: la propuesta debería ser gratuita. Para proyectos complejos que requieren análisis previo de más de dos horas, algunos equipos cobran un fee de evaluación de 50 a 150 UF que luego se descuenta del proyecto. Lo que no es aceptable es que te pidan dinero antes de hacerte una sola pregunta.
¿Cómo comparo dos cotizaciones de distinto precio?
No compares el precio total directamente. Compara ítem por ítem: ¿la propuesta más barata incluye diseño UX?, ¿QA?, ¿mantención post-lanzamiento?, ¿quién es el equipo real? Una cotización 40% más barata generalmente tiene exclusiones que no ves hasta que firmas el contrato.
¿Conviene precio fijo o por hora para desarrollo de software?
Precio fijo funciona cuando el alcance está bien definido; te protege del scope creep. Por hora (time & material) es válido para proyectos exploratorios o evolutivos, pero requiere visibilidad semanal de horas y un cap acordado. Nunca firmes time & material sin límite de horas.
¿Qué pasa si el alcance cambia después de firmar la propuesta?
Va a cambiar, siempre. Una propuesta seria incluye un proceso de change request: cualquier modificación fuera del alcance inicial se cotiza y aprueba por separado antes de implementarse. Sin ese proceso, el scope creep puede doblar el costo sin que nadie lo vea venir.
¿Tienes cotizaciones en mano y no sabes cómo evaluarlas? Agendemos una sesión de revisión — te decimos qué está bien, qué falta y si los números tienen sentido para lo que necesitas. Conversemos.