La mayoría de las agencias de tecnología en México y LatAm cobran por hora. Es el modelo heredado de las firmas de consultoría de los 90: registras tiempo, facturas tiempo, el cliente paga tiempo. El problema es que ese modelo optimiza el tiempo registrado, no el resultado obtenido.
En Eurema decidimos no usarlo. Esta es la explicación sin adornos de por qué, y qué implica para ti como cliente.
El problema estructural del modelo por horas
Cuando una agencia cobra por hora, sus ingresos crecen si el proyecto dura más. No hay mala fe en eso — es la lógica del sistema. Pero genera una fricción silenciosa: cada decisión de diseño que alarga el proyecto es, en términos financieros, una decisión neutra o positiva para la agencia. Para ti es una pérdida.
El modelo por horas también produce una asimetría de información difícil de resolver. Tú no sabes cuántas horas debería tomar construir un agente de calificación de leads. La agencia sí. Esa diferencia de conocimiento, combinada con un incentivo financiero de alargar, crea condiciones para que el proyecto se estire aunque nadie lo planee explícitamente.
Un proyecto que debería tomar 6 semanas puede tomar 14 sin que nadie haya mentido, solo porque el modelo lo permite.
Cómo funciona cobrar por implementación
El modelo que usamos en Eurema parte de una pregunta diferente: ¿cuál es el estado final verificable que el cliente necesita?
No “cuántas horas de desarrollo”, sino: ¿qué queda funcionando cuando terminamos? Eso define el entregable. El precio se fija sobre ese entregable antes de empezar. Si el alcance cambia — porque el cliente agrega funcionalidades o cambia la dirección — se renegocia el precio antes de ejecutar el cambio, no después.
Esto tiene consecuencias concretas:
- El riesgo de estimación es nuestro. Si calculamos mal las horas internas, eso no aparece en tu factura.
- El incentivo está alineado. Terminamos más rápido y bien → liberamos capacidad para el siguiente proyecto. No hay razón financiera para alargar.
- El alcance es explícito desde el día uno. No hay zona gris de “horas adicionales por ajustes”.
Lo que esto exige de ambos lados
El modelo por entregable no es más fácil — es más exigente en la fase de definición.
Antes de cotizar, necesitamos entender con precisión qué queda activo al final: ¿el agente responde en WhatsApp o solo en web? ¿El dashboard actualiza en tiempo real o con delay de 24 horas? ¿La integración incluye el ERP actual o solo el CRM? Cada una de esas preguntas cambia el precio, y es mejor resolverlas antes de firmar que después de tres semanas de desarrollo.
Lo que vemos en Eurema con empresas que vienen de trabajar con agencias por horas es que suelen llegar sin haber tenido esas conversaciones. El brief es vago porque nadie los obligó a precisarlo — las horas se cobran igual. Parte de nuestro proceso inicial es forzar esa precisión, y a veces incomoda, pero evita sorpresas más costosas después.
Por qué esto importa especialmente en proyectos de IA
Los proyectos de IA tienen una característica que los hace particularmente peligrosos bajo el modelo por horas: la experimentación es cara y no siempre produce resultado utilizable.
Un agente de IA puede requerir 10 iteraciones de prompt antes de que el comportamiento sea aceptable. Un modelo predictivo puede necesitar tres versiones del pipeline de datos antes de que las métricas sean confiables. Bajo el modelo por horas, cada iteración fallida es tiempo facturable. El cliente paga el proceso de aprendizaje de la agencia.
El criterio que usamos en Eurema para definir si un proyecto entra en nuestro modelo es simple: ¿podemos describir el estado final con criterios verificables antes de empezar? Si no podemos, hay trabajo de discovery previo que sí puede tener un componente de tiempo — pero acotado, con entregable propio (un documento de alcance, una prueba de concepto), no como apertura a facturación indefinida.
Para proyectos donde el entregable es claro — un agente personalizado que califica leads según criterios definidos, o un sitio con Websites + AI SEO optimizado para motores de respuesta — el modelo por implementación funciona sin ambigüedad.
Lo que no resuelve este modelo
Ser honesto implica decir también qué no cubre.
El modelo por entregable no es adecuado para trabajo de soporte continuo o mantenimiento evolutivo donde el volumen de cambios es impredecible. Para esos casos usamos retainers con alcance mensual definido — que es una variante del mismo principio: alcance claro, precio fijo, no horas abiertas.
Tampoco resuelve el problema si el cliente no sabe lo que quiere. Si llegas con “quiero algo de IA para mi operación” sin más contexto, el primer paso es un proceso de diagnóstico con su propio entregable y precio. No se puede cotizar lo que no está definido.
El modelo por implementación es más transparente, pero requiere que ambas partes hagan el trabajo de definición antes de firmar. Si eso te parece excesivo, probablemente el modelo por horas sea más cómodo a corto plazo — y más caro a largo plazo.
Si estás evaluando un proyecto de IA y quieres entender qué entregable concreto tendría sentido para tu operación, ese es exactamente el tipo de conversación que tiene sentido tener antes de cualquier propuesta.