How Long It Really Takes to Build an AI Product

Every published answer to "how long does it take to build an AI product" was measured on something that isn't an AI product. The numbers are real: 20 to 40 weeks for a mobile app (Clutch, 2026), 4 to 9 months for a general build (CatDoes, 2026). They are also numbers about screens, and an AI product does not run on screens.

The articles that do talk about AI go the other way. Lifecycle stages, speed gains, "concept to market in record time", and never a single week committed to. So the two halves of the internet split the question neatly in half and leave the middle empty: an AI system, from the first conversation to the day the business actually depends on it, takes how long?

Here is the honest version, phase by phase, including the two phases almost nobody counts.

The short answer, and why the range is so wide

A first AI product typically reaches genuine production somewhere between four and twelve months. Discovery through a working MVP is usually the fast part, often eight to sixteen weeks. Everything after the MVP, which is where most of the calendar actually goes, runs anywhere from six weeks to six months.

That is a wide band, and the width is not hedging. Three dials move it, and the number of features is not one of them.

The first is data readiness. If the data the system needs already exists, is accessible, and someone can grant permission to use it this month, the project runs fast. If the data lives in three systems, two of which are owned by a team that has other priorities, the project has a data-access timeline, not an engineering timeline.

The second is error tolerance. A system that drafts internal summaries can ship when it is usually right. A system that touches money, safety, compliance, or a customer-facing decision cannot. The gap between "usually right" and "wrong in ways we have mapped and handled" is often the longest stretch of the whole project.

The third is integration surface. An AI feature that reads from one system and writes to a screen is a different animal from one that has to write back into a system of record, respect an existing permission model, and survive a security review.

Set those three dials and the estimate will hold. Set it on feature count and it will not. Which raises the obvious question: why does the feature-count method work everywhere else?

Why AI timelines do not behave like app timelines

Because app estimates scale with scope in a way that is actually predictable. More screens means more design and more build. That relationship is why the published app numbers are as consistent as they are, and why an experienced agency can quote a range on a first call and be roughly right.

AI estimates do not scale that way. The build is often small. A retrieval pipeline with an evaluation harness can be a few weeks of engineering. What takes the time is establishing that the thing works well enough, on the real distribution of inputs, to be allowed near the business.

That inverts the usual shape of a project. In app work, the build is the long pole and testing is a phase at the end. In AI work, the build is short, the evaluation never really stops, and the honest project plan has more calendar after the demo than before it.

Here is the practical translation of that difference.

Anyone quoting an AI timeline without asking about all three is quoting from a template. Here is what the five phases look like when someone asks.

Phase one: discovery

Typical duration: one to four weeks.

Discovery decides the timeline. It does not merely estimate it.

The work is narrow and specific. Pick one workflow, not a category. Establish what the system has to do, what it is allowed to get wrong, and how anyone will know whether it worked. Confirm the data exists and that a named person can approve access to it. Identify who owns the outcome after launch , which is a different question from who is sponsoring the project, and the two are almost never the same person.

Discovery ends when four things are true: the use case is one workflow, the definition of "good enough" is written down as something measurable and signed off by whoever will own the outcome, data access is confirmed rather than assumed, and one person owns the result.

Skipping this phase is the most expensive way to save a week. It never looks like a delay at the time, because the team starts building immediately and progress looks fast. The bill arrives in month three, when it turns out the system was being built against a definition of success that two stakeholders understood differently.

A one-week structured discovery is usually enough for a first project. That is the shape of our own Discovery Sprint : five days, one workflow, and a roadmap with real numbers attached.

Phase two: the MVP

Typical duration: six to twelve weeks after discovery.

MVP means something specific here, and the specificity is what protects the schedule.

An AI MVP is a system doing the real task, on real data, evaluated against the measure agreed in discovery, in front of a small group of actual users. It is not a demo. A demo runs on examples chosen by the person who built it. An MVP runs on whatever arrives.

That distinction is why this phase surprises people twice, in opposite directions. The first working version often appears in two or three weeks, which feels like the project is nearly done. Then the real inputs arrive and the interesting work starts: the cases nobody anticipated, the inputs that are technically valid and semantically strange (a date field containing the word "asap" is the kind of thing nobody writes into a spec), the workflow steps the original scope quietly assumed away.

What belongs in this phase: the core capability, an evaluation harness that runs automatically , a small set of real users, and a feedback path from those users back to the team. What does not belong: polish, edge-case coverage beyond what the evaluation surfaces, and any integration that is not required to prove the value.

Teams that build the evaluation harness in the first two weeks finish this phase faster than teams that add it later, even though it feels like overhead at the start. Without it there is no way to tell whether a change made the system better, and the project starts running on opinion.

At the end of this phase the thing works. That is exactly where most timelines stop, and exactly where most of the remaining calendar begins.

Phase three: production readiness

Typical duration: four to sixteen weeks.

This is the phase no published timeline counts, and it is regularly as long as everything before it combined.

The MVP works. It works for the people who have been using it, on the inputs they have been giving it, with a team watching. Production readiness is the work of removing every one of those qualifiers.

The concrete list is longer than most sponsors expect:

• Failure handling. What the system does when it is unsure, when the model is unavailable, when an input is malformed, when a downstream service times out. Each of these needs a defined behaviour, not an exception.
• Evaluation at scale. The harness from the MVP has to cover the input distribution the system will actually see, including the categories that were rare in the pilot group.
• Monitoring. Somebody has to be able to answer "is it still working" without asking a user. Model outputs drift without announcing it, and with no instrumentation the first signal is a complaint.
• Cost control. Per-call cost that was irrelevant at pilot volume becomes a line item at production volume, and sometimes changes the architecture.
• Security review. Data handling, retention, access control, and the questions the security team will ask about what the model sees and where it goes.
• Access approvals. The permissions granted informally for the pilot have to be granted properly, which involves people who have not been in the project so far.

