4 to 6 weeks to production: what a scoped AI sprint looks like

An AI development sprint is a fixed-scope engagement that takes one defined job, lead triage, reporting, reconciliation, from a written brief to a working system live on your own infrastructure, usually in 4 to 6 weeks. That window is not arbitrary. 51% of executives now say their organization moves a generative AI application from idea to production in 3 to 6 months, up from 47% in 2024, according to Google Cloud’s September 2025 study of 3,466 executives across 24 countries. A scoped sprint compresses that further, because the scope and the price are locked in week zero instead of discovered somewhere in month three.

We run our own AI Workforce Sprint at a fixed $9,500, four to six weeks. This is what actually happens inside that window.

Week 0: scoping, before a line of code

The sprint has not started yet, and that is the point. Week 0 is a written brief: the one job to be automated, the systems it touches, who approves the output, and what “done” looks like. That becomes a fixed price and a fixed scope before any build work begins, so the client knows exactly what they are buying before committing a dollar.

This week kills more bad projects than any technical review later does. If the job cannot be described in writing with a clear input and a clear output, it is not ready for a sprint, and building anyway is how six-week projects turn into six-month ones. Scope decided here does not move once the sprint starts. A genuinely new requirement becomes a new order, not a change to this one.

Week 1: infrastructure and the first working slice

Week 1 is plumbing, not features: repository, database, hosting, and API accounts, all created in the client’s name from day one. By the end of the week there is a first vertical slice, one path through the system, working end to end on real data, even if it only handles the simplest case.

The client sees this in week 1, not week 5. A working slice this early surfaces wrong assumptions about the data or the access while there is still time to fix them cheaply. Nothing built after this point is a guess about whether the pieces fit together. They already do, for at least one path.

Week 2: the core logic gets built

Week 2 turns the one working path into the whole job: every input the system will actually see, not just the tidy example from week 0. For a reconciliation job that means every ledger category, not the three that came up during scoping. For a lead-routing job it means every source leads actually arrive from, not just the contact form.

Most of the real thinking happens this week. Judgment calls that could not be pinned down in writing during scoping get resolved against real examples: what counts as a duplicate, what triggers escalation, what gets logged versus flagged for a human. A written brief goes out at the end of the week regardless, short enough to read in one sitting, no call required.

Weeks 3-4: integration and the parts that break

This is where a sprint earns its middle two weeks. The system stops running against a clean sample and starts running against the client’s actual accounts and actual traffic: real API rate limits, real malformed records, real edge cases nobody mentioned in week 0 because nobody remembered them until they showed up.

Access control and logging get built properly here, not bolted on later. Every action the system takes leaves a paper trail, and anything that touches a customer still waits for a human to approve it before it goes out. If something in the original scope turns out bigger than estimated, that gets flagged in writing immediately, not discovered at handover.

Weeks 5-6: hardening and handover

The last stretch is deliberately unglamorous: error handling, monitoring, and documentation written for the client’s team, not for us. A recorded walkthrough replaces the demo call. By the end of week 6 the system is live in production doing the job it was scoped to do, with two weeks of written post-handover support included.

Handover is the actual finish line, not an afterthought. The repository, the database, and the hosting accounts are already in the client’s name, so nothing needs transferring; nothing was ever anywhere else. If the relationship ended the day after handover, the system keeps running.

Why some jobs take four weeks and others take six

The spread is integrations and data, not ambition. A job with one clean data source and no legacy system to reconcile against can close in four weeks. A job touching three systems with inconsistent records, or a client who needs a week to grant access, runs to six. Four out of five enterprises expect their generative AI investments to pay off within two to three years, per Wharton Human-AI Research and GBK Collective’s October 2025 survey of roughly 800 US enterprise decision-makers. A sprint’s job is to get one piece of that return running in weeks, not years, which only holds if the scope matches the client’s actual data instead of an idealized version of it.

Scoped sprint vs. retainer vs. building it in-house

	Scoped fixed-price sprint	Open-ended retainer or consulting	Internal build
Price structure	Fixed price, fixed scope, agreed before work starts	Hourly or monthly, ongoing	Salary: $180,000 to $250,000/yr for one AI/ML hire, before ramp
Timeline to production	4 to 6 weeks	No fixed end date	Months to hire, then ongoing
What a new requirement costs	A new order, priced in writing	More invoiced hours	More of an employee’s time
Ownership at the end	Code, data, and accounts, in your name from day one	Depends on the contract	Full, but the overhead never ends

Only 5% of companies are capturing AI value at scale, and 60% remain laggards who have not moved past pilots, according to BCG’s September 2025 survey of 1,250 executives. The leading group deploys agents in production at nearly three times the rate of the middle group, 33% versus 12%. A defined scope with a defined end date is one of the more reliable ways to end up in the group that ships something instead of the group still discussing it.

What actually goes wrong in a sprint

Over 40% of agentic AI projects will be canceled by the end of 2027, Gartner said in June 2025, citing escalating costs, unclear business value, and inadequate risk controls as the leading causes. All three are scope problems, not model problems: a job that grew after the price was fixed, a build nobody can point to a saved hour from, or an approval step skipped to hit a date.

A fixed scope is the guard against the first two: a new requirement is a new order, priced in writing, not a silent expansion of the original one. The human approval gate on anything customer-facing is the guard against the third. We wrote about the deeper version of this failure pattern, the operations gap that kills most pilots before they ship, in why your AI pilot died. The other place scope goes wrong is picking the wrong build type entirely, which we cover in AI agent vs. automation: a sprint scoped for an agent when the job only needed a script runs long and costs more than it should.

We hold ourselves to the same discipline before we ever quote a client. Our ad-spend truth build started as exactly this kind of scoped job, run on our own company first: the ad platform reported a 4.87x return, the ledger told a different story, and the fix was a defined reconciliation system built in a sprint of its own, not a bigger model.

Describe the one job you want off your plate and you get a written scope back within one business day: what it costs, what it takes six weeks or four, and what you own at the end. No discovery call, no meetings, just the plan. Start async.