Qué incluye normalmente una cotización de desarrollo

Pediste una cotización para desarrollar un sistema, una aplicación o una plataforma. Te llega un documento — a veces un PDF de dos páginas, a veces un correo con viñetas — que incluye un número y una lista de cosas que el proveedor promete hacer. ¿Es suficiente? ¿Cómo sabés si lo que estás leyendo cubre todo lo que debería cubrir?

Las cotizaciones de desarrollo de software no tienen un formato estándar. Cada proveedor las presenta a su manera, y la calidad de una propuesta dice mucho sobre la calidad del proveedor. Este artículo explica los elementos que una cotización seria debería incluir y, tan importante como eso, qué omisiones deberían encender una luz de alerta.

Los elementos mínimos de una cotización

El alcance: qué está incluido y qué no

El alcance es la sección más importante de cualquier cotización y, con frecuencia, la peor redactada. Un alcance bien definido no es una lista genérica de funcionalidades. Es una descripción que permite que dos personas distintas — vos y el proveedor — entiendan exactamente lo mismo sobre lo que se va a construir.

Tan importante como lo que está incluido es lo que está explícitamente excluido. Una buena cotización dedica una sección a decir "esto no está incluido". Si esa sección no existe, asumí que cualquier cosa que no esté escrita en el alcance puede ser considerada fuera del proyecto por el proveedor.

El cronograma con hitos verificables

Un cronograma serio no dice "el proyecto durará cuatro meses". Dice algo como:

• Mes 1: entrega del módulo de registro de clientes con pruebas de aceptación.
• Mes 2: entrega del módulo de facturación funcionando sobre datos de prueba.
• Mes 3: integración completa y pruebas con datos reales.
• Mes 4: puesta en producción y capacitación.

Cada hito debería estar asociado a un entregable concreto que puedas verificar. Si el cronograma es "desarrollo: 3 meses, testing: 1 mes", sin desglose, no tenés forma de saber si el proyecto va bien o mal hasta que sea demasiado tarde.

El modelo de cobro y las condiciones de pago

La cotización debe explicitar si el cobro es por precio fijo, por hora, por equipo mensual o una combinación. También debe aclarar:

• ¿Se paga por adelantado, contra hitos o al final?
• ¿Hay un monto mínimo comprometido?
• ¿Qué pasa si el alcance cambia durante el proyecto? ¿Cómo se cotiza el trabajo adicional?
• ¿Hay costos adicionales no incluidos en el precio? Por ejemplo: servidores, licencias de terceros, dominios, certificados de seguridad.

Un proveedor serio no tiene problema en transparentar estas condiciones. Uno que las evade probablemente tenga algo que ocultar.

El plan de mantenimiento posterior

Muchas cotizaciones terminan en la entrega del producto. Pero un sistema de software no deja de necesitar atención el día que se lanza. La cotización debería incluir — o al menos mencionar — qué pasa después:

• ¿Hay un período de garantía donde los errores se corrigen sin costo adicional?
• ¿Cuánto dura esa garantía? Treinta, sesenta, noventa días.
• ¿Ofrecen un plan de mantenimiento mensual? ¿Qué incluye y qué no?
• ¿Qué pasa si aparece un error grave después del período de garantía? ¿Hay un costo estándar por hora para correcciones?

Si la cotización no menciona el mantenimiento, asumí que cualquier corrección posterior al lanzamiento se va a pagar aparte y probablemente a un costo más alto que el del desarrollo inicial.

La propiedad del código y los entregables

Esta sección es crítica y muchas cotizaciones la omiten o la tratan con ambigüedad. Al finalizar el proyecto deberías saber:

• ¿El código fuente es tuyo o del proveedor?
• ¿Recibís acceso al repositorio de código?
• ¿Recibís documentación técnica y manuales de usuario?
• ¿Las cuentas de servicios cloud (servidores, bases de datos) quedan a tu nombre o a nombre del proveedor?

Si querés profundizar en este tema, leé quién debería ser dueño del código fuente.

Lo que una cotización NO debería tener

Hay señales que, cuando aparecen en una cotización, deberían hacerte dudar:

• Un precio sin alcance detallado. Un número sin una descripción precisa de lo que compra es un riesgo. Lo barato que parecía se convierte en caro cuando aparece todo lo que no estaba incluido.

• Plazos imposibles. Si el proveedor promete construir un sistema complejo en tres semanas, o está subestimando groseramente el trabajo o planea entregar algo que no se parece a lo que vos imaginás.

• Falta de información sobre el equipo. ¿Quién va a trabajar en tu proyecto? ¿Cuántas personas? ¿Qué experiencia tienen? Una cotización que no menciona al equipo es una caja negra.

• Términos vagos sobre cambios de alcance. Los cambios durante el desarrollo son inevitables. Si la cotización no dice cómo se gestionan, preparate para discusiones sobre qué estaba incluido y qué no.

La cotización como señal del proveedor

La forma en que un proveedor presenta su cotización dice más sobre cómo va a ser la relación de trabajo que cualquier reunión de venta. Un proveedor que entrega un presupuesto detallado, con exclusiones claras, hitos verificables y un plan de mantenimiento, probablemente maneje el proyecto con el mismo nivel de orden. Uno que entrega dos páginas con un número y una lista vaga de funcionalidades probablemente tenga el mismo nivel de desorden en la ejecución.

La cotización no es un trámite. Es el primer entregable de tu proveedor. Leerlo con criterio es la primera inversión que hacés en el éxito del proyecto.