What a custom AI build looks like, week by week

The question behind the question, when someone asks how long a custom AI build takes, is usually: what will actually happen after we sign, and how will we know it is going well? So instead of a number, here is the week-by-week anatomy of a build that is going well — and the signals of one that is not. Our own delivery target at Xwits is four to eight weeks; the structure below is why that is possible, not a boast.

Week 0: scoping — days, not weeks

Before any contract: one or two working sessions where the vendor understands the task, looks at your actual data, and asks uncomfortable questions about edge cases. The output is a short scope document — the problem, the definition of done, what is explicitly out of scope, and a fixed quote.

Note what this is not: a paid, multi-week discovery phase producing a strategy deck. Published guides note that discovery quality drives rework more than any other factor, and that is true — but discovery is a property of how the build runs, not a separate billable product. If understanding your problem takes a vendor six weeks, the problem is the vendor. We covered the vendor-side signals in how to choose an AI development company.

What you do this week: bring the people who live the workflow daily, not just the ones who bought the software. One hour with the person who actually processes the invoices is worth five with anyone else.

Weeks 1-2: access, then a working slice

The first days go to plumbing: access to your data, your systems, and a safe environment to build in. Then the vendor builds a thin, end-to-end slice of the real thing. Not a mockup — the actual pipeline, on your actual data, handling one narrow case correctly.

The slice matters because it converts every abstract assumption into something falsifiable. Data messier than promised, an API that does not do what its docs say, output that needs a format nobody mentioned — every project has these surprises, and week two is the cheap place to find them.

What you do: grant access fast (this is the most common source of week-one slippage), and look at the slice's output with your own eyes. Your reaction to real output is the most valuable design input the project will get.

Weeks 2-4: evals, then iteration against them

Now quality gets a definition. You and the vendor assemble an eval set — dozens to hundreds of real cases with agreed-correct answers — and every change to the system is measured against it. "It seems better" is replaced by "it went from 71% to 88% on the eval set, and here are the 12% it still gets wrong."

This is the single sharpest difference between an engineering-grade build and an impressive demo. It also produces the honest conversations early: some of the failing cases will turn out to be ones where humans disagree too, and deciding what "correct" means there is your call, not the model's. The broader pattern is in the five properties of production AI.

What you do: spend the hours to label and review eval cases. It is the least glamorous work in the project, and the hours that move the outcome most.

Weeks 4-6: integration, guardrails, and the failure path

The middle of the build wires the AI into where work actually happens — your CRM, your ERP, your WhatsApp line, your spreadsheet-shaped reality — and builds everything for the days the model is wrong: confidence thresholds, fallbacks, escalation to a human, and a review queue wherever a mistake has real cost.

Integration is routinely half the calendar on paper-simple projects, which surprises buyers and no experienced engineer. Legacy systems, missing APIs, and permission models eat days. This is also where run-cost gets engineered down — model choice per task, caching, batching — because the meter that matters starts at launch, not before it. The numbers behind that are in the economics of AI agents.

Weeks 6-8: hardening, acceptance, handover

The last stretch is production discipline: load and failure testing, security review, monitoring and alerts, and your team using the system on real work while the eval numbers are checked against the definition of done from week zero.

Then handover — and this is where good and bad vendors diverge permanently. Done properly, it means code in your repository, infrastructure in your accounts, the eval set and prompts included, a runbook your team can operate from, and training for the people who will live with the system. If the handover is a login to the vendor's platform, you have rented an outcome, not bought one.

When it legitimately takes longer

The 8-20 week industry range is wide for real reasons, and honesty requires naming them: data that needs serious cleanup before anything can be built on it, integrations with systems that have no APIs, regulated workflows where review and compliance gates add calendar time, and scope that is genuinely large. What should never add months: the vendor's own process. The drivers are the same five factors that set the price — covered in how much custom AI costs.

Mid-project red flags

• No working software by week three. The single most reliable predictor of a stalled project. Demos, decks, and architecture diagrams do not count.
• Progress reported in documents. Status updates should be "here is what it does now that it did not do last week", shown on screen.
• The eval set never materialises. If quality has no number by mid-project, "almost done" is unfalsifiable.
• Scope grows silently. New ideas are fine; new ideas without a written scope change and a date impact are how eight weeks becomes twenty.
• Your access requests stall the project — for weeks. A flag on your side of the table. The vendor should escalate it loudly; you should fix it fast.

What this means for you

• Expect a fixed scope and quote after days of scoping, not weeks of paid discovery.
• Demand a working slice on your real data by week two, and evals by week three or four. Put both in the contract.
• Budget your own team's hours: heavier in weeks 0-3 (access, examples, eval review) and 6-8 (acceptance), light in between.
• Treat handover completeness — code, infra, evals, runbook, training — as part of the definition of done.

Have a workflow you think this shape would fit? Book a 30-minute call. Bring the messy details — that is the part we actually need to hear, and we will tell you honestly if it is not a fit for a build like this.