Qué Debe Incluir una Cotización de Desarrollo de Software (y Qué Señales son Red Flags)

Lista de verificación para evaluar cotizaciones de proyectos de software. Qué pedir, qué desconfiar, cómo comparar peras con peras. Hecho por programadores.

Pedir una cotización de software es fácil. Saber leerla bien, compararla con otras dos, y detectar los problemas escondidos antes de firmar — eso es lo difícil. Esta guía está hecha por programadores que han escrito y leído cientos de cotizaciones. Sirve para que cualquier persona — técnica o no — evalúe propuestas y evite los errores más caros.

Si solo tiene 3 minutos: lea las 12 cosas que debe incluir y los 8 red flags. Eso ya filtra el 80% de las propuestas malas.

Contenido de esta guía

Por qué importa la cotización
12 cosas que debe incluir cualquier cotización seria
8 red flags: frases peligrosas a evitar
Cómo comparar 3 cotizaciones lado a lado
Plantilla mental: la tabla comparativa
Qué preguntar en la reunión de presentación

Por qué importa la cotización

Una cotización es un documento legal. Es la base del contrato. Es la única referencia objetiva si más adelante hay un desacuerdo. Lo que no esté en la cotización, no existe — o cuesta extra.

Una cotización mal hecha (vaga, sin alcance claro, sin entregables definidos) genera:

"Esto no estaba incluido, son $X adicionales"
"Eso lo pensamos diferente, hay que rehacerlo"
"El timeline asumía que ustedes nos dieran X, no nos lo dieron"
"Eso no es bug, es nueva feature"

Una cotización bien hecha (específica, con entregables claros, con asunciones documentadas) protege a las dos partes y permite que el proyecto avance sin sorpresas.

12 cosas que debe incluir cualquier cotización seria

1. Alcance funcional detallado

No "hacemos su sistema de inventarios". Sí: "módulo de productos con 7 campos, módulo de movimientos con entradas y salidas, reporte de existencias, alerta de stock mínimo, integración con báscula vía RS-232". Cada feature listada y descrita.

Por qué importa: sin esto, cualquier debate sobre "esto estaba incluido" es palabra contra palabra.

2. Lo que NO incluye

Igual de importante que lo que sí. "Esta cotización no incluye: hosting, dominio, certificados SSL, licencias de software de terceros, contenido (textos e imágenes), integración con WhatsApp Business API, soporte fuera de horario laboral".

Por qué importa: previene la conversación incómoda al final del proyecto.

3. Entregables específicos por hito

"Hito 1 (semana 4): demo del flujo de login, registro de empresa, registro de usuarios". No "vamos a entregar avances mensuales".

Por qué importa: cada hito es un punto donde el cliente puede revisar y aprobar antes de pagar. Sin hitos, el cliente paga a ciegas.

4. Timeline realista con dependencias

"Inicio: semana del 5 de mayo. Hito 1: 28 mayo. Hito 2: 25 junio. Hito 3: 23 julio. Lanzamiento: 13 agosto. Asume que el cliente entrega los textos finales antes del 20 de mayo y los accesos a Stripe antes del 1 de julio."

Por qué importa: los timelines sin dependencias siempre se rompen. Documentar las dependencias del cliente protege al proveedor y obliga al cliente a moverse.

5. Stack técnico específico

"Backend: .NET 9 con Clean Architecture, base de datos PostgreSQL 16. Frontend: Next.js 16, TypeScript, Tailwind CSS. Hosting: Azure App Service (US East). CI/CD: GitHub Actions."

Por qué importa: sin esto, no se sabe qué se está comprando. Tampoco se sabe si el cliente puede mantenerlo más adelante con otro equipo.

6. Equipo asignado y roles

"1 Tech Lead (60% del proyecto), 2 Senior Developers (full-time), 1 QA (30%), 1 Project Manager (20%). Tech Lead: Juan Pérez, 12 años de experiencia, certificado Azure."

Por qué importa: si la propuesta no dice quién lo hace, probablemente lo va a hacer un junior bajo supervisión teórica.

7. Modelo de pagos

