Desarrollo por hora, precio fijo o equipo mensual: qué modelo elegir

Cuando una empresa decide desarrollar software, la primera conversación suele girar alrededor de qué se va a construir y cuánto va a costar. Pero hay una decisión anterior que condiciona ambas respuestas: bajo qué modelo de contratación se va a trabajar.

Los tres modelos más comunes —pago por hora, precio fijo y equipo mensual— no son intercambiables. Cada uno tiene sentido en un contexto distinto, y elegir el equivocado puede generar problemas que van desde sobrecostos hasta productos que no resuelven lo que debían resolver.

Este artículo explica cómo funciona cada modelo, en qué situaciones conviene y —tan importante como lo anterior— en qué situaciones conviene evitarlo. El objetivo no es decir cuál es mejor en abstracto, sino darte criterios para decidir cuál se ajusta mejor a tu proyecto concreto.

Pago por hora

En este modelo, el proveedor factura por las horas efectivamente trabajadas, a una tarifa acordada previamente. El cliente paga por el tiempo invertido, no por un resultado definido de antemano.

Cómo funciona en la práctica. Se acuerda una tarifa horaria —por perfil o por equipo— y el proveedor registra las horas trabajadas. Cada semana o cada mes, el cliente recibe un detalle de las horas consumidas y paga en función de ese consumo. El alcance del proyecto puede ajustarse sobre la marcha: si aparece una necesidad nueva, se suma; si algo deja de ser prioritario, se pospone.

Cuándo conviene.

• Cuando el alcance del proyecto no está completamente definido al inicio y se espera que evolucione durante el desarrollo. Es el caso típico de productos nuevos, MVPs o proyectos donde el feedback de los usuarios va a cambiar las prioridades.
• Cuando el proyecto es de largo plazo y la relación con el proveedor se basa en la confianza y la continuidad. El cliente valora la flexibilidad por sobre la predictibilidad del costo total.
• Cuando la empresa tiene una persona interna —un CTO, un líder técnico, un product manager— que puede priorizar, validar y tomar decisiones sobre la marcha sin depender de que cada cambio pase por una renegociación de contrato.

Cuándo NO conviene.

• Cuando el presupuesto total tiene un techo fijo y no hay margen para absorber variaciones. El pago por hora es inherentemente variable: si el proyecto toma más tiempo del estimado, el costo final supera lo previsto.
• Cuando el cliente no tiene forma de validar que las horas facturadas corresponden a trabajo efectivo. Si no hay alguien del lado del cliente que pueda evaluar el ritmo de avance, el modelo por hora puede generar desconfianza en ambas direcciones.
• Cuando el proyecto tiene un alcance acotado y muy definido. Si se sabe exactamente qué hay que construir, el precio fijo suele ser más eficiente para el cliente porque transfiere el riesgo de estimación al proveedor.

El riesgo principal. El incentivo del proveedor es maximizar las horas facturadas, no minimizar el tiempo de desarrollo. Un proveedor serio no va a inflar horas —su reputación depende de la eficiencia—, pero el modelo no lo premia por terminar antes. La mitigación pasa por tener hitos medibles, revisiones frecuentes y una relación de confianza construida sobre resultados visibles, no sobre reportes de horas.

Precio fijo

En este modelo, el proveedor se compromete a entregar un alcance definido por un precio acordado de antemano. Si el proyecto toma más tiempo del estimado, el proveedor asume el costo adicional. Si toma menos, el proveedor se beneficia de su propia eficiencia.

Cómo funciona en la práctica. El cliente define —idealmente con ayuda del proveedor— un alcance detallado: qué funcionalidades incluye, qué queda fuera, qué criterios definen que el proyecto está terminado. El proveedor estima el esfuerzo y propone un precio total. Ambas partes firman un contrato que especifica el alcance, el precio, los plazos y las condiciones de aceptación.

Cuándo conviene.

• Cuando el alcance está muy definido y es poco probable que cambie durante el desarrollo. Proyectos como el desarrollo de un sitio web institucional, una integración entre dos sistemas existentes o la migración de datos de una plataforma a otra suelen tener alcances estables.
• Cuando el cliente necesita certeza sobre el costo total antes de aprobar el proyecto. Si la decisión de invertir depende de saber exactamente cuánto va a costar, el precio fijo da esa certeza.
• Cuando el plazo de entrega es una restricción fuerte —por ejemplo, un evento, una fecha regulatoria, una ventana de mercado— y el cliente necesita un compromiso firme sobre la fecha de finalización.

Cuándo NO conviene.

• Cuando el alcance es incierto o se sabe que va a cambiar. Un proyecto de precio fijo con cambios frecuentes de alcance se convierte en una negociación constante sobre qué estaba incluido y qué no, lo que erosiona la relación y demora el proyecto más que si se hubiera elegido otro modelo desde el inicio.
• Cuando el proyecto es de largo plazo —seis meses o más— y el contexto de negocio puede cambiar. Lo que hoy parece el alcance correcto puede dejar de serlo en tres meses si el mercado, la competencia o las prioridades de la empresa cambiaron.
• Cuando el cliente no tiene la capacidad de definir el alcance con el nivel de detalle que un precio fijo requiere. Si el proveedor tiene que adivinar qué quiere el cliente, el precio fijo es una apuesta para ambas partes.

