More workers is faster.
Until it isn’t.

The shape of it

Four stages, and only one of them is elastic

The limits, stated plainly

Four things bound this, and none of them is how many agents we have

Every one of these was paid for in real defects and real delay on live work. They are on this page rather than buried because pretending otherwise is how a delivery promise gets broken — and because the first three are also why capacity is a factor in what you pay.

1. 1
   Shared surfaces are single-writer

   Navigation, security and the common model can only be edited by one worker at a time — in any application, at any size.

   What it means for you: A small application runs out of independent seams almost immediately; a large one has several places to work in parallel. So how much parallelism your project can absorb is a property of your model, not of what you buy.

2. 2
   Past a point, extra workers mostly generate queue

   Beyond roughly six to eight concurrent workers, the wait for those shared surfaces dominates everything else.

   What it means for you: Twelve workers is not twice the throughput of six, and anyone who sells it that way will miss a date. We size to the knee and tell you where yours is.

3. 3
   Verification needs a running application

   Proving a change means opening the real app and driving it, so the number of running application stacks is bounded even though the workers are not.

   What it means for you: This is the honest reason capacity is not infinite. It is also why the evidence is worth anything — a claim that scaled without limit would be a claim nobody was checking.

4. 4
   Decisions on your side

   The questions only you can answer — a rule nobody remembers, a screen nobody owns, a permission nobody will sign off.

   What it means for you: Measured across real engagements this is the largest single source of delay, and it is the one nobody prices. We batch these rather than raising them one at a time, because each one raised alone costs a fortnight.

The counter-intuitive one

The same capacity does more across three projects than on one

Collisions on shared surfaces happen within a project, never between them. So the same number of workers split across three applications loses nothing to queueing, while the same number stacked onto one project spends part of its capacity waiting.

This is worth knowing before you buy, because it changes what to buy. If you have three applications that need attention, that is a better shape than one application you would like done three times faster — and it costs the same.

If it really is one application against a date, the honest answer is that we partition your model first and add capacity second. Adding capacity to a model that cannot absorb it is how a date gets missed with everybody working flat out.

What follows from it

Why the price has a capacity factor

Throughput is bounded. Shared surfaces — navigation, security, the common model — are single-writer, so beyond roughly six to eight concurrent workers you are queueing, not scaling. We size to that reality instead of selling workers that would sit idle.

That is the reason capacity is one of the three things that move your number rather than a slider you can drag upward indefinitely. If more workers were always better we would simply sell you more workers.

What drives the price Talk to Marcus about your model