Agency overflow: what to do when you sell more dev work than you can build

Your pipeline is fuller than your delivery calendar. A client just signed, another wants their build moved up, and the honest look at your team’s next six weeks says you cannot do all of it well. You have three options and you dislike all of them: turn the work away and hope the client comes back, push your team into the overtime that precedes people quitting, or hire in a hurry and carry the cost long after the spike is gone.

There is a fourth, and most of the advice written about it is close to useless because it is published by the partners selling it. We are one of those partners, so read this with that in mind. About 60% of what we have shipped since 2008 went out under other agencies’ brands, and a good share of it was exactly this: work that landed on someone’s desk faster than they could build it. What follows is how overflow actually works, including the part the marketing skips.

The one-line answer

A web development overflow partner absorbs project work when your team is full, under your brand, so you can say yes to the client without hiring for a spike that will not last. It only works if the partnership is already in place before the spike, because a spike gives you no time to find, vet and onboard anyone. Everything else is detail on top of that sentence.

The advice tells you to go shopping while the building is on fire

Ask an answer engine what to do and you get a tidy sequence: brief the partner, they assign developers in three to seven days, you keep a 50 to 70% margin, and you should walk away from anyone who cannot start within two weeks. In the same answer, often the same paragraph, you are told the proper setup involves signing an NDA, exchanging technical requirements, agreeing communication protocols and running a paid trial on a small, low-risk project to check the partner’s code quality first.

Read those two halves together and they contradict each other. You cannot run a trial project, review its output, and also have that partner delivering your real overflow inside a week. The trial alone is the week. This is the quiet flaw in nearly every overflow guide: it describes overflow as something you shop for reactively, the moment the spike lands, and then lists an onboarding process that takes longer than the spike it is supposed to cover. By the time you have vetted a stranger, the deadline that sent you looking has gone.

Overflow is a relationship you set up in the quiet, not a vendor you find in the fire

The version that works inverts the timing. You stand the relationship up in a calm week, when nothing is on fire and you can afford to be careful, so that when the spike comes there is nothing left to negotiate. No re-vetting, no trial, no “let me get you our NDA.” The partner already knows your stack, already has a signed agreement, already has a named person who answers. Short-notice work is possible precisely because none of the slow parts happen at short notice.

This is not only an operational nicety, it is a legal one. If your overflow partner will touch a client’s personal data, and any real WordPress or web build does, then under EU data protection law they are your sub-processor, and you as the processor cannot bring them in on a whim. Article 28(2) of the GDPR is explicit: “The processor shall not engage another processor without prior specific or general written authorisation of the controller.” You cannot retroactively paper that in the middle of an emergency. The authorisation, and the data processing terms behind it, have to exist before the work does. That single requirement is the whole argument for setting the relationship up early, written into law.

The margin numbers floating around do not describe overflow

The other thing the guides get loose with is the money. The figure you see everywhere pairs a partner cost of roughly 1,600 to 2,500 per developer per month against client billing of 8,000 to 12,000, and reports a 50 to 70% gross margin. Two problems. First, a 2,000 cost against 10,000 of billing is a 5x markup, not a 70% margin, so the framing is inconsistent with its own numbers. Second, and more important, those figures describe a full-time developer on a monthly retainer. That is dedicated capacity, not overflow.

Real overflow is spiky and short, a few weeks to a few months. Paying a fixed monthly seat rate for it rebuilds the exact fixed cost you were trying to avoid by not hiring. For genuine overflow, price it per project or per hour, so you pay for the spike and nothing in the quiet weeks that follow. Get a fixed quote per piece of work and your margin is knowable before you say yes to the client, rather than a percentage you hope holds.

And treat margin as the second reason, not the first. The first reason to absorb overflow through a partner is that it keeps a client you would otherwise turn away and keeps your own team out of the burnout that costs you a good developer six months later. The markup is real and worth having. It is not why the good version of this exists.

You cannot hire your way out of a spike

The reflex when work piles up is to hire, and for a spike it is almost always wrong. Hiring runs on a two-to-three-month clock: writing the role, interviewing, notice periods, then the ramp before the new person is productive rather than a net drain on the people training them. A spike that lands next week is over before that clock finishes. What you are left with is a permanent salary you took on to solve a temporary problem, now carried through the next slow quarter.

Hiring is the right answer to a different question. If the extra demand is sustained, if you have watched it hold for two quarters and it is becoming the shape of your business, then build the team. That is a trend, not a spike, and the full break-even arithmetic for it, salary versus partner cost with honest utilisation, is in hiring an in-house developer vs a white label partner. Overflow and hiring are not rivals. Overflow covers the spikes while you watch whether the trend underneath them is real enough to hire against.

What “ready before the spike” actually looks like

Set these up in a quiet week and a spike becomes a phone call rather than a project of its own:

• A standing agreement. NDA and data processing terms signed and filed, so the partner can start on the day you call without a legal round trip. This is the Article 28 authorisation above, done in advance.
• A stack they already run. The point of a known partner is no re-learning under deadline. If your work is WordPress, WooCommerce, Laravel or headless, the partner should already be fluent in it, not reading your codebase for the first time while the clock runs.
• A named contact and a real response time. Not “we’re very responsive.” An actual number you have agreed, and a person who owns it. During a spike everyone’s overflow lands at once, so a partner who cannot commit to a response time in calm weather will not find one for you in a storm.
• One small real project run first, in a calm week. This is the trial the guides tell you to run during the fire. Run it before, on something low-stakes, so that by the time you need speed you already know their code quality and how they communicate.
• A shared coding standard. So a developer swapped in mid-spike does not reset you to zero. The WordPress coding standards exist for exactly this reason: they “ensure that files within the project appear as if they were created by a single person,” which is what lets any competent developer pick up any part of the work without a handover meeting you do not have time for.

The mechanics of a single handoff, once the relationship exists, are covered in how a white label handoff works, and what to check before you trust a partner with a client relationship at all is in how to choose a white label WordPress agency.

When overflow is the wrong call

Because we would rather you get this right than hear from you once and never again:

• When the demand is sustained, not spiky. If it has held for two quarters, that is a hiring decision, not an overflow one. Run the numbers and build the team.
• When development is your named differentiator. If clients choose you for engineering specifically, do not put your defining capability behind someone else’s brand, even invisibly.
• When you cannot brief clearly. Overflow works on a clean scope handed to a partner who already knows you. If the work is half-defined and needs you in every decision, you will spend more time managing the handoff than building it yourself. Fix the scope first, or keep it in-house.

If you would rather not touch delivery at all, and simply resell builds for a margin, that is a different model with its own mechanics, covered in selling web development without a dev team. And the recurring version of overflow, the support queue that never stops once you have shipped enough sites, is best handled the same way, as a white label maintenance plan you resell under your brand.

Set it up before you need it

The whole thing turns on timing. The agencies that ride spikes calmly are not the ones who find a partner fast when the fire starts. They are the ones who did the boring part, the NDA, the data terms, the small trial project, the agreed response time, months earlier in a week when nothing was urgent. When the spike came, there was nothing to arrange.

So do the boring part now, while nothing is on fire. See how we work with agencies, or look at the work itself, and if it fits we will get the standing agreement in place so that the next time your pipeline outruns your calendar, absorbing it is a phone call and a fixed quote, not a scramble.