The project you won and can’t staff

You won it. The client said yes to a number you were pleased with, the start date is six weeks out, and somewhere between the pitch and the signature it became obvious that the team who will build it does not currently exist.

This is the most common way a good agency gets into trouble, and it has nothing to do with competence. It is arithmetic. Winning work and having capacity are governed by different clocks, and they only line up by accident.

The four options, and what each one costs

Hire

The honest answer when the work is permanent. It is the wrong answer when the work is a project, because the hiring cycle is longer than the delivery window. In the UK you are looking at four to twelve weeks to offer, plus a notice period that is routinely three months for anyone senior. That is your project finished before they start.

And you have converted a project-shaped cost into a permanent one. If the pipeline behind this piece of work is uncertain — and after the last two years, whose isn’t — you have taken on a liability to solve a temporary problem.

Contractors

Fast, flexible, and the default for good reason. The costs are real though. Day rates for senior engineers price a lot of fixed-fee projects out of profit. IR35 has made the admin genuinely unpleasant, and an inside-IR35 determination changes the maths again.

The deeper problem is that contractors are individuals. Three contractors are not a team — they have no shared standards, no shared history and no collective memory of why the code is the way it is. Somebody on your side has to supply all of that, and that somebody is usually the person who is already fully booked.

Push the date

Sometimes correct and always expensive. It spends client goodwill you may need later, and it does not solve the underlying problem: you will win the next thing too, and be in the same position with less credibility.

A delivery partner

A team that already works together, brought in for the project and gone when it ends. Right when the work is a defined block with a deadline. Wrong when you actually need permanent capability, or when the work is too vague to hand over.

It is also the option most likely to have burned you before, which is worth being direct about.

Why the last one went badly

Almost every agency has a story here, and the stories rhyme. The failure is rarely that the engineers could not code.

Each of those is preventable, and none of them is prevented by a lower day rate. They are prevented by what is in the agreement and how the engagement is set up in the first fortnight.

What to ask before you sign

If you take one thing from this, take this list. It is the one we would want asked of us.

1. Who exactly is on this? Names, and a call with them before contracts — not a capability deck. If the answer is “we will allocate from the pool”, you are buying a lottery ticket.
2. What happens when something is ambiguous? A good partner tells you what they assumed and carried on, then flags it at the demo. A bad one stops and waits for you, which quietly makes you the bottleneck you hired them to remove.
3. What does handover include? Get the list before you start: source, schema and migrations, tests, API documentation, deployment notes, runbook, and a walkthrough. Anything not on that list will not exist at the end.
4. Whose IP is it, and when? Assigned on payment, no residual licence back to them, no reuse of client-specific code elsewhere.
5. Are they contractually invisible? Non-circumvention, no attribution without your written agreement, no case study, no logo. If they hesitate here, they are planning to use your client as a reference.
6. Whose tools? Yours. Your repo, your board, your branching model, your definition of done. A partner who insists on their own process is optimising for their convenience, not your delivery.
7. What is the overlap? Three to four hours of genuine working overlap is enough for a standup and a real conversation. Zero overlap means a twenty-four hour round trip on every question, which is how a six-week project becomes ten.

The test that matters more than the rate card

Give them something small first. Two weeks, paid, with a real output — a schema and an integration plan, a spike on the risky part, one complete feature end to end.

You will learn more from that than from any number of reference calls. You will see how they handle an ambiguity, whether their written English survives a client-facing document, whether the code has tests without being asked, and whether they tell you something you did not want to hear.

That last one is the real signal. A partner who agrees with everything in the first fortnight will agree with everything right up until the deadline, and then tell you.

Where offshore genuinely does and does not work

It works when the scope can be written down, when there is real time overlap, and when the partner is a team rather than a staffing pool. Payments, integrations, data pipelines, back-office systems, document processing — work where correctness is checkable and the domain can be learned from the specification.

It does not work when the requirement lives in somebody’s head and emerges through conversation, when the work needs to be in the room with the client’s users, or when what you actually need is a permanent capability rather than a burst of delivery. A partner cannot absorb tacit knowledge you have not written down — and if you have not written it down, that is the project’s bigger problem.

Being straight about that is the point. The agencies we work well with are the ones who came with a defined block of work and a deadline, kept their client relationship entirely, and used us for the part they could not staff in time. That is a narrow, honest use of a delivery partner, and it is the one that tends to survive the project.