Por qué tu freelance debería darte precio cerrado, no por horas (y cómo conseguirlo)

Cuando contratas a un freelance por horas, le pagas por tardar más. Eso es la cuenta. Cada hora extra que se eche en tu proyecto son más euros en su bolsillo. Hasta los devs éticos sienten ese tirón de manera subconsciente — y los no-éticos lo ordeñan a propósito.

El precio cerrado le da la vuelta al incentivo. Una vez fijado el precio, el incentivo del dev es entregar rápido y bien, porque cualquier otra cosa le come margen.

Aun así, el 80% de contratos freelance todavía pasan por horas. Por qué, y cómo salir de esa trampa.

Por qué pasa lo de las horas (y por qué es mala señal)

Los contratos por horas siguen vivos por tres razones:

1. El cliente no sabe qué quiere. Si no puedes escribir un brief claro, el dev no puede dar precio cerrado. Se protege saltando a horas.
2. El dev no sabe estimar. Los juniors y los que se acaban de meter en un stack nuevo honestamente no pueden predecir tiempos. Las horas son su red.
3. El dev lo prefiere. Las horas esconden trabajo lento. Los seniors que insisten en horas cuando el alcance es claro suelen tener una razón — y no es a tu favor.

Si has escrito un brief sólido y el dev todavía no te quiere dar precio cerrado, es bandera amarilla. ¿Dos briefs sólidos seguidos que dan presupuestos por horas? Lárgate.

Qué necesita un dev de ti para darte precio cerrado

La mayoría de negociaciones que fracasan acaban siendo culpa del brief, no del dev. Mándale esto antes de la llamada inicial:

1. La métrica de éxito (una frase)

No “quiero una web mejor”. No “quiero que se registren usuarios”. Prueba: “Quiero que la conversión de signup en /pricing pase de 1.2% a 2.5% en los 60 días siguientes al launch.”

Un objetivo medible, con plazo, de un solo número es la base de cada presupuesto cerrado. Sin eso, el alcance se va en cuanto el dev piensa “pero igual querían…“.

2. Las restricciones duras

• Stack tecnológico obligado (o dispuesto a cambiar).
• Browsers / dispositivos que tienes que soportar (¿IE11 para un contrato gobierno coreano? Dilo).
• Compliance: GDPR, SOC 2, HIPAA, PCI-DSS.
• Deadline: duro o blando, y por qué.
• Presupuesto: la banda, no el techo.

No escondas el presupuesto. Un buen dev diseña el alcance para que encaje; uno malo te infla el quote hasta donde crea que pagas.

3. La separación “must” vs “nice to have”

Por cada feature que quieras, marca M o N. Una buena regla: menos del 50% de items deben ser M. Si todo es M, tu alcance es demasiado grande para precio cerrado.

Cuando escribes el brief, la lista M se vuelve el contrato. La N pasa a “fase 2” o se cae si la M se come el presupuesto.

4. El mapa del código existente

Si tienes codebase ya, lista:

• Los lenguajes y frameworks
• Dónde está el código (¿GitHub privado? ¿Bitbucket? “En mi portátil viejo”?)
• Quién más ha tocado recientemente
• Qué está roto ahora

Nada hace explotar un presupuesto cerrado más rápido que descubrir en el día 3 que el código existente es un WordPress lleno de 47 plugins custom.

Qué te debería dar el dev a cambio

Un presupuesto cerrado decente lleva seis cosas. Si falta cualquiera, retrocede.

1. Items por línea. No “Build the app — 5.000 €”. Un presupuesto real desglosa por workstream para que negocies o recortes.
2. Timeline con milestones. No “4 semanas”. Prueba: “Semana 1: setup + auth listo. Semana 2: dashboard. Semana 3: pagos. Semana 4: QA + launch.”
3. Lista explícita de out-of-scope. Lo que NO está incluido. Es la protección del dev contra creep, y la tuya contra asumir cosas que no pagaste.
4. Proceso de change-request. “Cualquier cosa fuera de la M se gestiona como change-request, presupuestada aparte.” La válvula de seguridad explícita para los dos.
5. Términos de pago. Habitual: 30% al firmar, 30% en milestone 2, 40% en entrega. Algunos prefieren 50/50. Cualquiera que pida 100% por adelantado a un freelance que no conoces es estafa.
6. Fecha de fin del soporte. Lo más razonable: 30 días de bugfixes gratis post-launch, luego retainer o por intervención.

Cuatro banderas rojas del presupuesto

1. Sin items por línea. Solo un número. No puedes negociar lo que no ves.
2. Sin out-of-scope. Significa que todo lo que pidas se vuelve “sí pero más dinero”.
3. Buffer de project management de más del 20%. Te están metiendo padding porque no confían en su propia estimación.
4. Sin milestones de pago. Te piden 100% por adelantado o 100% a entrega. Ambos extremos son red flags por lados opuestos.

Cómo lo hago yo

Mando presupuesto cerrado en las 48h siguientes a la llamada inicial. El quote lleva items por línea, timeline con milestones, lista explícita de out-of-scope, proceso de change-request y pagos 30/30/40. El primer 30% se vuelve no reembolsable el día 1; el resto es reembolsable hasta que cada milestone se firme.

Y ya. Sin trampa de horas. Sin facturas sorpresa.

Si ese es el tipo de contrato que quieres, mándame un brief y mañana tienes presupuesto en el inbox.