todas las notas
~3 min#process#freelance

Por qué entrego cada semana, no cada mes

La mayoría de los proyectos freelance no fallan por falta de skill. Fallan porque el loop de feedback es muy largo.

Tomé la decisión de entregar todas las semanas hace casi dos años, y desde entonces no falló un proyecto por scope creep o por cliente confundido. No es magia. Es geometría de feedback.

El problema con el ciclo mensual

El default en agencias es entregar un MVP completo después de 4 a 8 semanas. El cliente ve algo recién a mitad del proceso, cuando ya tomaste 30 decisiones que no le consultaste. Las correcciones llegan cuando ya escribiste el código encima de ellas. Y vos cobrás horas que se gastan re-haciendo cosas que no había forma de validar antes.

Qué cambia con sprints semanales

Cada lunes el cliente ve un deploy nuevo. No una demo en vivo, no un Figma, no un Notion: una URL que abre desde el celular en el subte. El viernes le mando un loom de 5 minutos con qué se hizo, qué decisiones quedaron pendientes, y qué necesito que confirme.

  • Los errores se descubren en una semana, no en seis.
  • El cliente percibe el avance — cada lunes hay algo nuevo, así no haya features grandes.
  • Los pivots cuestan poco porque hay poco escrito encima.
  • El presupuesto se respeta mejor: el alcance se ajusta antes de explotar.

Lo que no funciona

Sprints semanales no funcionan si el cliente no puede dar feedback en menos de 48 horas. Eso aparece más en clientes con comités o aprobaciones por mail. En esos casos el sprint pasa a quincenal, pero la regla queda igual: hay un deploy nuevo cada vez, y hay un texto escrito de qué hay que revisar.

La regla más simple que conozco para mantener un proyecto sano es ésta: si pasaron más de 7 días sin que el cliente toque la URL, hay un problema. Lo arreglás antes de seguir escribiendo código.