Software & AI · Scheduling · Written and maintained by Haink’s AI adoption team · Updated August 2026 · 7 min read
How Long Does an AI Project Take?
Well-scoped AI projects move faster than most buyers expect: first working results in two to four weeks is realistic for many use cases, with production hardening adding several more weeks. What varies most is not the model but the path from a working prototype to a reliable production system — and how clean the data and how clear the scope are at the start.
Key takeaways
- The honest answer depends on what gets contested afterwards. A prototype is weeks; an assistant is two to three months; a document layer whose output can be challenged is six to eight.
- First working results in 2–4 weeks is realistic for most use cases, whatever the total.
- Most of a long calendar is waiting, not working. Four approval gates at two weeks each add 67% to a twelve-week build without adding an hour of engineering.
- Clean data, a narrow use case and a foundation-model-plus-RAG approach are the biggest accelerators.
- Messy data, deep integration and high compliance bars are the biggest delays.
- Phased, iterative delivery reaches value faster and lowers risk than a single big launch.
How long, by what you are building
“How long does an AI project take” has no single answer, and the ranges quoted in this market differ by a factor of eight because they are quietly describing different things. The variable that sorts them is not model complexity. It is what happens if the output is wrong — because that determines how much checking, evidence and integration has to exist around the model.
| What you are building | Spec / discovery | Build to production | Total |
|---|---|---|---|
| Prototype to establish whether the value is real | Days – 1 week | 2–4 weeks | ~1 month |
| Grounded assistant, light integration, internal users | 1–2 weeks | 4–8 weeks | 2–3 months |
| Document layer in a process whose output can be contested | 5–6 weeks | 4–6 months | 6–8 months |
| Custom ML system with its own modelling work | 2–4 weeks | 3–5 months | 4–6 months |
| Multi-system programme across several processes | Phased | Phased | 12 months+ |
Why the third row is four times the second. Nothing in it is model work. A deterministic check layer has to be specified and tested against agreed acceptance criteria; an evidence chain has to be retained per record; exceptions need a queue a person can actually work; and it all has to land inside a system of record that was not built to receive it. If a regulator, an auditor, a customer or a counterparty can challenge the output later, you are in that row regardless of how the first conversation sounded. That is why our own document intelligence engagements quote 5–6 weeks for the specification and 4–6 months for the build, rather than the two months a prototype timeline would suggest.
The phases, and where the time actually goes
| Phase | Typical duration | What happens |
|---|---|---|
| Discovery / specification | Days – 6 weeks | Goals, constraints, data audit, architecture, acceptance criteria and milestones. Longer where the output has to be defensible |
| First working results | 2–4 weeks | A usable prototype on real data that proves or disproves value — this part is fast almost regardless of the total |
| Production hardening | Weeks – months | Evaluation set, guardrails, integration, observability, security review. This is the phase whose length varies most |
| Operate | Ongoing | Monitoring, retraining, SLAs — or handover to your team |
Most of a long calendar is waiting, not working
The number quoted in a proposal is engineering effort. The number you experience is calendar time, and the gap between them is almost never the engineers.
A build has approval gates: access to the data, a security review, an integration window, a sign-off before anything touches production. Each is a queue rather than a task, and the arithmetic is unforgiving:
Which gives the single highest-leverage thing a buyer can do to a schedule, and it is not adding engineers: name the decision-makers for each gate before the build starts, and book the reviews in advance. A security review scheduled in week one for week eight costs nothing. The same review requested in week eight costs three weeks of everyone standing still.
What makes an AI project faster
- A narrow, well-defined first use case rather than a broad mandate.
- Clean, accessible data — the single biggest accelerator, and the one most often discovered to be absent in week four rather than week one. Data preparation and integration routinely take the largest share of a schedule.
- A foundation-model-plus-RAG approach instead of training from scratch.
- Named decision-makers per approval gate, booked in advance — worth more weeks than any staffing change.
- Reusing proven patterns and components rather than inventing everything.
What slows a project down
- Messy, scattered or unlabeled data that needs an engineering phase first.
- Deep integration into many existing systems with their own constraints.
- High accuracy or compliance bars that require extensive evaluation and review.
- Scope that grows mid-project instead of being phased.
- Unclear ownership and slow approvals.
Why phasing beats big-bang
The fastest path to value is iterative: ship a narrow version, measure it, and expand. This is why strong AI engagements aim for first working results in weeks and then build out — you see value early and steer the roadmap with evidence, rather than waiting months for a single large delivery that may miss the mark. Phasing also de-risks budget: each stage delivers something usable and informs whether and how to continue.
Two realistic examples, at opposite ends
A grounded support assistant, internal users. One week of discovery and a data audit; two to three weeks to a working RAG prototype answering real questions with citations; then three to five weeks of hardening — evaluation set, guardrails, integration into the support tool, monitoring — before rollout. Around two months, with something demonstrable inside the first month. Few approval gates, because nothing leaves the building and nobody outside challenges the output.
A document layer whose output can be contested. Five to six weeks to a specification with acceptance criteria agreed before anything is tested, with a prototype on real records inside that window; then four to six months of build — the deterministic check layer, the evidence chain, the exception queue, the integration into a system of record — with a data-access approval, a security review and an acceptance sign-off along the way. Six to eight months, of which a meaningful share is queue rather than work.
Same team, same tools, same technique. The difference is entirely in what has to be true for the output to be defended later — which is also why the two are priced roughly four times apart, as set out in how much custom AI costs.
Building AI software on your own infrastructure?
Model, pipeline and GPUs under one contract — tell us the use case and we'll scope it.
Talk to our engineers Prefer email? sales@haink.org
What to read next
- How much does custom AI cost? — the same tiers, priced rather than scheduled
- Build vs buy at the stack level — buying removes the model work, not the integration that sets the calendar
- AI Solution Blueprint — the 5–6 week specification, with a fixed price and timeline as its output
- From blueprint to implementation — what happens once the specification is signed
Related Resources
Frequently Asked Questions
How long does an AI project take?
It depends on what happens if the output is wrong, not on model complexity. A prototype to establish whether the value is real takes about a month. A grounded assistant with light integration and internal users takes two to three months. A document layer in a process whose output can be contested — by a regulator, an auditor, a customer or a counterparty — takes six to eight months, of which five to six weeks is the specification. Custom ML systems with their own modelling work run four to six months. First working results in two to four weeks is realistic in almost all of these, whatever the total.
Why do AI timeline estimates vary so much?
Because the phrase covers projects that differ by a factor of eight, and quotes rarely say which one they mean. The variable is not the model. It is how much checking, evidence and integration has to exist around it, which is set by the consequences of being wrong. A prototype nobody will challenge and an audited document layer use the same techniques and take entirely different amounts of time.
Why does a project take longer than the engineering estimate?
Because most of a long calendar is waiting rather than working. Approval gates — data access, security review, integration windows, sign-off before production — are queues, not tasks. Twelve weeks of engineering with four gates of two weeks each becomes a twenty-week calendar, so 40% of the elapsed time is nobody working. The highest-leverage fix is not adding engineers: it is naming the decision-maker for each gate before the build starts and booking the reviews in advance.
What makes an AI project faster?
A narrow, well-defined first use case, clean accessible data, a foundation-model-plus-RAG approach instead of training from scratch, fast decision-making, and reusing proven patterns.
What slows AI projects down?
Messy or unlabeled data, deep integration across many systems, strict accuracy or compliance requirements, scope that expands mid-project, and slow approvals.
Should we build everything at once?
No. Iterative, phased delivery — ship a narrow version, measure, then expand — reaches value faster and reduces risk compared with a single large delivery.
How quickly can we see something working?
For many use cases, a usable prototype on real data in 2–4 weeks after a short discovery phase, well before full production hardening is complete.
Sources and scope. Duration ranges are drawn from our own engagements and from published enterprise timelines, and are scoping guidance rather than commitments — data readiness moves them more than any other factor. The calendar arithmetic is illustrative: elapsed time equals engineering weeks plus the waiting at each approval gate, and both the gate count and the wait per gate are yours to measure rather than ours to assume.
Reviewed: August 2026.