How long does AI implementation take for a small business?
About 90 days per workflow, from the first mapping session to your team running the system without us. Before that build starts, an AI Readiness Audit takes 2–4 weeks; the Implementation Sprint itself runs 4–12 weeks depending on the workflow’s complexity.
You will hear shorter numbers. “Live in two weeks” is a common pitch, and this guide takes it seriously enough to explain exactly what ships in two weeks and why almost nobody is using it by week six. The 90-day figure is not padding — every week in it does specific work, and cutting a week removes something you will pay for later. What follows is the arc broken into its three phases, a week-by-week table, the levers that genuinely make it faster or slower, and one sequencing lesson from our largest published build. The full version of how we work is on the method page; this is the calendar view of it.
What happens in weeks 1–2?
Discovery and mapping: we watch the workflow run inside your real operation and write down where the hours, files, and decisions actually go. Skipping this phase is where AI projects die.
The work is unglamorous on purpose. We interview the people who do the task, watch them do it, inventory which systems hold the data and who can export it, list the edge cases everyone “just handles,” and pin down what done means — in numbers, agreed in writing. The reason this cannot be compressed is that every business runs two versions of every workflow: the one in the org chart and the one that actually happens. Build against the org chart’s version and you automate a process nobody performs; the system demos beautifully and dies in a month. Two weeks of mapping is the cheapest insurance in the whole project, and it is why our method starts here rather than at the keyboard.
What happens in weeks 3–10?
The build — inside your real operation, on your real files. The long pole is integration, not the model: getting the AI wired into your systems takes weeks; getting the AI to work takes an afternoon.
This surprises most buyers, so it bears spelling out. Modern models are astonishingly capable out of the box; the hard part is everything around them. Data access and permissions to your system of record. Handling the invoice that arrives as a photo of a crumpled page. Teaching the system your terminology, your formats, your exceptions — the work the essay Teaching the Machine Your Business describes. Then testing on real files, because real files are where demos go to be humbled: a healthcare practice we would map, for instance, gets intake paperwork as faxes, phone photos, and handwriting, and the system has to route all three or staff will stop trusting it after the first miss. Weeks 3–10 are mostly this: plumbing, edge cases, and testing against reality until the exception rate is boring.
What happens in weeks 11–13?
Handoff and training: your team runs the system while we watch, and by the end they own it outright. No dependency by design.
The deliverables are concrete — documentation written for the people who will use it, training sessions for the operators and the exception-handlers, and an escalation path for the day something odd appears. Training is not a webinar; it is your bookkeeper processing Thursday’s real invoices through the new system with us in the room, hitting a real exception, and handling it. People trust what they have personally seen recover from a mistake, and manufacturing that moment on purpose is what the last fortnight is for. The important part is the posture: we do not hold the keys. The system, the prompts, the integrations, and the documentation are yours at handoff, and if you never call us again it keeps working. If you would rather someone else watch it long-term, Managed Services is a monthly retainer with no lock-in — but it is an option, not a tether. A vendor whose timeline has no training phase is planning to be permanent. Ask where handoff is on their calendar; if the answer is vague, so is your ownership.
What does the timeline look like, week by week?
Three phases, thirteen weeks, and a column most timelines omit: what you should be doing while we work. The calendar has two owners or it slips.
| Phase | Weeks | What ships | What you should be doing |
|---|---|---|---|
| Discovery & mapping | 1–2 | Workflow map, data inventory, edge-case list, a written definition of done | Granting data access, naming one owner, telling staff why we are watching them work |
| Build & integration | 3–10 | The working system, wired to your tools, tested on your real files | Reviewing weekly outputs, flagging exceptions fast, keeping approvals to days not weeks |
| Handoff & training | 11–13 | Documentation, trained operators, an escalation path — you own all of it | Running the system yourselves while we watch, and telling us where it fights you |
The sprint band is 4–12 weeks — a single contained workflow lands near the short end; ~90 days is the typical full arc for one workflow.
What does a “two-week AI implementation” actually deliver?
Usually a chat wrapper: a general-purpose model with your logo on it, not connected to your systems, with no training and no edge-case testing. It is not fraud — it is just a different product wearing the word “implementation.”
The pattern is predictable. Week one, the wrapper appears and everyone tries it. Week three, usage has fallen to the two people who like new things, because the tool cannot see the job files, the customer records, or the calendar — so every answer is generic and every task still ends in the old system. By week six it is a line item nobody defends. That said, there is a legitimate case for the fast version: as a pilot. If your team has never touched AI and you want to build familiarity cheaply before committing real money, a two-week wrapper is a reasonable experiment — as long as it is priced like an experiment and nobody calls it a transformation. What it cannot be is the thing that changes your operation, because it never touches your operation.
What makes implementation faster — or slower?
Faster: exportable data, one named owner, and one workflow instead of five. Slower: approval bottlenecks and no system of record.
The fast levers are all on your side of the table. If your data can be exported from real systems, weeks of archaeology disappear. If one person owns the project and can answer questions in hours, the build never idles — decision latency is the quietest schedule-killer there is, and a question that waits a week doubles the calendar all by itself. And scope discipline compounds: one workflow done in ~90 days beats five workflows half-done in a year, every time. The slow cases are the mirror image: a committee where an owner should be, or an operation running on paper and memory, where there is no system of record to integrate with and one must be stood up first. If you want to know which side of this ledger you are on before spending anything, the free 20-point readiness checklist will tell you in an afternoon — and being unready is a fixable condition, not a verdict.
One more calendar fact vendors soften: multiple workflows do not run in parallel on day one. The second workflow reuses the plumbing, the data access, and the trust the first one built, so it usually lands faster — but it starts after the first one works, not alongside it. A vendor promising five workflows in one quarter is describing five pilots, not five implementations. A professional-services firm that automates intake first and proposals second will finish both sooner, and keep both, compared with one that launches everything at once and stabilizes nothing.
When should the highest-stakes work get built?
Last. In the MARCUS build at B:Side Capital — 14 agents across 7 departments — the highest-exposure work was deliberately sequenced last, after the low-stakes agents had run long enough to earn trust.
That ordering is the opposite of the demo instinct, which wants the most impressive thing first. But trust is the actual product of an implementation, and trust is built by boring reliability on low-stakes work — which is also why nothing in that system sends, files, posts, or pays without human approval. Sequencing this way is a large part of why real timelines are measured in quarters rather than days: the calendar is not just building software, it is building your team’s justified confidence in it. So plan the arc in full: an audit first — 2–4 weeks, $3,500–$8,500, which tells you which workflow to build and in what order — then a sprint at $12,000–$45,000, fixed in writing before work begins. Both prices are on one page. If 90 days sounds long, note what it replaces: a two-week tool nobody uses, purchased three separate times.