El precio fijo es justo cuando el alcance es claro; el cobro por hora es justo cuando el trabajo es de verdad abierto. Para la mayoría de los proyectos web con un resultado definido — un sitio, un MVP, un portal — el precio fijo contra un alcance escrito te protege, porque conoces el número por adelantado y el riesgo de errar la estimación es mío, no tuyo. Por hora encaja en descubrimiento, cambios continuos o trabajo que nadie puede acotar aún. Ajusta el modelo a la certeza.
¿Cuándo conviene el precio fijo?
Cuando el resultado está definido lo suficiente para acotarlo: un conjunto conocido de páginas, funciones o una v1 clara. Precio fijo significa que apruebas un número antes de empezar y pagas ese número, sin importar cuánto me tome. El riesgo de una mala estimación es mío, que es justo por qué acoto con cuidado primero. Para la mayoría de los builds de cliente este es el default justo — te da certeza de presupuesto y nos alinea en entregar lo acordado. También cambia cómo se toman las decisiones: como el precio está fijo, no hay incentivo para alargar el trabajo, y cada conversación es sobre entregar el resultado acordado en vez de registrar horas. Compras un resultado, no tiempo.
¿Cuándo tiene más sentido por hora?
Cuando el trabajo es de verdad abierto: descubrimiento temprano, iteración continua tras el lanzamiento, o un alcance que obviamente cambiará semana a semana. Por hora es honesto ahí, porque fingir un precio fijo sobre trabajo desconocido solo significa inflar el número. El detalle es que tú cargas el riesgo — el costo sube si el trabajo crece. Uso por hora para mantenimiento e iteración continua, donde la flexibilidad importa más que un total fijo y el alcance está hecho para moverse. La versión honesta del cobro por hora viene con visibilidad: actualizaciones regulares de a dónde fueron las horas y qué sigue, para que "flexible" nunca se vuelva "sin límite" en silencio. Siempre deberías poder ver por qué estás pagando.
¿Cuál es el riesgo oculto en cada uno?
En precio fijo, el riesgo es un alcance vago: si el brief es flojo, o la cotización se infla o las solicitudes de cambio se acumulan como extras. En por hora, el riesgo es un medidor abierto sin techo. Manejo ambos igual — un alcance escrito y claro por adelantado, y un tope o checkpoint en el trabajo por hora para que nunca se dispare en silencio. El modelo no es el problema; un acuerdo poco claro sí. Acierta el alcance y cualquiera puede ser justo. Lo que hay que vigilar en cualquier contrato es cómo se manejan los cambios: un build a precio fijo necesita un proceso de cambios simple y escrito, para que una adición a mitad de proyecto sea una conversación clara sobre alcance y costo, no un sobrecosto silencioso o una pelea incómoda. Acuerden cómo funcionan los cambios antes de necesitarlo.
¿Y un alcance fijo con un modelo híbrido?
La mayoría de los acuerdos sanos son en realidad ambos, en secuencia. Fijas el precio para el build definido — la parte con un resultado claro — y luego pasas a por hora (o un pequeño retainer mensual) para el trabajo abierto que viene tras el lanzamiento: iteración, nuevas funciones, mantenimiento. Así la parte riesgosa y acotada tiene certeza de presupuesto, y la parte de verdad abierta tiene flexibilidad, cada una cotizada como es justo para ella. El error es forzar un modelo en ambas fases — fijar un precio sobre trabajo futuro desconocido significa inflar, y medir por hora un build claramente acotado significa que cargas un riesgo de estimación que no deberías. Usa fijo para lo conocido, por hora para lo desconocido, y di cuál es cuál por adelantado.
¿Cuál es más barato para el cliente?
Normalmente el precio fijo, para trabajo definido — y no porque la tarifa sea menor. Con precio fijo no cargas riesgo de estimación: si el build tarda más de lo esperado, eso es mío, no de tu factura. El cobro por hora puede verse más barato por hora y aun así costar más en total, porque cada cambio, cada decisión lenta y cada subestimación cae en tu cuenta. El precio fijo también obliga la conversación de alcance por adelantado, que es donde se recorta la mayoría del desperdicio. Por hora solo gana en costo cuando el trabajo es de verdad pequeño, o tan abierto que una cotización fija justa tendría que inflarse para cubrir lo desconocido — momento en el que pagarías por una certeza que aún no necesitas.
¿Cómo cotizo un build?
Acoto el resultado primero, luego cotizo casi todos los builds definidos a precio fijo para que sepas el número antes de empezar — así están estructurados mis servicios. El trabajo abierto o posterior al lanzamiento va por hora con un tope claro. De cualquier forma ves el alcance y el precio por escrito antes de que empiece cualquier trabajo, porque las facturas sorpresa son como muere la confianza. La certeza por adelantado es parte de la entrega, no un extra.
Guías de estrategia relacionadas
Mira cómo presupuestar un proyecto de software, cómo escribir un brief de proyecto y freelancer vs agencia vs estudio.
¿Quieres un número claro para tu proyecto? Cuéntame qué estás construyendo — lo acoto y lo cotizo directo.
