Por qué cobramos por sprint, no por hora
Tres modelos de pricing. Un único resultado que importa. Veamos los incentivos.
Por hora
La facturación por hora te paga por gastar horas. Cada hora es ingreso. El developer lento gana lo mismo por hora que el rápido — y a lo largo del proyecto, el lento gana más. Peor, el cliente paga por el tiempo de pensar, debugar, aprender, estar en reuniones. La mayor parte del cual no debería subsidiar.
Precio fijo
Precio por proyecto invierte el problema: ahora el estudio quiere entregar lo más rápido posible, aunque la calidad sufra. Lo primero que cae son los tests. Lo segundo la documentación. Lo tercero las partes que el cliente no pidió explícitamente pero necesitaba.
Los dos modelos ponen a cliente y estudio en lados opuestos de la mesa.
Sprint
Vendemos sprints de dos semanas a una tarifa fija de equipo senior. Cada sprint, el cliente recibe: un scope acordado a la entrada, una entrega a la salida, y una retro escrita que lista lo que queremos hacer el próximo sprint y lo que cortaríamos.
Al final de cada sprint, el cliente puede parar. Marcharse. Llevarse lo que construimos, el código, la marca, las entregas. No trancamos nada.
Por qué funciona
Dos razones. Primera, el cliente ve velocidad semanalmente. Sabe por qué está pagando. Segunda, nuestro incentivo es entregar limpio lo suficiente para que el siguiente sprint vaya más rápido — no estirar trabajo por ingreso.
El modelo también nos fuerza a hacer scope sin compasión. Un sprint de dos semanas no esconde un build de seis semanas. Decimos no al scope creep en la reunión de planificación, no en la fecha tope.
La parte honesta
Esto no es correcto para todo el mundo. Clientes que quieren precio fijo para algo totalmente especificado — los mandamos a una agencia de precio fijo. Clientes que quieren developers contratados por hora — lo mismo. Trabajamos con founders que quieren entregar algo cada dos semanas y confían en el proceso. Forma distinta.
Preguntas frecuentes
¿Cómo funciona el modelo de precio por sprint?
Vendemos sprints de dos semanas a una tarifa fija de equipo sénior. Cada sprint recibe un alcance acordado de entrada y produce un entregable puesto en producción, más una retrospectiva escrita sobre lo que viene después y lo que recortaríamos.
¿Por qué cobrar por sprint es mejor que cobrar por hora?
La facturación por hora paga al estudio por dedicar horas, así que un desarrollo lento gana más y el cliente paga el tiempo de pensar, depurar, aprender y reunirse. Una tarifa fija por sprint elimina ese incentivo, ya que nuestro objetivo pasa a ser entregar de forma limpia para que el siguiente sprint vaya más rápido.
¿Qué problema tiene un contrato de precio cerrado?
El precio cerrado empuja al estudio a entregar rápido aunque la calidad sufra, por lo que lo primero en caer son las pruebas, luego la documentación, y luego las partes que el cliente necesitaba pero no pidió explícitamente. Igual que por hora, pone al cliente y al estudio en lados opuestos.
¿Quedo atado si quiero parar?
No. Al final de cada sprint puedes parar e irte con el código, la marca y los entregables, sin nada bloqueado.
¿El modelo por sprint sirve para todos?
No. Quien quiere un precio fijo para algo totalmente especificado está mejor con una agencia de precio cerrado, y quien busca desarrolladores por hora debe ir a otro lado. Trabajamos con founders que entregan algo cada dos semanas y confían en el proceso.