How long does it take to build an AI automation?

Timeline by project size

Elapsed time, not effort. The distinction matters: a two week project is rarely two weeks of continuous work, and the gap between the two is almost always spent waiting for something on the client side.

What a two week build actually contains

Set out day by day, because the phrase live in 14 days means very little without it. This is our own delivery pattern for a single agent, stated as ours.

1. 1

   Days one and two, discovery

   Sit with whoever owns the process today. Watch it being done rather than being described, because the description always leaves out the exceptions. Agree what is in scope, what the system does when it is not confident, and where the boundary of its authority sits.

2. 2

   Day three, access and the map

   Credentials, permissions and test environments requested. The process map signed off in writing. Nothing is built before that signature, because a map corrected in week two costs a week.

3. 3

   Days four to eight, the build

   Integrations first, because that is where the surprises are, then the agent logic, then the exception path. The exception path is built during this phase rather than added at the end, which is the difference between a system and a demonstration.

4. 4

   Days nine and ten, testing against real data

   Real historical items, including the awkward ones deliberately chosen. Output compared against what the team actually did with those items. Thresholds tuned until the exception rate is sensible rather than flattering.

5. 5

   Days eleven and twelve, shadow running

   The system processes live work in parallel while people carry on as normal. Nothing it produces is acted on. This is the phase most often skipped and it is the one that catches the expensive mistakes.

6. 6

   Days thirteen and fourteen, go live and handover

   Switched into the live path with monitoring and alerting on a named person. Documentation delivered, a recorded handover session, and the optimisation window opens.

Five things that make a project run late

In order of how often they are the actual cause. Four of the five sit on the client side, which is not a criticism: it is the reason a schedule should name who is responsible for each of them on day one.

1. 1

   Access

   Credentials, permissions, a sandbox environment, an exception to a security policy. This is the single largest cause of delay in automation projects and it is almost never the builder's to solve. Start it before discovery finishes rather than after.

2. 2

   An undecided rule

   A case nobody has ever written down, where two people in the business genuinely disagree about the correct handling. The build stops until somebody with authority decides. Identifying these during discovery, and naming who will decide each one, is the highest value thing a discovery session does.

3. 3

   No single owner

   A project reviewed by a committee moves at the speed of the next available meeting. One named owner with authority to sign off is worth more to the timeline than any amount of engineering effort.

4. 4

   Data quality discovered late

   Duplicate records, inconsistent references, three formats for the same field. This is normally found in testing, and it either extends the project or narrows the scope. Sampling real data during discovery moves the discovery earlier, where it is cheap.

5. 5

   Scope growth

   The second and third process added while the first is being built, usually with good intentions. The fix is not refusal but sequencing: finish the first, put it live, then start the second with the benefit of what was learned.

What can and cannot be compressed

Can be compressed

• Discovery, when the process is already documented and the owner is available for a single uninterrupted session.
• Integration work, when every system involved has a proper interface and credentials are ready on day one.
• Build time on a process closely resembling one that has been built before, where the pattern is already proven.

Cannot be compressed safely

• The period of running against real data. Unusual cases arrive at their own pace and no amount of effort makes a month's worth of edge cases appear in three days.
• Decisions that require somebody in your organisation to choose between two defensible answers.
• Hardware lead time, and any security or procurement review, both of which run on their own calendar.

What happens after go live

The first two to four weeks are optimisation rather than maintenance. Real inputs surface cases the design never anticipated, thresholds are adjusted, and the exception rate falls, usually sharply. Expect the completion rate in week one to be lower than the rate in week four, and judge the system on the second figure rather than the first.

A build handed over on the day of launch, with no observation period, has been handed over too early. Our own builds include a 28 day optimisation window that starts at go live, and the same window is when the return is measured against the position before. That is our published position rather than a market norm; other suppliers structure it differently and some do not include one at all.

Four questions to ask about any stated timeline

• Does the stated date mean live in the real path, or a demonstration on sample data?
• What is assumed about access, and by when do those credentials have to exist?
• Is there a period of running against real work before the system is trusted, and how long is it?
• What happens to the date if a rule turns out to be undecided, which is the most common single cause of slippage?

Reviewed 25 July 2026. Market figures change; where this page quotes a range from a third party, the source is named above. Figures described as ours are our published fees or typical results for a first build, not measured results for a named client.