What an automation project looks like: stages, timeline, and what you get
A well-run automation project moves through 6 stages: a mapping call, a modular proposal, development in short iterations, testing against real data, team training, and a handover that transfers full ownership of the code to you. A focused project ships in a few weeks; a broad system takes a few months. At the end, the system belongs to you, code included, with no dependency on the vendor.
This guide walks through each stage, what it asks of you, and what you get back, so you can enter a project like this knowing exactly what to expect.
What are the stages of an automation project?
An automation project has 6 stages, and each one produces a defined deliverable. This table summarizes the process as we run it at Automation Flow:
| Stage | What happens | What you give | What you get |
|---|---|---|---|
| 1. Mapping call | We walk through your processes and find where the hours actually go | An hour of your time, a description of how work flows | A clear picture of what's worth automating and what isn't |
| 2. Modular proposal | Scope is broken into independent modules, each with a defined output | Feedback on priorities | A detailed proposal with a fixed price per module |
| 3. Build in iterations | Development runs in short sprints; you see a working version every week or two | An available point of contact for questions and decisions | A working demo each iteration, no end-of-project surprises |
| 4. Testing on real data | The system runs against your actual data and edge cases | Real examples, including the messy ones | A system proven against your reality, with fixes applied |
| 5. Team training | We train the people who'll use the system daily | Training time for the relevant team | A team that operates the system without depending on us |
| 6. Handover and ownership | Code, credentials, and documentation transfer to you | Target accounts and infrastructure in your name | Full ownership of the code and system, no vendor lock-in |
What happens on the mapping call?
The mapping call answers one central question: where do the hours in your business actually go, and which of those processes qualify for automation. We walk through the working routine together, identify tasks that repeat, and sort them along two axes: how much time they burn, and how structured and predictable they are.
Some processes don't qualify. A process that needs human judgment at every step, or that changes shape every week, usually isn't worth automating yet. Part of the value of mapping is being told what to skip. A good mapping call ends with a short list of processes that do qualify, a clear reason for each, and a rough sense of scope.
How is pricing built for an automation project?
Pricing is built per module: each module is a self-contained unit with a defined output, gets its own price based on its scope, and that price is fixed after mapping and doesn't move. You know exactly what you're paying for, you can add or drop modules to fit a budget, and you're never exposed to open-ended hourly billing. Cost questions get answered on a call, because a serious price follows from scope, and scope only becomes clear during mapping.
How long does an automation project take?
It depends on scope, and here are honest ranges from our experience. A focused automation of a single process takes 2 to 4 weeks. A system covering several connected processes, say lead intake, follow-up, and document generation, takes 4 to 8 weeks. A broad system with AI agents, multiple integrations, and organizational memory runs 8 to 16 weeks.
Two things affect the timeline more than anything else: whether you have a point of contact who answers questions and makes calls quickly, and the state of your existing systems (a tidy CRM with an API connects fast; scattered spreadsheets take longer). Because the work runs in iterations, you don't wait until the end to see value: the first module is typically live in your business within 2 to 3 weeks of the build starting.
What does the build phase look like from the client's side?
The build runs in short iterations, and each one ends with you seeing something real work. There is no "we disappear for a quarter and come back with a system" period. Every week or two there's a demo: a module running, a process working end to end, something you can click and react to.
This rhythm has 2 advantages you feel directly. First, misunderstandings surface after a week instead of after a quarter, while fixing them is still cheap. Second, if your priorities shift mid-project, modules can be reordered without tearing the project apart.
The testing stage runs on your real data rather than sanitized samples. We push last month's actual cases through the system, including the annoying and irregular ones, and fix until it behaves correctly on those too. A system that only passed clean tests breaks in its first week live, and we'd rather live through that week together, before handover.
What do you get at the end of an automation project?
At the end you get full ownership of the system: the code, the workflows, the credentials, and the documentation transfer to you, and everything runs on accounts registered in your name. At Automation Flow this is a principle, present in every project: ownership of the code passes to the client. No monthly license on the code, no black box only we can touch, no lock-in.
Why does this matter? Because part of the market works the other way: the system stays with the vendor, and you pay monthly for access to something built with your money. Every small change then routes through them, forever. When you own the system, you're free: continue with us, maintain it with an internal team, or bring in another vendor. We prefer clients who stay because it's working for them, and full ownership keeps everyone honest.
Alongside the code you get documentation: what the system does, how it's built, what to do when something jams, and how to extend it.
What does ongoing support look like after handover?
After handover there's a close-support period for stabilization, and then you choose a track: ongoing maintenance with us, or fully independent operation. In the first weeks after going live, things always come up: a new edge case, a provider changing an API, a small request from the team. During that period we're available and respond fast.
After that, clients who want peace of mind continue with ongoing support covering monitoring, fixes, and improvements. Clients with a technical team can maintain the system themselves, because the code and docs are theirs. Both tracks are legitimate, and the choice stays yours a year later too.
Frequently asked questions
How long from first call until something is working in our business?
In most projects the first module is live within 2 to 3 weeks from the start of the build. Before that comes the mapping and proposal stage, which usually takes 1 to 2 weeks, depending mostly on how quickly you gather materials and approve the proposal.
How much of our time does the project need?
Less than you'd expect, but more than zero. You need an hour for the mapping call, a point of contact available for questions and decisions during the build (typically a few messages a week plus a short demo meeting per iteration), real examples for the testing stage, and training time near the end. Projects stall almost exclusively for one reason, the absence of someone who can decide, so we ask for that person up front.
What if we realize mid-project that we need something different?
Because the work is split into modules and iterations, a change of direction is a managed event: add a module, drop one, or reorder, with a clean scope update. Whatever was fixed in the proposal stays fixed, and anything new gets its own definition and price before it's built.
What tools is the system built on, and what if a tool changes?
We build mostly on n8n, with Claude for AI agents and Python for custom logic, and we prefer tools with large communities and open source where possible. Since ownership transfers to you, you're never bound to our choices: any developer familiar with these tools can pick up the work.
Do we need technical people on our side?
No. Our conversations with you are about business processes: who does what, what takes time, where things get stuck. We handle the translation into architecture and code, and the training stage teaches your team to operate the system in its own language. What you do need is deep familiarity with your own processes.
How much does a project like this cost?
Price follows from scope, so a serious answer only exists after mapping. What we can say up front: pricing is built per module, each module gets a defined price, and the total is fixed before the build starts. There's no open-ended hourly billing and no surprise at the end.
How is this different from buying an off-the-shelf tool?
An off-the-shelf tool solves a generic process; a custom automation project is built around yours. When your process is fully standard, an off-the-shelf tool is sometimes the right answer, and we say so during mapping when that's the case. A custom project earns its keep when processes are complex, span several systems, or are exactly the thing that makes you competitive.
The simplest way to find out whether this fits your business is a mapping call with Automation Flow: one hour, a walk through your processes, and you leave with a clear picture of what's worth automating, in what order, and on what timeline.
