Desarrollo de software a precio fijo: qué es y cuándo tiene sentido
Cuando una empresa busca desarrollar software, la primera pregunta suele ser el precio. Y la segunda, cómo saber si ese precio va a mantenerse. El modelo de precio fijo existe para responder esa segunda pregunta. El problema es que muchos proyectos que empiezan como precio fijo terminan siendo otra cosa.
Este artículo explica qué es realmente un contrato de software a precio fijo, cuándo tiene sentido usarlo, cuándo es una mala idea, y qué necesitas tener definido antes de firmar. Sin teoría de libro: lo que hemos visto en proyectos reales.
Qué es el desarrollo de software a precio fijo
En un contrato de precio fijo, el proveedor se compromete a entregar un alcance definido por un precio acordado, con independencia del tiempo real que tarde. El riesgo de desvío de horas lo asume el proveedor, no el cliente.
Esto lo diferencia de las otras dos modalidades principales:
- Time & Material (T&M): el cliente paga por horas o días de trabajo. El alcance puede ajustarse en el camino, pero el precio final es variable.
- Retainer: el cliente contrata una capacidad mensual fija. No hay un proyecto con fecha de fin, sino un equipo disponible de forma continua.
En precio fijo, el proveedor hace una estimación, le añade un margen de riesgo de entre el 15% y el 25%, y eso es lo que cotiza. Si el proyecto tarda menos de lo estimado, el proveedor gana más margen. Si tarda más, lo absorbe él.
Ventajas reales del precio fijo
El argumento principal es previsibilidad financiera. El cliente sabe exactamente cuánto va a gastar antes de que empiece el proyecto. Para empresas con presupuestos aprobados por junta, con inversión de riesgo acotada o con necesidad de presentar un ROI claro, eso tiene valor real.
Otras ventajas concretas:
- El riesgo de estimación es del proveedor. Si el equipo subestimó la complejidad, el cliente no paga el diferencial.
- Incentivo para eficiencia. El proveedor tiene motivación para entregar bien y rápido, porque cada hora extra sale de su margen.
- Deadline claro. La mayoría de contratos de precio fijo incluyen una fecha de entrega, lo que facilita la planificación del lado del cliente.
- Menos gestión diaria. El cliente no necesita controlar horas ni aprobar cada tarea. Supervisa el resultado, no el proceso.
Cuándo el precio fijo no funciona
La mayoría de proyectos que fracasan en precio fijo no fallan por el proveedor ni por el cliente: fallan porque el alcance nunca estuvo suficientemente definido para justificar un precio fijo. La señal más clara es el cliente que dice "es algo sencillo, básicamente..." sin ningún documento escrito.
Si el cliente describe el proyecto con una frase y el proveedor da un precio sin documentación, ninguno de los dos sabe realmente qué se está comprando ni qué se está vendiendo.
Situaciones concretas donde el precio fijo es una mala idea:
- Producto en fase de descubrimiento. Si todavía estás validando qué construir, el alcance va a cambiar. Precio fijo sobre un alcance que todavía no sabes es una garantía de conflicto.
- Requisitos al 40-50% de definición. La mayoría de proyectos fallidos en precio fijo llegan a la firma con los requisitos a la mitad. Lo que parece "suficientemente claro" en una reunión tiene ambigüedades enormes cuando el developer empieza a construir.
- Producto con muchas integraciones externas desconocidas. Cada integración con un sistema externo es una fuente de imprevistos. Si no conoces bien las APIs con las que vas a trabajar, el precio fijo tiene un riesgo oculto grande.
- Equipo del cliente sin disponibilidad para dar feedback. El precio fijo requiere validaciones frecuentes. Si el cliente desaparece dos semanas y luego pide cambios, el contrato se complica.
También hay un riesgo de deuda técnica en proyectos de precio fijo: el proveedor, bajo presión de márgenes, puede tomar atajos en calidad de código que el cliente no ve en la entrega pero paga durante años de mantenimiento.
Qué necesitas tener claro antes de firmar
Para que un contrato de precio fijo funcione, el alcance tiene que estar definido con suficiente precisión. No perfecto, pero sí lo bastante detallado para que ambas partes entiendan lo mismo cuando leen el documento.
Requisitos documentados
Como mínimo: casos de uso o user stories con criterios de aceptación, wireframes o mockups de las pantallas principales, y una descripción de las integraciones con sistemas externos. Sin esto, cualquier estimación es una conjetura.
Criterios de aceptación
¿Cómo sabes que una funcionalidad está terminada? Los criterios de aceptación definen exactamente eso. Son la referencia objetiva para resolver disputas. Si no existen, "está terminado" significa cosas diferentes para el cliente y para el proveedor.
Proceso de gestión de cambios
Todo proyecto tiene cambios. La diferencia entre un precio fijo bien estructurado y uno que termina en conflicto es si hay un proceso claro para gestionarlos. Cada cambio de alcance debe formalizarse por escrito con el impacto en tiempo y costo antes de ejecutarse. Si el proveedor acepta cambios verbalmente, el contrato se vacía de sentido.
Lista explícita de exclusiones
Tan importante como lo que está incluido es documentar lo que queda fuera del alcance. "Sistema de notificaciones" puede significar un email automático o puede significar push notifications, SMS y webhooks. Definir las exclusiones evita el clásico "yo pensé que eso estaba incluido".
Precio fijo vs. Time & Material vs. Retainer
| Criterio | Precio fijo | Time & Material | Retainer |
|---|---|---|---|
| Presupuesto predecible | Sí | No | Parcial |
| Flexibilidad de alcance | Baja | Alta | Alta |
| Riesgo de desvío de costo | Del proveedor | Del cliente | Compartido |
| Requiere alcance definido | Sí (>80%) | No | No |
| Ideal para | Proyectos acotados | Productos en evolución | Equipos continuos |
El precio fijo no es mejor ni peor que T&M. Es adecuado para proyectos con alcance estable y mala opción para productos en evolución continua. El error más común es elegir precio fijo porque "da más seguridad" cuando el alcance no está realmente definido. En ese caso, la seguridad es ilusoria.
El modelo BeC para proyectos de precio fijo
En BeC trabajamos con precio fijo cuando el alcance lo justifica. Antes de dar cualquier estimación, hacemos una sesión de definición de alcance donde revisamos los requisitos, identificamos ambigüedades y acordamos los criterios de aceptación. Si el resultado de esa sesión es que el alcance no está maduro para precio fijo, lo decimos.
Los proyectos de precio fijo que hacemos incluyen siempre un proceso formal de change request. Los cambios son bienvenidos, pero se cotizan y aprueban por escrito antes de ejecutarse. Eso protege al cliente de sorpresas y nos protege a nosotros de trabajar gratis.
El artículo sobre por qué los proyectos de software se retrasan entra en más detalle sobre los factores que hacen fallar un proyecto, independientemente del modelo de contratación.
Si tu proyecto tiene requerimientos documentados y un scope claro, el precio fijo puede funcionar bien. Si todavía estás descubriendo qué construir, hablemos primero de eso: contacta con nosotros.
Preguntas frecuentes
¿Cuándo conviene precio fijo en vez de Time & Material?
El precio fijo funciona cuando el alcance está definido al menos en un 80% antes de empezar: requisitos documentados, criterios de aceptación claros y pocos cambios esperados. Si el alcance es difuso o el producto está en fase de descubrimiento, T&M es más adecuado para ambas partes.
¿Qué pasa si el alcance cambia en un contrato de precio fijo?
Cualquier cambio de alcance debe formalizarse por escrito con impacto en tiempo y costo antes de ejecutarse. Los contratos bien estructurados incluyen un proceso de change request explícito. Si el proveedor acepta cambios sin documentarlos, el proyecto se convierte en T&M encubierto sin las protecciones del cliente.
¿El precio fijo es más barato que Time & Material?
No necesariamente. El proveedor incluye un margen de riesgo del 15-25% sobre su estimación base. Si el proyecto sale sin desvíos, el cliente puede pagar un poco más que con T&M. La ventaja no es el precio: es la previsibilidad. Sabes cuánto gastas antes de empezar.
¿Cómo documentar requisitos para un proyecto de precio fijo?
Mínimo necesario: casos de uso o user stories con criterios de aceptación, wireframes de las pantallas principales, descripción de integraciones con sistemas externos y una lista de exclusiones de alcance. Sin esta base, cualquier estimación de precio fijo es una apuesta para ambas partes.