Cómo leer una cotización de desarrollo de software sin ser técnico
Qué debe contener una cotización seria, qué omisiones predicen sobrecostos y cómo comparar propuestas que llegan con números muy distintos.
Una cotización de desarrollo de software seria detalla alcance, supuestos, exclusiones, forma de pago y qué pasa cuando algo cambia. Las que solo traen un número y una lista de funcionalidades esconden el riesgo en las omisiones: QA, integraciones, ambientes y soporte suelen ser lo que falta.
Recibir tres cotizaciones para el mismo proyecto y que una cueste tres veces más que otra no significa que alguien esté abusando. Casi siempre significa que están cotizando cosas distintas. El problema es que la diferencia no está en lo que dicen, sino en lo que omiten.
No hace falta ser técnico para detectarlo. Hace falta saber qué buscar.
¿Qué debe contener una cotización seria?
Independientemente del monto, una propuesta profesional incluye seis elementos. Si falta alguno, no es que la cotización sea mala: es que ese riesgo quedó sin asignar, y por defecto lo absorbes tú.
| Elemento | Qué debe decir | Si falta, qué pasa |
|---|---|---|
| Alcance | Qué se construye, con qué roles y flujos | Cada aclaración se vuelve negociación |
| Supuestos | Qué se dio por cierto al cotizar | Cualquier supuesto falso es un costo extra |
| Exclusiones | Qué NO está incluido | Descubres los faltantes a mitad del proyecto |
| Entregables | Qué recibes y en qué formato | No hay forma objetiva de dar por terminado |
| Manejo de cambios | Cómo se cotiza lo que surja | Todo cambio se vuelve conflicto |
| Pagos y plazos | Contra qué hitos se paga | Pagas por tiempo, no por avance |
Las cuatro omisiones que predicen sobrecostos
Cuando una propuesta llega notablemente más barata que las demás, revisa estos cuatro rubros antes de celebrar. En la mayoría de los casos, ahí está la diferencia.
- QA y pruebas: si no aparece como línea, se está asumiendo que el desarrollador prueba su propio trabajo. Funciona hasta que no.
- Integraciones: conectar con un ERP, un CRM o una pasarela de pagos es trabajo de ingeniería, no una casilla que se activa.
- Ambientes e infraestructura: desarrollo, pruebas y producción son tres entornos. Si solo se contempla uno, los errores se descubren con usuarios reales.
- Soporte post-lanzamiento: qué pasa las primeras semanas después de salir a producción, que es cuando aparece casi todo.
¿Cómo comparar propuestas con números muy distintos?
Normalízalas antes de compararlas. Toma la propuesta más completa como referencia y pregunta a las demás, por escrito, si cada rubro está incluido. Las respuestas suelen cerrar la brecha de precio por sí solas, y las que no responden con claridad ya te dijeron lo que necesitabas saber.
Compara también el modelo de entrega. Un proyecto por fases con alcance cerrado en cada una y un proyecto de bolsa de horas abierta no son comparables aunque el total coincida: en el primero el riesgo de estimación lo asume el proveedor, en el segundo lo asumes tú.
El precio bajo que sale caro
Hay una asimetría incómoda en este mercado: el proveedor que cotiza completo se ve caro frente al que cotiza incompleto, y pierde el proyecto. Meses después el segundo presupuesto ya se igualó al primero vía cambios de alcance, pero para entonces cambiar de proveedor cuesta más que continuar.
La forma de protegerte no es desconfiar del precio bajo, sino exigir que todos coticen sobre el mismo alcance escrito. Si tú defines el alcance, las propuestas se vuelven comparables. Si dejas que cada proveedor lo defina, estás comparando peras con documentos distintos.
El presupuesto que se cierra rápido porque nadie hizo preguntas es el que se reabre a los tres meses.
Qué llevar para recibir una cotización útil
Antes de pedir números, define el problema que quieres resolver, quién lo vive todos los días, cuál es el flujo que hay que validar primero y con qué sistemas debe conectarse lo que se construya. Con eso, cualquier proveedor serio puede proponer fases en lugar de un número genérico.
Si buscas rangos de referencia antes de la primera llamada, publicamos los nuestros para desarrollo de aplicaciones móviles en México.
Puntos clave
- Seis elementos obligatorios: alcance, supuestos, exclusiones, entregables, manejo de cambios y pagos.
- Las omisiones típicas que explican un precio bajo son QA, integraciones, ambientes y soporte.
- Define tú el alcance por escrito para que las propuestas sean comparables entre sí.
- Un proyecto por fases y una bolsa de horas abierta no son comparables aunque el total coincida.
Preguntas frecuentes
Respuestas directas para cotizar, decidir stack o validar si conviene construir.
Alcance detallado, supuestos considerados, exclusiones explícitas, entregables con formato, procedimiento para manejar cambios, y calendario de pagos ligado a hitos verificables. Si alguno falta, ese riesgo queda sin asignar y por defecto lo absorbe el cliente.
Porque rara vez cotizan lo mismo. Las diferencias suelen estar en QA, integraciones con sistemas existentes, ambientes de pruebas y soporte posterior al lanzamiento. Al normalizar los rubros, la brecha de precio se reduce considerablemente en la mayoría de los casos.
Al contrario. Las exclusiones explícitas indican que el proveedor pensó el proyecto a fondo y está delimitando riesgo de forma transparente. Preocúpate más por las propuestas sin exclusiones: no significan que todo esté incluido, significan que nadie lo definió.
Por proyecto cerrado cuando el alcance es claro, porque el riesgo de estimación lo asume el proveedor. Por horas cuando el alcance es genuinamente exploratorio. Lo que no conviene es una bolsa de horas abierta presentada como si fuera un proyecto cerrado.
El problema a resolver, el usuario que lo vive, el flujo crítico y los sistemas con los que debe integrarse. Sin eso, cualquier número es una estimación a ciegas que se va a corregir al alza durante el proyecto.
Cuánto cuesta una app en México 2026: $150K–$2M MXN
¿Cuánto cuesta desarrollar una app en México? Rangos reales 2026, desde MVP hasta plataformas enterprise. Qué mueve el costo y cómo cotizar sin sorpresas.
Agencia, freelance o equipo interno: qué conviene según la etapa de tu empresa
Los tres modelos para construir software tienen costos ocultos distintos. Criterios para elegir según etapa, volumen de proyectos y tolerancia al riesgo operativo.
API, RPA o IoT en planta: cuándo cada uno
API vs RPA vs IoT en planta: cuándo cada capa, cómo conviven en un mismo flujo y qué se rompe si eliges mal. Criterios para México, sin demo de fábrica 4.0.