The week-by-week shape
A productised setup follows a fairly consistent shape. It starts with a short setup session, usually on the first call and just after, to capture how you work, your tone, and the two or three jobs you want handled first. The foundation goes in quickly after that: the private record of how your business runs, the self-updating memory, and drafts learned from your own writing. In practice the first automations are drafting real work within the first week, on real examples from your business rather than toy demos.
The weeks that follow are not more building. They are fine-tuning: teaching it your edge cases, sharpening the tone, and personalising each job until the drafts are ones you would send yourself. That is what turns something that works into something you trust, and it is why handover lands at two to three weeks rather than one.
The order matters more than the length. An automation that drafts your quotes or chases your invoices only earns your trust once it already knows your prices, your standard terms, and the way you actually word things. Building that foundation first, before the automations themselves are polished, is why week one can look slow from the outside and is actually the fastest part on the inside: nothing flashy ships on day two, but everything that ships from day five onward is already working from your real business rather than a generic template that has to be corrected later.
If you begin with a Bottleneck Audit, add about a week for that up front. It is time well spent: you arrive at the build with the scope already decided and the right problem in the crosshairs, which usually makes the setup itself quicker than starting cold.
The stage-by-stage breakdown
Here is what that shape looks like stage by stage, from the first conversation through to the point where it is running on your own computer and you are the one operating it. I have listed the audit as its own line, since plenty of people skip straight to the build having already worked out what they want fixed.
| Stage | Roughly how long | What you provide | What you walk away with |
|---|---|---|---|
| Bottleneck Audit (optional) | About a week | Walk me through how the work actually gets done now, and answer straight questions about where the time goes | A written bottleneck map, six ranked fixes, and a 90-day roadmap, yours to keep either way |
| First call | 30 minutes, day one | Show me the job, or jobs, you want gone | A clear shortlist of which automations from the menu of twelve fit, and which tier makes sense |
| Foundation and first drafts | Week one | Access to the accounts involved (inbox, quoting tool, spreadsheet) and quick answers to my questions | The business record and self-updating memory in place, and the first automation already drafting real work |
| Fine-tuning | Weeks two and three | A few minutes to review drafts and tell me what is off | Your tone, edge cases, and every chosen automation sharpened until the drafts are ones you would send yourself |
| Handover call | End of week two or three | Test the system live, on a real job, during the call | Files on your own computer, training on running it, and full ownership |
| Adding more later (optional) | Roughly one new system a month | Two 45-minute calls a month, and the next job to show me | A new automation added to what already works, through the Monthly Consultation |
Treat every figure in that table as typical, not guaranteed. Two automations move through fine-tuning faster than twelve, simply because there is less to test and approve. A business running on one clear process, in a common setup like Google Workspace or Microsoft 365, moves faster than one running quotes through one tool, invoicing through another, and follow-ups through a third that was bolted on two years ago. The stages themselves do not change. Only the width of weeks two and three does.
Why most AI projects take months
Most AI projects run long for reasons that have little to do with the technology. The scope gets invented as they go, people weigh in at every stage, and generic tools have to be bent to fit a workflow they were never built for. Industry-wide, IDC found in a 2025 study for Microsoft (The Business Opportunity of AI) that most generative AI deployments go live in under eight months - and that figure is weighted by large enterprises with sign-off at every step. A small business working from a defined menu does not carry that weight, which is why the timeline is measured in weeks, not months. The lesson is not that faster is always better. It is that most of the delay in AI projects comes from indecision and scope creep, both of which a fixed menu removes before the work begins.
The other reason enterprise timelines stretch is that nobody is building against the real, messy business until much later. A committee signs off a plan, a vendor builds a demo, and the demo only meets real data months in, usually revealing that the real data was never as tidy as the plan assumed. A one-person setup skips that whole detour: I am working against your real inbox, your real quotes, and your real exceptions from week one, so there is no separate demo stage where the gap gets discovered later, once everyone has already agreed the project is nearly done.
What speeds it up, and what slows it down
A few things move the timeline within that window. It goes faster when you can give access to the accounts it needs without a fortnight of back-and-forth, when decisions get made quickly, and when your business is already reasonably documented. It slows down when access is tangled, when every choice waits on a busy week, or when the process lives only in your head and has to be drawn out first. None of these are dealbreakers. They just decide whether you land at the fast or the slow end of the two to three weeks.
In practice, three things tend to push a project past typical. The first is an undocumented process: if quoting depends on knowledge that only lives in your head, week one has to include drawing that out before anything can be automated, which eats into time meant for building. The second is multiple systems that need to talk to each other. One inbox feeding one spreadsheet connects quickly. An inbox, a separate quoting tool, an invoicing platform, and a shared drive that were each added at a different point in your business's history take longer, because each connection is its own small piece of testing. The third is simply pace on your side: if getting access to an account means a week of chasing whoever manages your IT, or a draft sits unread because you are flat out on a job, the calendar keeps moving even though the work does not.
What keeps a project at the fast end is closer to boring than clever. One clear process you can explain in a sentence. Common, well-known tools rather than a patchwork of niche ones nobody else uses. A quick turnaround when I send something to approve, even if the answer is just "yes, that's right" or "no, change this one line." None of that requires you to be technical. It just requires the work to already make sense to you, and for you to be reachable while I build it.
The one useful thing to do before the first call is not to tidy everything up first. It is to be ready to walk me through the messy version exactly as it actually happens, screen open, on the call. A project rarely slows down because a process is disorganised. It slows down when the disorganised version stays hidden until week two, because that is time spent finding the real process rather than automating it.
What about doing it yourself first?
It is a fair question, and I would rather give you the honest answer than the sales one. DIY tools, ChatGPT, Zapier, Make, can get a first version of something running in days, not weeks. If you only need one simple, low-stakes automation and you do not mind the tinkering, that speed is real and I would not talk you out of it.
What that speed does not include is what happens after the first version. An automation you wired together yourself is also one that only you can fix, and it tends to quietly stop working the day a website changes its layout or a spreadsheet column moves. A Zap that files invoices can run perfectly for months, right up until a payment provider changes its export format and invoices quietly stop filing without anyone noticing. Nobody broke it on purpose. Nobody was watching it either. A "working" system on day one and a maintained system six months later are two different things, and the gap between them is usually your own time, spent debugging instead of doing the job the automation was meant to take off your plate. I have written a fuller comparison of the two paths if you want to weigh it properly before deciding.
What "done" actually means
Done is not a switch-on date. It means the foundation is in place - the business brain, the self-updating memory, and drafts in your voice - and the automations you chose are built, tested, and running with your approval. You have been trained to use it, and it is handed over as something you own outright. From there it is yours to run, not a project you are still waiting on. See the full menu of automations.
"Tested" is doing real work in that sentence, so it is worth being specific about what it means here. Every automation that goes through fine-tuning gets checked against real examples pulled from your own business, not a tidy demo dataset chosen to make it look good. Nothing goes out to a customer or a supplier without your approval built into the workflow itself, which is also why handover always ends with you running it live on the call, rather than me telling you it works and hoping that turns out to be true.
After it is live
Once it is live, the system keeps itself current. A short daily wrap-up updates its memory of your business, so it sharpens with use rather than going stale, and a weekly health check quietly flags anything that has stopped or drifted. If you take the optional care plan, that covers maintenance and improvements - upkeep, not rent. Either way the system keeps working, because you own it. Most owners add an automation or two over the following months, once they have seen the first ones earn their place, but that is your call on your timeline, not a queue you are stuck in.
If you want to keep going past the first build, that is what the Monthly Consultation is for: USD 950 a month, two 45-minute video calls in that month, one new system built and shipped each time. The rhythm is the same as the first build, just spread over a month instead of two or three weeks, because by then the foundation is already in place and each new automation is being added onto something that already works rather than built from nothing. You can stop in any month you like. Whatever has already been built keeps running regardless.
A system added later through the Monthly Consultation goes through the same three moves as the first build, just compressed into one month instead of two or three weeks: a call to show me the next job, a build in between while you carry on running your business as normal, and a second call to test it live and hand it over. Nothing about the pace changes because the business has grown. It changes because the foundation from the first build is already doing the heavy lifting, so there is no repeat of week one.