How long does an automation project take?
A single automation from the price list takes 10 business days from go-ahead to running in production. That is the build itself. Around it sit a thirty-minute scoping call, a written proposal within two business days, one to two weeks of parallel running, and a couple of days for cutover, so end to end, a first automation is typically three to five weeks from first conversation to fully live.
Several automations built together as a package, or a build with genuine two-way sync, run longer. The things that actually cause overruns are almost never the engineering: they are waiting for API credentials, discovering undocumented exceptions, and not having one person who can sign off.
Week by week
| Stage | Duration | Who is doing the work |
|---|---|---|
| Scoping call | 30 minutes | You and us |
| Written proposal | Within 2 business days | Us, then your sign-off |
| Build | 10 business days | Us, with weekly check-ins |
| Parallel run | 1–2 weeks | Your team keeps working as normal; we compare outputs |
| Cutover and handover | 2–3 days | Joint, including a recorded walkthrough |
Those stages overlap less than people expect. Scoping has to finish before the plan can be honest, and the parallel run cannot start before the build is functionally complete. Compressing the schedule mostly means compressing the parallel run, which is the worst place to save time.
What actually causes delays
In our experience the engineering estimate is rarely the problem. These are.
Waiting for access
By some distance the most common cause. A project stalls for eleven days because nobody can find who administers the accounting system, or because the CRM license with API access needs a purchase order, or because IT policy requires a security review nobody started. This is entirely avoidable and entirely predictable. Sorting access during scoping rather than at the start of the build removes it.
Exceptions discovered late
Someone mentions in week three that orders from one particular customer are handled completely differently, and always have been. That is not a small change; it is a new branch with its own testing. Thorough scoping surfaces most of these, but the genuinely tacit ones. The things people do without knowing they do them, sometimes only appear when the automation gets them wrong during parallel running. This is an argument for the parallel run, not against it.
No single decision-maker
Scope questions arrive constantly during a build: should this edge case route to a human or default to the standard path? If answering that requires a meeting between three people who are all busy, the project moves at the speed of their calendars. One named person who can decide is worth more to the timeline than an extra engineer.
Dirty data
Duplicate records, inconsistent formats, three spellings of the same supplier. Discovering this mid-build means either stopping to clean it or building defensive logic to cope with it, and both cost time. Competent scoping checks data quality before quoting.
A system with no usable API. Working out whether a scheduled export, a database connection, or browser automation is the least-bad route can take a day or two on its own, and each option is slower to build and more fragile than a real integration. If you know one of your systems is like this, say so on the first call. It changes both the timeline and the price.
What makes it go faster
- Sort credentials during scoping. A dedicated service account with the right permissions, created and tested before the build starts, routinely saves a week.
- Name one decision-maker. Someone who can answer scope questions within a day without convening anyone.
- Be honest about exceptions early. Nobody is judging the fact that your process has fifteen special cases. Every process does. Hiding them does not make them go away, it just moves the cost to week three.
- Start narrower than feels satisfying. One process, done properly and live in a month, beats four processes half-built in a quarter. The second build is always faster because we already know your systems.
- Do not batch the sign-off. Reviewing the proposal the day it arrives rather than the following Friday moves the whole schedule forward.
Why parallel running is not padding
The most common request is to skip the parallel run and go straight live. It is understandable. The build works in testing, and another two weeks feels like caution for its own sake.
It is not. Testing proves the automation handles the cases you thought of. Parallel running proves it handles the cases that actually occur, on real data, at real volume, including the ones nobody mentioned. The two are not the same, and the gap between them is where automation projects fail publicly.
Running both in parallel means every discrepancy gets found while the manual process is still there to catch it. Nothing reaches a customer wrong. When the outputs match for a sustained period, you cut over with evidence rather than hope, and you keep the manual fallback documented, because vendors have outages.
Two weeks of parallel running is cheap. One invoice sent to the wrong customer because you skipped it is not.
Want a timeline for your process?
Tell us which systems are involved and we will give you a realistic schedule on the call.
You will talk to Fayez or Kareem. Nobody else.