That is not a hedge. It is the actual shape of the work, and it is worth saying plainly rather than quoting a single number that only holds true for the easiest case. This guide walks through what determines an AI project timeline, roughly how the phases divide up the elapsed time, what most often adds weeks that nobody planned for, and what a client can do to keep their own project on the fast end of the range rather than the slow one.
The direct answer, and the honest caveat
For one narrow system — a single workflow, one clear owner, a defined set of systems it needs to read from or write to — weeks, not quarters, is the realistic target. That holds for a support agent that handles one category of enquiry, a workflow automation that reconciles two systems, or a first voice AI deployment covering one call type.
The caveat is not a disclaimer, it is the actual finding: two projects with near-identical technical scope can land on opposite ends of that range, and the difference is rarely the technology. It is usually how ready the client side was. A team that shows up with a decision-maker who answers same-day, credentials already gathered, and a realistic account of how the process actually runs will finish nearer the front of the range every time. A team that has to chase access requests, wait on a stakeholder who reviews on a fixed cycle, or discover midway through that the documented process was never the real one will land nearer the back of it — sometimes well past it. Our process page lays out the four stages this runs through — Discover, Design, Build, Run — and this guide goes deeper specifically on time, since that is the question most people actually have before they pick up the phone.
What actually determines the timeline
Six factors do most of the work in setting how long a build takes. None of them are about how hard the underlying AI problem is — they are about how well-understood and well-supported the project is before and during the build.
- How well the process is understood before starting. A workflow that has been mapped honestly — including the exceptions, the workarounds, and the steps nobody wrote down — moves fast because there is nothing left to discover mid-build. A workflow that is only understood at the level of "here's roughly what happens" tends to surface surprises once real data hits it.
- How fast the client can grant access to their own systems. Every build eventually needs credentials, API access, or a sandbox in the systems it touches. Whether that access arrives the same week or gets stuck in an internal ticket queue is one of the single biggest swing factors in the whole timeline.
- Whether a decision-maker answers in days, not weeks. Builds generate questions — about an edge case, a wording choice, a judgement call the system needs to make. A point of contact who can answer those quickly keeps momentum. One who reviews on a fortnightly cadence turns a short build into a long one almost by accident, one small delay at a time.
- Data condition. Clean, current, accessible data lets a build move straight to logic. Data that is scattered across systems, inconsistently formatted, or genuinely out of date adds real work before the system can be trusted with anything. Our AI readiness checklist is a way to check where your own data and access stand before a project even starts.
- How many exception cases must be handled before go-live. A workflow with three clear paths is a different build than one with twenty edge cases that each need a defined behaviour. This is usually invisible until someone actually lists every way the process can branch, which is exactly why that listing happens early.
- How many people must approve. One owner who can sign off keeps things moving. A build that needs sequential agreement from several stakeholders before anything ships adds waiting time that has nothing to do with the system itself.
How the phases divide up the time
Using the same four stages laid out on the process page — Discover, Design, Build, Run — the elapsed time is not spread evenly across them. Two stages are short by design; one carries most of the calendar.
Discover and Design together are a small fraction of the total elapsed time. These stages are deliberately bounded — long enough to be precise about what is being built and why, short enough that scoping never becomes the project in its own right. If either of these stages is dragging, it is almost always because access or a decision is stuck somewhere, not because the scoping work itself is slow.
Build is where the majority of the calendar time sits, and it scales with how many systems the work touches and how much judgement the system needs to exercise well. This is also the stage most exposed to the client-side factors above — access requests, decision speed, and exception handling all surface here, because this is where the system meets real data and real edge cases for the first time.
Run does not have a fixed length, because it is not a phase that ends. A system that goes live and then gets left alone degrades quietly as the business around it changes. The weeks immediately after launch matter for tuning against real volume, but "how long until this is finished" is the wrong question for this stage — it is closer to "when does this next need attention," and the answer is continuously.
What most often adds weeks nobody planned for
A handful of patterns account for most of the gap between the fast end of the range and the slow end. None of them are exotic — they show up on ordinary projects, repeatedly.
Waiting on IT access. A credential or sandbox request that sits in an internal queue for a week is a week added to the build regardless of how fast the actual work goes once access arrives. This is the most common and most avoidable source of delay, because it is entirely within the client's control to front-load.
A stakeholder who reviews on a fixed cycle. If the one person who can approve a decision only looks at requests once every two weeks, every question that needs their sign-off inherits that cadence — even a five-minute decision effectively costs up to two weeks if it lands the day after the review window closes.
Discovering the documented process is not the real process. Almost every workflow has a written version and a lived version, and they rarely match exactly. The gap usually surfaces once the system is built against real data and hits a case the documentation never mentioned. Surfacing this during Discover, by watching the work rather than reading a description of it, is what keeps it from surfacing later and more expensively.
Scope growing mid-build. A team sees the system working and, reasonably, wants it to also handle one more case, or connect to one more system. Each addition is small on its own. Added up mid-build, without being re-scoped and re-priced the way the original build was, they are the most common reason a project that was supposed to take weeks starts to look like it will take quarters instead.
What the client can do to compress it
Most of the levers that shorten a timeline sit on the client side, which is good news — they are within reach before a project even starts.
- Gather access before Discover, not during Build. Whatever credentials, exports, or sandbox environments the build will eventually need, requesting them early removes the single most common source of dead time.
- Name one decision-maker who can answer quickly. Not a committee, not someone relaying questions to someone else — a person who can make small calls without convening a meeting first.
- Be honest about how the process actually runs, workarounds included, during Discover. The exceptions you don't mention during scoping are the ones that get discovered mid-build, at a worse time to deal with them.
- Resist adding scope mid-build. If something new comes up while the first version is being built, note it for the next phase rather than folding it into the current one. A narrow first project that ships on schedule is worth more than a broader one that keeps slipping.
- Set the approval chain before work starts, not after a decision is already waiting on it. If a change needs sign-off from more than one person, agree upfront how fast that group can turn it around.
Timeline and cost tend to get scoped together, since both depend on the same factors — how many systems are touched and how much judgement the system needs to exercise. Our guide to what a custom AI agent costs covers the price side of the same question this guide covers for time.
If you are earlier than scoping a specific build — still deciding what is worth automating at all — that groundwork usually happens through AI strategy work, which exists precisely to settle those questions before a Build-stage clock starts running.
Why a narrow first scope finishes faster and teaches more
There is a temptation, understandably, to scope the first AI project as broadly as the ambition behind it — cover every case, touch every system, solve the whole problem at once. That instinct almost always works against the timeline, and against the project's actual chances of success.
A narrow first system finishes faster for an obvious reason: fewer systems, fewer exception cases, fewer approvals standing between the start of Build and something live. But the less obvious reason matters more. A small system running against real data in production teaches you things a large system still sitting in a test environment cannot: whether the data is actually as clean as everyone assumed, whether the team adopts the tool the way the plan assumed they would, whether an integration behaves the way its documentation claimed. Every one of those findings is worth having before committing to the next, larger piece of scope — and every one of them is cheaper to discover on a narrow system than on a broad one.
That is also why go-live is never really the finish line. Once a system is running, it moves into an ongoing Run stage, where it gets monitored, tuned against what real usage reveals, and adjusted as your business changes around it. A narrow first system reaches that stage sooner, which means it starts generating that signal sooner — and the next piece of scope gets built on evidence rather than a guess about how the first piece would perform.