Cómo cotizar un desarrollo de software sin que te lo tumben

Esto va para quien vende desarrollo y para quien lo compra, porque el problema es el mismo visto desde los dos lados: una cotización mal armada termina en un proyecto que se alarga, una relación que se daña y alguien que siente que lo tumbaron.

Y casi siempre el origen no fue el precio. Fue que nadie escribió dónde terminaba el trabajo.

El error que cuesta más caro

Una cotización que dice «desarrollo de sistema de facturación — 8 semanas — valor X» no es una cotización: es una apuesta. No dice qué incluye, qué no, quién entrega qué ni qué pasa si a mitad de camino aparece un requisito nuevo. Y siempre aparece.

El cliente no es malintencionado. Simplemente no sabía lo que quería hasta que vio la primera versión, que es lo normal en software. El problema es que sin un límite escrito, cada descubrimiento se convierte en «eso estaba incluido, ¿no?».

Los tres modelos y quién asume el riesgo

Precio cerrado. El proveedor asume el riesgo. Solo funciona si el alcance está escrito con suficiente detalle como para que un tercero pueda decir si algo está dentro o fuera. Si no lo está, el proveedor infla el precio para cubrirse —y el cliente paga de más— o no lo infla y pierde.

Tiempo y materiales. El cliente asume el riesgo. Es honesto cuando hay incertidumbre real, pero necesita un tope acordado y reportes frecuentes, porque si no, el cliente siente que firmó un cheque en blanco.

Descubrimiento pagado y después cierre. Una primera fase corta y pagada cuyo entregable es el documento de alcance, la arquitectura y la cotización cerrada del resto. Es el modelo que aplica en la mayoría de los proyectos reales, y el que menos relaciones rompe.

Qué tiene que decir una cotización que no te va a doler

Sección	Qué debe contener
Alcance incluido	Lista concreta de funcionalidades. Verbos, no adjetivos: «el usuario genera un PDF de la factura», no «módulo robusto de facturación».
Alcance excluido	Lo que un cliente podría asumir que va incluido y no va. Esta sección vale más que la anterior.
Supuestos	De qué depende la estimación: que el cliente entregue accesos, que el sistema actual tenga API, que los datos vengan limpios.
Entregables y criterio de aceptación	Qué se entrega y cómo se sabe que quedó bien. Sin esto, «terminado» es una opinión.
Responsabilidades del cliente	Accesos, decisiones, validaciones, contenidos, y en qué plazo. La mayoría de retrasos vienen de aquí.
Manejo de cambios	Todo cambio se cotiza aparte por escrito y puede mover la fecha. Escrito así de literal.
Soporte posterior	Qué entra como garantía, por cuánto tiempo, y qué ya es soporte pago.
Forma de pago	Anticipo y pagos atados a entregables, no a fechas del calendario.

Cómo estimar sin mentirte

1. Parte el trabajo hasta que ninguna pieza pase de una semana. Lo que no puedas partir es lo que no entendiste, y ahí está el riesgo.
2. Estima cada pieza en rango, no en número único. Optimista y pesimista.
3. Suma pruebas, corrección y despliegue como parte del trabajo, no como algo que pasa solo al final.
4. Añade el tiempo de coordinación: reuniones, validaciones, esperar respuestas. En proyectos con clientes ocupados esto es una fracción real del total.
5. No apliques un descuento al total para ganar el negocio. Si tienes que bajar el precio, quita alcance. Un proyecto vendido barato con el mismo alcance se cobra después en calidad o en relación.

Del lado del cliente: cómo leer una cotización

Si estás comprando, desconfía de la cotización que solo trae precio y plazo, por atractiva que sea. Esa es la que se alarga. La que trae exclusiones y supuestos parece más complicada y es la que va a terminar costándote lo que dice.

Y pregunta siempre lo mismo que conviene preguntar en cualquier contrato de tecnología: qué pasa si nos separamos. Quién se queda con el código, con los datos y con los accesos.

Preguntas frecuentes

¿Debo poner el precio por hora en la cotización?

En precio cerrado, no: el cliente compra un resultado, no horas, y exponer la tarifa invita a discutir tu velocidad en vez de tu entregable. En tiempo y materiales, obviamente sí, junto con el tope y la frecuencia de reporte.

¿Cuánto anticipo es razonable pedir?

Lo importante no es el porcentaje sino que los pagos estén atados a entregables verificables. Un esquema de pagos por fecha te obliga a cobrar por tiempo transcurrido; uno por entregable alinea a las dos partes en terminar cosas.

¿Y si el cliente pide «un cambio pequeño»?

Cotízalo, aunque sea en cero. El registro importa más que el cobro: deja constancia de que hubo un cambio y de su impacto en la fecha. Los proyectos no se desbordan por un cambio grande; se desbordan por quince pequeños que nadie contó.

¿Sirve usar IA para estimar?

Para desglosar el trabajo en piezas y para no olvidar partidas, ayuda bastante. Para darte el número, no: no conoce tu equipo, tu velocidad real ni a ese cliente en particular. Úsala para la lista, no para la cifra.

La conclusión, sin rodeos

El precio casi nunca es el problema. Escribe el alcance en verbos, escribe con más cuidado todavía lo que no incluye, cobra el descubrimiento y deja por escrito que todo cambio se cotiza. Con eso, las dos partes terminan el proyecto pensando lo mismo sobre lo que se acordó.