The pattern to watch for is a project that declares victory at the end of the MVP and then spends four months in a phase nobody planned. The timeline did not slip. The plan was missing a phase.

This is also where a pilot most often dies quietly . It rarely fails outright. It just runs out of sponsor somewhere between "the demo was impressive" and "the business depends on it".

Phase four: scaling

Typical duration: four to twelve weeks, often overlapping with rollout.

Scaling is where the system meets volume, and volume changes what the system is.

Three things reliably shift. Latency stops being a technical detail and becomes a product decision, because the response time that was acceptable to ten friendly pilot users is not acceptable to four hundred people doing the task under time pressure. Cost per call , previously a rounding error, becomes a number the finance team asks about. And the input distribution widens, which surfaces behaviour the pilot never triggered.

None of these are failures. They are the predictable consequences of the system doing what it was built to do, more often, for people who did not help design it. Four to twelve weeks for this phase is what the arithmetic gives you.

The teams that move through it quickly are the ones that instrumented properly during production readiness. If the monitoring is already in place , scaling is a series of measured adjustments. If it is not, scaling is a series of arguments about whether something got worse.

Phase five: enterprise rollout

Typical duration: four weeks to six months, and mostly not up to the engineering team.

The final phase is the one where engineering velocity stops mattering at all.

Procurement, legal review, security questionnaires, vendor onboarding, training, documentation, internal communication, and the slow work of getting people to change how they do a task they already know how to do. Every one of these has its own calendar, and those calendars belong to other departments.

The variance here is enormous, and it is organizational rather than technical. The same system can roll out in a month at a company with an established path for new internal tools, and take two quarters at a company where it is the first AI system anyone has had to approve. Nothing about the code is different.

One thing reliably shortens it, and it happens at the start rather than the end: involving security, legal, and the people who will actually use the system during discovery rather than presenting to them at rollout. A security review that starts in month one runs in parallel. A security review that starts in month six is a serial dependency at the worst possible moment.

Here is the full picture in one place.

Durations are ranges drawn from our own delivery experience on AI engagements, not fixed quotes or published benchmarks. Each one moves with the three dials above.

What actually makes an AI build faster

Four things, consistently.

Narrow the scope to one workflow. Not one department, not one category of task. One workflow, with a beginning and an end and a person who does it today. Everything else can be phase two.

Build the evaluation harness first. Before the capability is good, build the thing that measures whether it is good. It feels backwards, and it is the highest-leverage sequencing decision available in an AI project.

Unblock data access before kickoff. The approval conversation takes the same number of weeks whether it starts in week one or week six. Starting it in week one means it runs alongside the build instead of stopping it.

Give it one owner. Not a steering committee. One person who can make a call about what "good enough" means without scheduling a meeting.

And one lever that does not work: adding engineers. An AI project's long poles are data access, evaluation, and approvals, and none of them parallelize across more people. Brooks's law (Brooks, 1975) applies here in its original form: adding people to a late project makes it later, because coordination grows faster than output. On an AI build the constraint is usually a permission, not a pull request, and no headcount clears a permission faster.

What quietly adds months

The delays that hurt most are rarely dramatic. They are the ones that look like normal progress while the date moves.

• No written definition of "good enough". Without a measurable bar there is no moment when the system is finished, so evaluation continues indefinitely.
• Data access assumed rather than confirmed. Discovering in week five that the required data needs a formal approval process is a four-to-ten-week correction.
• No single owner. Every judgement call becomes a meeting, and meetings have lead times.
• Scope added mid-flight. A second use case introduced in month two does not add its own duration to the project, it restarts the evaluation work for both.
• Waiting for the next model. There is always a better model three months away. Building against what exists and swapping later is almost always faster than waiting for it.
• Security engaged at the end. The most reliably expensive sequencing mistake in enterprise AI, and the easiest one to avoid.

Almost all of these are decided in the first two weeks of a project, which is most of why discovery is worth doing properly.

How to read a timeline estimate

Whether the estimate comes from an internal team or an outside partner, four things separate a real number from a comfortable one.

Named phases with separate durations. A single figure for the whole project is a guess wearing a suit. Five phases with five ranges is an argument that can be checked.

Stated assumptions. A credible estimate says what it assumes about data access, error tolerance, and integration. Assumptions that never get written down are just hopes with better posture.

An explicit definition of done. Ask which of the three dates is being quoted: MVP live, production ready, or fully rolled out. They are three different dates, often months apart, and nearly every argument about an AI timeline turns out to be an argument about which one somebody meant. Settle that before anyone writes a date on a slide, and most of the disagreement disappears with it.

A checkpoint inside four weeks. Any plan whose first verifiable milestone lands in month three is a hope with a Gantt chart. The first real signal should arrive within a month.

If the answer to "how long will this take" needs to be defensible rather than optimistic, the fastest route to it is a structured discovery that produces the phase numbers for your specific situation. Our Discovery Sprint is one week, covers one workflow, costs $5,000, and ends with a roadmap that names each phase and what it depends on.

Key takeaways

• A first AI product typically reaches genuine production in four to twelve months, with discovery through MVP the fast part and everything after it the variable part.
• Three dials set the number: data readiness, error tolerance, and integration surface. Feature count is not one of them, which is why published app-development timelines do not transfer.
• Production readiness and enterprise rollout are the two phases most plans omit entirely, and together they routinely account for more than half the calendar.
• MVP live, production ready, and fully rolled out are three different dates. Agree on which one is being promised before anyone commits to it.
• Adding engineers does not compress an AI timeline. Narrowing scope, building evaluation first, unblocking data access early, and naming one owner do.