El riesgo principal. El incentivo del proveedor es minimizar el esfuerzo para maximizar su margen. Si el alcance no está definido con precisión, el proveedor puede interpretar los vacíos a su favor —entregar lo mínimo que cumple con la letra del contrato, no con el espíritu de lo que el cliente necesita—. La mitigación pasa por un alcance detallado, criterios de aceptación claros y un proceso de revisión durante el desarrollo, no solo al final.

Equipo mensual

En este modelo, el cliente contrata un equipo dedicado —desarrolladores, diseñadores, líder técnico— por un monto fijo mensual. El equipo trabaja de manera exclusiva o semi-exclusiva para el cliente durante el período contratado, con un alcance que se define y se ajusta de manera continua.

Cómo funciona en la práctica. Se acuerda la composición del equipo —cuántas personas, con qué perfiles, con qué dedicación— y un monto mensual fijo. El equipo trabaja en las prioridades que el cliente define, con reuniones frecuentes de planificación y revisión. El alcance no está fijo al inicio: se define semana a semana o mes a mes según las necesidades del negocio.

Cuándo conviene.

• Cuando el proyecto es continuo y no tiene un final definido. Es el caso de empresas que están construyendo y evolucionando un producto digital de manera permanente: una plataforma SaaS, un marketplace, una aplicación que se actualiza constantemente.
• Cuando la velocidad de iteración es crítica y el cliente necesita poder cambiar de dirección rápido sin renegociar contratos. El equipo ya está asignado: lo que cambia es en qué trabaja.
• Cuando el cliente no tiene —o no quiere tener— un equipo interno de desarrollo, pero necesita la continuidad y el conocimiento de negocio que un equipo dedicado acumula con el tiempo. A diferencia del pago por hora, donde el equipo puede rotar entre proyectos, el equipo mensual tiende a ser estable.

Cuándo NO conviene.

• Cuando el proyecto es puntual y tiene un principio y un final claros. Mantener un equipo mensual para un proyecto de tres meses que después no va a requerir desarrollo continuo es ineficiente: el precio fijo o el pago por hora se ajustan mejor a proyectos acotados.
• Cuando el presupuesto mensual del cliente no puede sostener el costo de un equipo completo. Un equipo mensual típico incluye al menos dos o tres personas —desarrollador, diseñador, líder— y el costo mensual refleja esa dedicación.
• Cuando el cliente no tiene la capacidad de gestionar las prioridades del equipo. Un equipo mensual requiere que alguien del lado del cliente —o un líder técnico del lado del proveedor— defina qué se hace cada semana, valide lo construido y tome decisiones. Sin esa gestión, el equipo produce, pero no necesariamente lo que el negocio necesita en ese momento.

El riesgo principal. El equipo puede convertirse en un costo fijo que la empresa paga por inercia, sin evaluar periódicamente si el retorno justifica la inversión. La mitigación pasa por definir objetivos trimestrales medibles y revisar si el equipo los está alcanzando. Si después de dos trimestres el equipo no está generando el valor esperado, el problema puede estar en la composición del equipo, en las prioridades que se le asignan o en que el modelo mensual no es el adecuado para ese momento del proyecto.

Cómo decidir entre los tres modelos

La decisión no depende de cuál modelo es objetivamente mejor, sino de tres variables del proyecto:

1. Nivel de certeza del alcance. Si sabés exactamente qué hay que construir —un veinticinco por ciento de incertidumbre o menos—, el precio fijo es eficiente. Si el alcance va a evolucionar con el feedback de los usuarios —más de un cincuenta por ciento de incertidumbre—, el pago por hora o el equipo mensual permiten adaptarse sin fricción contractual. Si el alcance va a cambiar de manera continua porque el producto está en evolución permanente, el equipo mensual es la opción más natural.

2. Duración y continuidad del proyecto. Para proyectos de menos de tres meses con un alcance definido, el precio fijo suele ser la mejor opción. Para proyectos de tres a seis meses con incertidumbre moderada, el pago por hora ofrece flexibilidad sin el compromiso de un equipo mensual. Para proyectos de más de seis meses que requieren desarrollo continuo, el equipo mensual genera eficiencias por conocimiento acumulado y reduce la fricción de estar renegociando alcances cada mes.

3. Capacidad de gestión del cliente. Si el cliente tiene alguien que puede priorizar, validar y tomar decisiones técnicas —o está dispuesto a pagar por ese rol dentro del equipo—, el pago por hora y el equipo mensual funcionan bien. Si el cliente no tiene esa capacidad y necesita que el proveedor se haga cargo de la gestión completa, el precio fijo —con un alcance muy bien definido— es la opción que genera menos fricción.

No hay un modelo superior a los otros. Hay un modelo más adecuado para el proyecto que tenés, la etapa en la que está tu empresa y la capacidad de gestión que podés dedicarle. Elegir bien el modelo no garantiza el éxito del proyecto, pero elegir mal lo hace más caro y más difícil de lo necesario.

Si querés profundizar en la diferencia entre presupuesto cerrado y cobro por horas —los dos extremos del espectro—, el artículo sobre presupuesto cerrado versus cobro por horas analiza el trade-off entre certeza y flexibilidad. Y si estás en la etapa de estimar cuánto va a costar un proyecto, revisá cómo estimar el costo real de un proyecto de software para anticipar variables que suelen quedar fuera de la cotización inicial.

Más contenido sobre planificación financiera en la categoría de costos y presupuestos.