How Long Does It Take to Build an AI System? What Sets the Timeline

No one can give you an honest number for an AI build on the first call. Here is what an honest answer sounds like instead.

A clickable version on dummy data can exist early, in the first phase. That is because nothing is wired to your systems yet. A production system is different. It is live, with real people using it. It takes as long as its phases. Each phase stretches with the same five things:

• How many systems it reads from and writes to.
• The state of the data in them.
• How much risk the system carries.
• How fast access arrives.
• How fast decisions get made.

The spread is wide. Look at our own delivery record. Complex platforms that link many systems shipped in 28, 40, 42 and 45 days. The largest jobs ran as phased deliveries of 12 and 30 weeks. Thirty weeks is 210 days. Divided by 28, that is 7.5.

Same team. Same method. 7.5 times apart. That is what "it depends" looks like in real data.

A good plan turns that spread into dates. First, someone reads your systems. Then the scope should give a date for every phase, to the day. Ours arrives within 48 hours of the readout, the meeting where we share what we found.

What are the phases of an AI build?

Whoever builds it, a live AI system passes the same stops. Skipping one does not remove it. It moves the work to the end, where it costs more.

The Phase Map, as we draw it, has six stops. Each one ends in something you can check.

Each phase has win conditions. Those are tests that end in a count, or in a yes or no.

The order of the build phases matters. The mock-up comes first. A mock-up is a clickable model of the screens, with fake data. It answers one question cheaply: is this the thing you pictured? Under it, the build goes data first, structure second, skin third.

So the first milestone after the mock-up is the data, connected and checked. A CRM is the system that holds your customer and lead records. Say the CRM field everyone thought was full turns out to be empty. You want to learn that in the first milestone, not the fourth.

And every phase has its own date. So a slip shows up at the end of a phase. There, it costs a phase to fix. It does not wait for the end of the project, where it costs the project.

Why is a prototype fast and production slow?

Because the part you can click is the smallest part. A prototype is an early test version. A demo on dummy data needs a screen and a model. But think of a system you can put in front of customers, staff or an auditor. It needs all that sits under the screen:

• Access control at the database, on every query, so each user sees only their own rows.
• Each value it pulls out, stored with its source file, page and a short quote as proof.
• Each database change saved as a version you can roll back. Notes on each decision, for the next engineer.
• Every model call traced, with cost alarms and circuit breakers.
• A person who approves where it matters.
• Fallback providers for the day the first one goes down.
• A handover: code, accounts, documents and training.

Each one is real work. A vendor promising production AI in two weeks is skipping something. Either it is not in the build, or it is not in the date. Ask which.

The same gap explains the most common surprise in AI projects. A pilot worked in a meeting and never shipped. MIT's NANDA report looked at generative AI pilots at large firms. Generative AI is the kind that writes. Only about 5% of those pilots reached rapid, measurable revenue impact. Its authors blamed the gap mainly on tools that never adapted to the real workflow. A launch date doesn't close that gap. The layers under the screen do.

What slows down an AI build?

My read is blunt. The engineering is rarely the slow part. Waiting is. You wait for logins, for keys and for feedback. Or you find out that a system everyone thought was open has no way in.

The integration row is the one that bites late. An integration is a link between the AI system and one of your other systems. Take the scheduling system your operations team has used since 2011. In the third phase, the build needs to read from it. It has no API, no door for other software to use. What happens next turns on one thing. Did anyone find out in the scope, or in the phase?

Found in the scope, the design names the problem and the way around it. The date already allows for it. There is nearly always a way in. The question is how simple it is to build. Found in the third phase, the date moves and the bill follows.

Whose clock is the delay on?

A fair plan writes down which delays belong to which side. Access and feedback are on your clock. A closed system is on the vendor's clock. That holds if they read your systems before they set the date. Messy data is shared. New requests in the middle of a phase are yours. Changes inside the scope go on until you accept the work. Bigger asks go to the next phase, with their own scope, price and date.

Here is window language you can put in front of any vendor:

Client will give access within [2] business days of a written request. Client will give feedback within [3] business days of a delivered milestone. Time past a window moves the affected date by the same number of days. A delay on Vendor's side moves no date.

Set the brackets to what your company can really do. Our own contracts attach a penalty to a date we miss on our end. The windows are what make "our end" something both sides can check.

One delay the windows don't shorten is slow agreement. A window decides whose clock a delay goes on. It does not make nine reviewers agree faster. The fix there is one named approver, chosen before the mock-up goes out.

Can an AI system be built faster?

Yes, by building less, not by planning less.

Scope a lean first version aimed at the single biggest leak. Test it on a few real cases. Give later phases their own scope, price and date. Say your constraint, the leak that costs you most, is $40,000 a month. That number is made up. Now say a lean first build stops half of it. That is $20,000 a month you stop losing while the rest is built.

Three things should never be squeezed to hit a date: testing, access controls and the handover. Those are the parts that don't show in a demo and do show in an audit.

Two things truly shorten a timeline without cutting anything. One is access on Day 0, the day work starts. All of it, from one list. The other is one decision-maker per phase. Both sit on the buyer's side of the table. That is good news, because they are in your control.

When not to start with a dated plan

When no one knows if the task can be done. Say the open question is whether a model can read your documents at all. Then you are buying an answer, not a build. Buy the answer first, with a short written finding. Then plan the build. What an AI audit should include covers that first step.

When the job is small. A landing page or a basic CRM setup doesn't need a phase map. A good freelancer will have it done before a scope is signed.

When you want a number from a call. Any number given before anyone has read your systems is theater, ours included.

How to read a vendor's timeline

A dated plan should hold these, for every phase:

1. What exists at the end: a thing you can open, click or run.
2. A win condition that ends in a count, or a yes or no.
3. A date, to the day.
4. What the vendor owes you, and by when.
5. What you owe the vendor (access, logins, feedback), each with a window in business days.
6. Your written sign-off before the next phase starts.

And the red flags. Any one of them means the date is a hope:

• One date for the whole project, and none for the phases.
• A length of time ("about two months") where a date should be.
• No win conditions for each phase.
• Nothing about who owes what, and by when.
• No answer when you ask what the price leaves out.

A fixed price and a fixed date are two halves of the same document. Fixed price vs hourly AI development covers the other half.