"30% al firmar contrato, 30% al hito 1, 30% al hito 2, 10% al lanzamiento. Pagos a 7 días desde la factura. Moneda: USD."

Por qué importa: el modelo de pagos refleja la confianza mutua. Un proveedor que pide 100% por adelantado tiene un problema. Uno que ofrece 0% upfront probablemente cierra muchos proyectos a pérdida.

8. Garantía post-entrega

"Garantía de 90 días después del lanzamiento: bugs reportados se corrigen sin costo adicional. No incluye nuevas features ni cambios de alcance."

Por qué importa: sin garantía explícita, todo bug post-lanzamiento es "una nueva consulta" y se cobra extra.

9. Propiedad intelectual

"Al pago final, la propiedad intelectual del código se transfiere al cliente. El cliente recibe acceso completo al repositorio Git, documentación técnica y credenciales de servicios. El proveedor mantiene el derecho de mostrar el proyecto en su portafolio."

Por qué importa: sin esta cláusula, el cliente puede terminar pagando por software que no es suyo.

10. Confidencialidad (NDA)

Mención explícita de manejo de información sensible: datos de clientes finales, código, modelos de negocio. Mejor si viene como anexo NDA firmado por separado.

Por qué importa: protege al cliente. La ausencia de mención sugiere que el proveedor no piensa en seguridad.

11. Asunciones explícitas

"Esta cotización asume: máximo 5,000 usuarios concurrentes, integraciones con 2 servicios externos máximo, no cambios regulatorios mayores durante el desarrollo, disponibilidad del cliente para revisión semanal de 1 hora."

Por qué importa: las asunciones documentadas son el ancla cuando algo cambia. "Eso no estaba en las asunciones" es un argumento legítimo.

12. Procedimiento para cambios de alcance (change orders)

"Cualquier cambio fuera del alcance original se evalúa, cotiza por separado y requiere aprobación escrita antes de iniciarse. Tarifa de cambio: $X/hora."

Por qué importa: los cambios de alcance son inevitables. Sin un procedimiento claro, terminan en peleas. Con procedimiento claro, son rutina.

8 red flags: frases peligrosas a evitar

1. "Hacemos cualquier cosa que necesite"

Traducción: no tienen especialización. Las empresas serias saben qué hacen bien y dicen que no a lo que no.

2. "El precio incluye revisiones ilimitadas"

Traducción: o el precio está inflado para cubrir el riesgo, o el proveedor va a cortar la calidad cuando empiece a perder dinero. No existe "ilimitado" en un negocio sano.

3. "Lo entregamos en 2 semanas" (para cualquier proyecto no trivial)

Traducción: o no entendieron el alcance, o están subestimando para cerrar la venta. Cuando el plazo se incumpla, el cliente está atrapado.

4. "No necesitamos contrato, somos serios"

Traducción: alguna combinación de ingenuidad, falta de profesionalismo, o intención de no cumplir. El contrato protege a ambas partes — rechazarlo es una bandera roja gigante.

5. "El precio depende de cuánto le funcione" (sin tarifa base clara)

Traducción: modelo de "éxito" que en la práctica significa que el proveedor decide cuánto cobrar al final. Solo funciona en escenarios muy específicos (performance marketing, ventas) — no en desarrollo de software.

6. "Pagas todo por adelantado y empezamos mañana"

Traducción: flujo de caja del proveedor está mal o el cliente es desechable después del cobro inicial. Estándar serio: 30–50% upfront, resto contra entregables.

7. "No es necesario que vea el código, confíe en nosotros"

Traducción: no quieren que el cliente sepa cómo está hecho, probablemente porque está mal. El código del cliente es del cliente — debe tener acceso desde el día uno.

8. "Nuestro precio incluye todo lo que se le ocurra"

Traducción: no leyeron el alcance. O lo leyeron y van a inventar excusas más adelante. "Todo" no es un alcance; es una promesa vacía.

Cómo comparar 3 cotizaciones lado a lado

El error más común es comparar precios sin normalizar alcances. Una cotización de $20,000 puede ser más barata en realidad que una de $15,000 si la primera incluye soporte 6 meses y la segunda no.

