How long a custom AI project takes, week by week

Asked how long a custom AI project takes, we give every prospect the same numbers: scoping in days, a working prototype on your real data in 2 to 4 weeks, a production system between week 8 and week 12 for most mid-size scopes. A vendor quoting six months for a first version is either padding or planning a platform you did not ask for. One promising production in a fortnight is selling a demo with a go-live date.

The custom AI project timeline has an unusual property: the AI is rarely the long pole. Models are capable and the patterns are known. What moves the date is everything around the build: access, data, security reviews, and how fast your side can make decisions.

Days 1 to 5: scoping

Scoping a first AI project should take days rather than weeks, and produce three things: one workflow, one success metric, one owner with authority to decide. The method stays short because the discipline of scoping is mostly the discipline of refusing: not six use cases, not a platform, not an "AI strategy". Scoping also settles whether this should be a build at all; the build vs buy question is cheaper to answer in week one than in week ten. Also in week one, unglamorous but decisive: file every request for system access, sample data, credentials and a security review slot. At most companies these clear in weeks, and filing them on day one is the cheapest schedule protection available.

Weeks 1 to 4: a prototype on real data

The prototype exists to produce evidence. It runs on your live documents, tickets or transactions rather than on a cleaned export, because the distance between a demo and a system is the mess the export removed. By the end of week 4 you should hold three numbers: measured quality on an eval set built from your data, cost per unit of work, and a candid list of observed failure modes.

That is enough to decide continue, adjust or stop, having spent a month rather than a year. Some projects do stop here, and that is the timeline working as designed: a fast, clear no is one of the most valuable things a prototype can produce.

Weeks 4 to 12: production hardening

This is the unglamorous majority of the calendar: error handling for inputs the prototype never saw, the eval set expanded, monitoring wired in, permissions enforced, integration into the systems where the work happens, security review passed, and the internal team trained to own what ships. Nothing on that list is optional; every skipped item returns later as an incident with your name on it.

Teams are regularly surprised that hardening takes twice as long as the prototype. It should. The prototype proves the value; hardening makes the value safe to depend on.

What stretches the timeline

In observed order of damage: waiting for access and credentials; security and compliance reviews that start late (started in week one they run happily in parallel, started in week six they block everything); integrations with systems that have no API; data held by a third party who answers monthly; and decision latency, the quiet killer. A project with a decision-maker in the loop weekly moves roughly twice as fast as one whose questions queue for a monthly steering committee. None of the items on that list are AI problems. They are organizational, which means they are yours to remove.

What compresses it

The mirror image of the same list: a named owner with real authority, data available on day one, systems with APIs, one use case instead of six, and a build team embedded in your repos and your standups rather than shipping deliverables over a wall. That last point is why we work inside client teams rather than beside them: decisions made in days instead of weeks compound across a 12 week schedule. Budget, for what it is worth, shapes the timeline less than people expect; cost and duration are related but not proportional, and paying more mostly buys scope rather than speed.

Twelve weeks from first conversation to a system your team depends on is a normal outcome when the preconditions hold, and it is the schedule our build engagements are structured around. When a timeline slips, look for the cause on the stretch list above before looking at the model.