Cobrar por sprint en lugar de por hora: cómo funciona en dev freelance
Las horas son una métrica de input, no de valor entregado. El sprint te alinea con lo que el cliente ya entiende.
El modelo de cobro por hora es cómodo para el dev porque traslada el riesgo al cliente: si tarda más, el cliente paga más. Pero ese mismo modelo te castiga cuando mejoras: si haces en 4 horas lo que antes te llevaba 10, cobras menos. Tu eficiencia se convierte en un descuento involuntario.
El sprint resuelve dos problemas a la vez
Un sprint de 2 semanas con scope cerrado y precio fijo cambia la conversación. El cliente sabe qué va a recibir y cuándo. Tú sabes cuánto vas a cobrar y qué tienes que entregar. La conversación deja de ser "¿cuántas horas?" y pasa a ser "¿qué entramos al próximo sprint?".
Ese cambio te empuja a algo importante: scoping. Antes de cada sprint tienes que decir con precisión qué entra. Eso es trabajo del freelance maduro. El junior cobra por hora; el senior cobra por entregable.
Cómo armar el primer sprint con un cliente nuevo
El primer sprint es el de mayor riesgo: todavía no calibraste tu velocidad con ese stack ni con ese cliente. Reglas que funcionan:
- El primer sprint es chico (1-2 semanas) y tiene un entregable concreto y demoable.
- Pagás 50% al arrancar, 50% al cierre del sprint con la demo aprobada.
- El scope se documenta como issues en GitHub/Linear, no como conversación de Slack.
- Si surge algo fuera de scope mid-sprint, va al backlog del próximo sprint — no se hace ad-hoc.
Cuándo NO usar sprint
Proyectos muy chicos (menos de 1 semana) — overhead de scoping no compensa. Proyectos de descubrimiento puro donde el scope todavía no existe — ahí mejor un "discovery contract" de tarifa fija para 1 semana de research. Mantenimiento continuo sin nuevo desarrollo — ahí el retainer mensual le gana al sprint.
Cobrar por sprint no es ganar más por defecto. Es ganar lo mismo con menos fricción de scoping. Y a la larga, eso es lo que separa al freelance ocupado del freelance rentable.