Paso 1: Normalizar alcances

Ponga las 3 cotizaciones en una tabla con las features de cada una. Lo que una incluye y otra no, márquelo. Si una es más cara pero incluye 5 cosas que las otras cobrarían como extra, súmele esos extras al precio de las otras para comparar manzanas con manzanas.

Paso 2: Normalizar entregables

¿Las tres entregan código fuente? ¿Las tres incluyen documentación técnica? ¿Las tres entregan los datos en formato exportable? Si una no, descontar valor.

Paso 3: Evaluar timeline realista

¿Las tres prometen el mismo tiempo? Si una promete la mitad del tiempo, asuma que está mintiendo o subestimando. Pregunte cómo lo logran.

Paso 4: Verificar referencias

Pida 3 referencias de cada uno. Llame al cliente directamente (no acepte testimonios escritos sin contacto). Pregunte: "¿lo contrataría otra vez? ¿qué fue lo más difícil del proyecto? ¿hubo cambios de alcance?".

Paso 5: Evaluar fit cultural

¿Responden los emails en horas o en días? ¿La propuesta tiene errores de ortografía? ¿Las llamadas son puntuales? Estas señales pequeñas predicen cómo será trabajar con ellos.

Plantilla mental: la tabla comparativa

Use esta estructura para evaluar 3 propuestas:

| Criterio | Propuesta A | Propuesta B | Propuesta C | |----------|-------------|-------------|-------------| | Precio total | $ | $ | $ | | Alcance funcional (escala 1–10 según completitud) | | | | | Entregables incluidos | | | | | Timeline | semanas | semanas | semanas | | Stack técnico | | | | | Equipo asignado | personas/seniority | personas/seniority | personas/seniority | | Modelo de pago | % upfront / hitos | % upfront / hitos | % upfront / hitos | | Garantía post-entrega | meses | meses | meses | | Propiedad código | ¿se transfiere? | ¿se transfiere? | ¿se transfiere? | | Asunciones documentadas | sí / no | sí / no | sí / no | | Referencias verificables | cantidad | cantidad | cantidad | | Red flags detectados | lista | lista | lista |

Una vez completa, la decisión casi se toma sola.

Qué preguntar en la reunión de presentación

Cinco preguntas que separan a los proveedores serios de los que están vendiendo humo:

1. "¿Qué pasa si el desarrollador asignado se enferma o renuncia?"

Buena respuesta: "Tenemos un equipo, hay overlap entre desarrolladores, el código está documentado, otra persona puede continuar." Mala respuesta: "Eso no va a pasar."

2. "¿Pueden mostrarme un proyecto similar al mío que hayan entregado?"

Buena respuesta: muestran demos, links, referencias. Mala respuesta: "No podemos por confidencialidad" (sin alternativas).

3. "¿Qué pasa si el alcance cambia a mitad del proyecto?"

Buena respuesta: explican el procedimiento de change orders, tarifa, tiempo de evaluación. Mala respuesta: "Lo discutimos cuando pase."

4. "¿Cuál es su tasa de proyectos que se entregan dentro del timeline original?"

Buena respuesta: un número honesto (60–80% es realista para proyectos serios) y explicación de qué causa los retrasos. Mala respuesta: "100%, siempre cumplimos."

5. "¿Quién es responsable si hay un bug crítico el día del lanzamiento?"

Buena respuesta: "Nosotros, dentro del período de garantía. Hay un proceso de hotfix con SLA de X horas." Mala respuesta: "Tendríamos que cotizar la corrección."

Resumen ejecutivo

Una cotización seria es específica, documenta asunciones, define entregables claros y deja por escrito qué pasa cuando algo sale mal. Una cotización pobre es vaga, promete demasiado, evita los temas difíciles y llega al cliente como "una propuesta breve para que arranquemos rápido".

Tomar 2 horas adicionales para evaluar bien una cotización — pidiendo todo lo que falta, haciendo las preguntas incómodas, comparando con otras dos — ahorra meses de problemas y miles de dólares.

Si quieres una segunda opinión sobre tu cotización o necesitas un equipo serio que cotice claro y entregue lo prometido, contactanos.