Un AI Sprint es un compromiso de alcance fijo y precio fijo: de 5 a 10 días de trabajo de ingeniería que entrega un prototipo funcional y desplegable impulsado por IA. Existe porque la mayoría de las empresas necesita probar una idea antes de comprometerse con un proyecto completo — y "agendemos una llamada de discovery" no responde esa pregunta con suficiente rapidez.
El formato es simple. Entras con una idea, un problema, o un flujo de trabajo que quieres automatizar. Definimos el alcance el primer día, construimos con Claude Code y herramientas modernas (Lovable, Supabase, Vercel), y al final te entregamos una URL funcional y el código fuente. Sin demos vacías. Sin presentaciones explicando lo que podríamos construir. Algo que corre.
Un sprint no es un ejercicio de discovery. Está suficientemente listo para producción como para probarlo con usuarios reales — típicamente los primeros 50 a 200 — aunque no necesariamente listo para escalar a miles. En concreto, produce:
El formato de sprint funciona bien en situaciones específicas. Si te reconoces en más de dos de estas, vale la pena conversarlo:
El formato de sprint tiene limitaciones reales. Ser honestos al respecto es más útil que venderlo como solución universal.
Si la funcionalidad de IA necesita leer de un ERP de 20 años sin API documentada, el trabajo de integración solo ya excederá el tiempo del sprint. El sprint funciona mejor con fuentes de datos modernas y accesibles. Las integraciones con sistemas legacy complejos requieren otro modelo de engagement.
Healthcare y servicios financieros son un fit parcial. Un sprint puede producir algo, pero lo que produce necesitará refuerzo significativo antes de tocar datos reales de pacientes o información financiera. Si tu equipo de compliance necesita aprobar la arquitectura antes de escribir una sola línea de código, el timeline del sprint no encaja.
"Queremos hacer algo con IA" no es un brief para un sprint. El sprint necesita un problema específico, un usuario específico y una hipótesis específica. El trabajo de discovery viene antes del sprint, no durante. Si aún no tienes esa claridad, el sprint no es el primer paso correcto.
Un sprint es el comienzo, no el final. El resultado es un prototipo testeable, no un producto escalable. Si ya sabes que necesitas un equipo de ingeniería completo por 12 meses, comienza con esa conversación.
El código te pertenece. Puedes entregárselo a tu equipo interno con el documento de arquitectura como punto de partida, continuar construyendo con Axented en la siguiente fase, o mostrarle a usuarios, descubrir que la hipótesis estaba equivocada y ajustar — habiendo gastado de $5K a $10K en lugar de $150K para llegar a esa conclusión.
El documento de arquitectura que entregamos no es un formalismo. Describe cada decisión no obvia — por qué usamos Supabase en lugar de un backend personalizado, por qué el prompt está estructurado de la manera en que está, dónde aparecerán las principales limitaciones de escala. Está escrito para el ingeniero que mantendrá el código seis meses después, no para el stakeholder que quiere un resumen ejecutivo.
%20(1)-2.svg)
