How we ship a working system in 5–12 days

When people hear 5–12 days they assume we're cutting corners somewhere. Rushing the build. Shipping something half-finished and calling it done.

We're not. The timeline is real and it's repeatable — we've hit it across every client build including Bodyline, JMJ Homes, and MaxSil. Different industries, different systems, same result.

The reason it works is not that we build fast. It's that we don't start building until we know exactly what we're building.

The standard agency process looks like this: discovery call, proposal, contract, kickoff, build, review, revisions, more revisions, launch. The whole thing stretches across six to twelve weeks and the client spends most of that time waiting for updates.

The reason it drags is that the thinking and the building happen at the same time. The agency is figuring out what to build while it's building it. Every revision cycle is a symptom of something that should have been resolved in discovery.

We separate those two things completely. Discovery is finished before build starts. By the time we write the first line of code, every decision has already been made.

This is where the real work happens.

We map everything. Your workflows, your tools, your approval preferences, your brand voice, your edge cases. We ask questions that feel tangential — who your difficult callers are, what a complaint looks like versus a normal query, which staff members need to be involved in which decisions. None of it is tangential. It all ends up in the system.

The output is a spec document. A full written description of what we are building, how it routes, and what it does in every scenario we could map. You read it. You correct anything that's wrong. We don't write a line of code until you've signed off on it.

This document is what makes the rest of the timeline possible. Every decision downstream — how the agent handles an edge case, which tier an action falls into, when the system escalates — is already answered before we open n8n.

This is the mechanical part. The n8n workflows get built. API credentials get connected. The voice layer gets configured. Brand memory gets populated. Approval thresholds get set.

It looks unimpressive from the outside — a lot of workflow nodes, a lot of test inputs, a lot of incremental checks. But because the spec is already written and signed off, there are no judgment calls being made mid-build. We are executing a plan, not discovering one.

Internal testing starts from day five. We push synthetic inputs through the system — fake calls, fake emails, edge cases from the spec document. Most things work as expected. Some things surface unexpected behaviour. We catch and fix those before you see them.

No client contact during the build phase. We are heads down.

Day ten: you test it as a customer. You call in, send a message, try to book, ask something unusual, probe the escalation path. You tell us what felt wrong — a phrase that sounded off, a routing decision that didn't make sense, a tone that didn't match your brand.

Day eleven: we fix everything you flagged. Tune the prompts. Adjust the thresholds. Rerun the edge cases. The system gets tighter.

Day twelve: handoff call with your team. We walk through how to update the knowledge base, how to read the daily Telegram briefings, what the monitoring looks like, and what to do if something behaves unexpectedly. Then we go live.

Two things legitimately extend the timeline and we are upfront about both.

The first is scope complexity. A build involving more than two or three system integrations, or one that requires significant custom logic, needs more time in phase two. We identify this during discovery and tell you before we start. It doesn't come as a surprise on day eight.

The second is slow feedback during the test phase. The test-and-tune phase only works if you have time to actually test it and give us your feedback. If that takes five days instead of two, the handoff shifts right accordingly. The system does not go live until it's right — not until a specific date on the calendar.

In the standard case — one or two core integrations, a motivated client who can carve out an hour to test — 5–12 days is real.

Every fast build we've shipped has one thing in common: a discovery phase that was taken seriously.

When the spec is thorough, the build is mechanical. When the spec is vague, the build becomes a research project. And research projects don't have predictable timelines.

The 5–12 day timeline is not a function of how fast we can write n8n workflows. It's a function of how well we understand your business before we start.

That understanding comes from the discovery call. If you want to see what 5–12 days would look like for your operation, that's where we start.