In February 2023 we had 28 open projects, three designers, and a shared Google Sheet called projects_v5_FINAL_real.xlsx. The sheet had 47 columns. Two of them were status (real) and status (for clients). If that tells you how that month ended, we don't need to explain further.

That month was what we now call the 2023 breaking point. We had accidentally grown past the size where eight-hour workdays and verbal handoffs could carry the business, and we hadn't yet built anything that could replace them. We were missing client deadlines, redoing work twice, and on one memorable Thursday, we launched a dentist's website with the wrong dentist's photos.

The response, over the following four months, was to rebuild the way we make websites from the ground up. What came out of it is the system that now ships 140+ sites a month with the same eight people. This is a tour of what we kept, what we threw out, and what we got wrong the first three times.

The 2023 breaking point

The issue was never capacity in the way we thought about it. Our designers could each, on a good week, produce the design for 2 to 3 small-business sites. Our developer could implement 3 to 4. Our sales guy could close 20. On paper, we had a balanced assembly line.

The actual failure was in the joints between people. Every time a design moved from Jovana to David, it took a half-day of back-and-forth to clarify what had been agreed with the client. Every time a build was done, a senior-ish person (usually me) had to manually QA it. Every revision request came back into the pipeline as a fresh item with no history attached.

We measured the handoffs for a week. On average, each site was losing 11 hours between Figma and DNS to pure friction — questions, clarifications, re-explanations, and the occasional redo. Eleven hours × 100 sites a month is a full-time person. We were paying a ghost.

Productizing the unproductizable

The first decision was to stop treating each site as a project and start treating them as units. A project has a bespoke scope, a custom timeline, and a conversation-driven brief. A unit has a fixed shape, a fixed duration, and a standardized intake. Agencies hate this framing because it sounds industrial. Our clients, it turned out, loved it, because it meant they actually knew what they were buying.

We wrote down the unit as a one-page spec. A DecaRoy build is: 4 to 7 pages, built on our internal theme scaffold, using our shared component library, with one revision round, one training call, and 30 days of post-launch support. If a prospect's needs fell outside that shape — more than 200 SKUs, custom integrations, a hand-drawn design direction — we referred them elsewhere. This sounds obvious in retrospect. It took us eight months to actually do it.

You cannot systematize a thing whose shape you have never committed to paper.

The three pipelines

Inside the unit, the work splits into three parallel pipelines that move roughly independently. Design, build, and QA. Each pipeline has one owner, a single input queue, a single output queue, and a hard cap on work-in-progress.

Design pipeline

Figma is the source of truth. Every project starts with a filled-in intake form, feeds into a shared "brief in" queue, and a designer pulls from the top. We cap design WIP at 6 projects per designer. When a designer is at cap, they cannot take new work — the sales team gets the signal and stops selling until the queue drains. This is the single hardest rule to enforce, and the single most important one.

Build pipeline

A developer pulls an approved design and builds against our internal scaffold. Same developer start-to-finish — no mid-build handoff, ever. We learned this the hard way in late 2023. Mid-build handoffs introduced a 22% defect rate. Single-owner builds dropped it to 3%.

QA pipeline

Mihaela runs QA and client success. Every build hits her queue before it leaves the building. She runs a 34-item checklist: performance, accessibility, forms, analytics, mobile, cross-browser, SEO basics, content accuracy. If an item fails, the build goes back with a named owner. She has veto power over launch. We almost didn't give her that. We were wrong.

Why async kills revision hell

The single biggest unlock was killing the real-time revision call. In the old world, a client would get the design, we'd schedule a call, they'd open Figma, and we'd talk through it live. On the call, they would say things like "move it a bit" and "make it pop" and we would translate that, in real time, under social pressure, into decisions the designer had not agreed to.

Now the client gets a Loom walkthrough of the design, a comment thread in Figma, and 72 hours to leave written, specific comments. We read them all at once. The designer makes the revisions in a single sitting with full context. One revision round, clearly scoped, done.

The side effect is that clients now write better feedback. When you know nobody is going to nod politely at your "make it pop", you have to figure out what you actually mean. About 60% of the time, by the time clients finish writing, they've self-corrected. They realize the thing they wanted to change was fine, and they ask for something else instead.

The tooling, for the curious

We use Figma for design, our own theme scaffold for the build, Make.com for pipeline automations (brief intake, handoff notifications, post-launch check-ins), GoHighLevel for CRM and sales sequences, and Slack for everything else. There is no custom-built internal tool. There was a six-month period in 2024 where we tried to build one. We shipped 40% fewer sites that half-year. We shut it down and went back to Slack.

What we got wrong

Three things, in chronological order.

The "flexible pipeline" phase, Q2 2023. We thought we could run two pipelines — one for "standard" builds and one for "premium" ones that would command a fee. The premium pipeline consumed 80% of management attention for 15% of revenue. We killed it.

The "AI everywhere" phase, Q1 2024. We tried to use LLMs to generate first-draft copy, first-draft designs, and first-draft QA notes. The copy was fine. The designs were bad. The QA notes missed the exact things a human catches. We kept the copy use and rolled back the rest.

The "let's open Germany" phase, Q3 2024. We tried to extend the pipeline to Munich. The partner commission math is different there, the sales cycle is longer, and the small-business owner is a fundamentally different buyer. We paused it after three months. We'll come back to it when we're ready — which is to say, when we understand the market instead of assuming we do.

Numbers from Q1 2026

For the people who want the receipts:

  • Sites shipped: 402 across January, February, March.
  • On-time rate (30-day SLA): 94%.
  • Post-launch defect escalations: 3.1% of builds.
  • Average NPS: 68 (SMB owners, measured day 30).
  • Sales-to-launch conversion: 71% of signed discovery calls reach launch.
  • Designer WIP cap breaches: 2 (both reverted within 4 working days).

The thing we are most proud of is the 94%. It is not 100. The 6% we miss, we miss for specific, named reasons, and we write up every one of them. If we ever hit 100, we'll know we stopped taking interesting clients.

Francesco Dei Campielisi is co-founder of DecaRoy. He writes about the operational side of the business roughly once a quarter. You can reach him at francesco@decaroy.com.