How to brief an offshore development team

There are two ways a brief reaches the person who will do the work. It can pass through layers of account management, or it can go straight to the engineer. Having seen both, the difference in outcome is not the quality of the document.

It is worth saying what this guide is not. It is not a template. Templates produce thorough briefs that still fail, because the thing that determines success is not in the document at all. Almost everything below is about what happens after you send it.

The half hour

If you take one thing from this guide: the single best predictor of whether an offshore engagement works is whether somebody on your side has about thirty minutes a day to answer questions.

Not to manage. To answer. “Should a cancelled order still appear in this report?” is a thirty-second question that blocks a day if nobody answers it. A developer with no product context does not stop working. They guess, and plausible code solving the wrong problem is more expensive than no code, because somebody has to find it, understand it and unpick it.

Across our engagements the pattern is stark. The ones with a named person who answers within a day run at close to full velocity. The ones without spend somewhere between a fifth and a third of the available hours on rework or on waiting, and neither party enjoys the invoice conversation that follows.

Three things make the half hour work:

One named person, not a distribution list. A question sent to a group is a question nobody owns. We ask for a name in the kickoff and we put it in the notes.

A channel, not a meeting. Questions arrive when they arrive. A weekly call turns a thirty-second answer into a five-day delay, and by then we have made an assumption and built on it.

Permission to answer. If your named person has to escalate every decision, they are a relay rather than a decision maker and the delay is the same. They need the authority to say “yes, cancelled orders should still appear” without asking anyone.

Everything else in this guide is secondary to that.

What to send

The problem, in a paragraph. Not the solution. “Our quoting tool takes three days because the pricing rules live in a spreadsheet and one person understands them” tells us more than four pages of feature list, because it tells us what success looks like and lets us tell you if the feature list was the wrong shape.

Access to the actual thing. Repository, staging, or a database dump with the sensitive columns nulled. We sign an NDA before any of it. Fifteen minutes in a real codebase beats an hour of description, and every estimate made without it is a guess dressed as a number.

It is also why we will not send a fixed build price without a paid discovery, currently $2,400. Two weeks of reading is what turns a guess into a number, and a fixed price given without it is either padded by 40% to protect the vendor or about to become an argument in month three.

The constraint that is not negotiable. A conference date, a contract ending, a compliance deadline, a fixed budget ceiling. Say it early. It changes the approach, not just the schedule, because a hard date usually means phasing work we would otherwise do in one pass, and phasing decisions are cheap in week one and expensive in week six.

Who decides. One name. Scope decisions made by committee take three times as long and produce something nobody is happy with. If there genuinely are two decision makers, say so and tell us how they resolve a disagreement.

What “done” looks like, ideally as a scenario. “A sales rep can produce a quote for a 200-unit order with the volume discount applied, in under two minutes, and it appears in NetSuite.” That is testable. “Improve the quoting process” is not.

The things that must not break. Every mature system has a handful of behaviours the business depends on and nobody has documented: an export a large customer relies on, a report the finance team runs on the first of the month, an integration that fails silently. Naming three of those is worth more than another page of requirements.

Who else is involved. An in-house developer, another agency, an IT team that controls deployments, a designer. Discovering a second party in week three is one of the more reliable ways to lose a fortnight.

What to leave out

Estimated hours. You are hiring us to estimate. Telling us you think it is forty hours anchors the conversation, and if you are wrong it guarantees an argument later. If you have a budget rather than an estimate, that is different and useful: say the budget.

A solution architecture, unless you have one for a reason. If you have settled on a stack because of an existing team or a platform commitment, say so. That is a constraint and it is genuinely useful. If you settled on it because you read something, let us disagree with you first. Roughly one enquiry a fortnight ends with us recommending something cheaper or nothing at all, and most of those started with a prescribed solution.

Every edge case up front. Send the main path and the two or three edge cases carrying money or risk. The rest surface naturally and cost less to handle when they do, because by then we understand the domain.

Long “about our company” material. We will read your site. What we need is the problem.

A non-disclosure agreement as the first message. We will sign one, gladly, and it takes a day. Leading with it before there is anything to discuss just adds a day to the front of the conversation.

The kickoff that works

An hour, with the engineer who will do the work, not a salesperson. If the person on your kickoff call is not the person who will write the code, ask why, because that gap is where most offshore disappointment originates.

The agenda that has served us best:

1. Walk the current process, on screen. Not the wireframe of the future one. Show us somebody doing the job badly today. Ten minutes of that replaces pages of specification, and it is where we find the constraints nobody thought to mention.
2. Say what has been tried. Especially what failed. “We tried a plugin and it fell over at 5,000 rows” saves a week and tells us the shape of the data.
3. Agree the first slice. Something demonstrable inside two weeks. Not a scaffold, not a login page. Something a real user could click that does something real.
4. Agree how questions get answered. A channel with a named person and a rough expectation. Not a weekly call.
5. Agree what happens when we are blocked. Our default: make the smallest reasonable assumption, write it in the channel, keep moving, flag it in the Friday demo. Some clients want us to stop and wait instead. Both are fine. Deciding in advance is what matters, because the alternative is discovering your preference after we have guessed wrong.
6. Agree what we do not do. Ten minutes on scope boundaries at the start prevents the most common source of friction later.

Working across four hours of overlap

We get roughly four hours with New York and five and a half with London. That shapes things more than most briefs anticipate, and it can be made to work well enough that clients stop noticing it.

A normal day on a US engagement looks like this:

Four practices make that comfortable:

Front-load questions. Anything ambiguous gets asked at the start of our day, which is your previous evening, so an answer arriving during your morning does not cost us a day.

A written handover beats a standup. Ours lands before the client’s morning: what moved, what is blocked, what needs a decision. Asynchronous by default means the overlap window goes on things that genuinely need a conversation.

Demos on the same day each week. Friday works, because it forces the week to produce something clickable. If a week produces nothing demonstrable you find out that Friday, rather than at the end of the month.

Do not schedule the overlap solid. If all four hours are meetings, no work happens in them. Two hours of the window kept clear is a working agreement worth making explicit.

What a good handover actually contains

Four sections, no more than a screen, written by the engineer rather than a manager:

• Moved: what is done and where to look at it.
• Blocked: what is stopping, who can unblock it, and by when it starts costing time.
• Decisions needed: the actual question, with the options and our recommendation, so it can be answered with a single word.
• Assumed: anything we guessed at and proceeded on, so you can correct it cheaply today rather than expensively in a fortnight.

That last section is the one most teams leave out and the one that prevents the most rework.

The first two weeks, and what to watch

If you have never worked with an offshore team before, here is what a healthy start looks like. It is also, deliberately, what our ten working days risk-free period is designed to make visible.

By day two: environment running locally, repository access working, first questions asked. Questions on day two are a good sign. Silence is not.

By day three: the first pull request, however small. A tiny fix merged early proves the whole pipeline works, from access to review to deploy.

By day five: something demonstrable, and a handover you can actually follow. You should be able to read Friday’s handover and know what happened without asking.

By day ten: tickets closing without questions about how the deploy works, and questions that are about the domain rather than the setup. That shift, from “how do I run this” to “should a cancelled order appear in this report”, is the signal that ramp-up is done.

If day ten still looks like day two, something is wrong and it is better to say so then. That is what the risk-free period is for, and it cuts both ways: we would rather absorb two weeks than spend three months on a bad fit.

The failure modes, in order of frequency

Nobody answers questions. Covered above. It is the big one, and it accounts for more failed engagements than every technical factor combined.

The brief describes a solution, and the solution is wrong. We build exactly what was asked and it does not solve the problem. This is why we push for the problem statement, and why we will say “we think that is the wrong approach” before quoting rather than after.

Scope moves without anyone pricing it. Small additions absorbed silently, then argued about at handover. Anything changing scope should get a written price and schedule impact before code, and you approve or decline. Not bureaucracy. It is what stops the relationship souring in month three, and it protects you as much as us.

The engineer changes. Somebody you interviewed gets replaced by somebody you did not. This is the single most common complaint about offshore agencies, and it is a structural choice rather than an accident: it happens when a vendor optimises utilisation across a bench. Ask what happens if your developer is reassigned, and get the answer in the contract. Ours says the same person for the engagement, named in the contract, with a replacement inside five business days and a paid week of overlap if the fit is wrong.

Nobody owns the environments. Staging drifts from production, deploys need a person who is asleep, and a two-hour task waits a day. Unglamorous, and it quietly costs more than any of the above except the first.

Review responsibility is unclear. If nobody on your side reviews and nobody on ours does either, quality is whatever one person felt like that week. Our work is reviewed by a second engineer before it reaches you. Ask whoever you are speaking to whether theirs is, and what happens when the reviewer disagrees.

What to put in the contract

Short list, and each item exists because its absence has caused a problem somewhere:

• Named engineer, and what happens if they are replaced.
• Notice period. Ours is thirty days, month to month after the trial, no annual minimum.
• IP assignment on commit, not on final payment. An assignment clause rather than a licence.
• Who owns the accounts. Repository, cloud, domain and CI should be in your name from day one, with us as collaborators.
• What happens at the end. Handover documentation, a walkthrough, and access removal. Agree it at the start, when nobody is annoyed.
• A defect warranty window on fixed-scope work. Ours is thirty days after sign-off.

A brief that would get a good estimate from anyone

Short is fine. This shape works:

We run a Laravel 9 app for field service scheduling, about 60 tables, one in-house developer who leaves in six weeks. It works, but the scheduling logic is entangled with the invoicing and we cannot change one without breaking the other.

We need someone to take it over, get it documented and tested, then split those two. No hard deadline, but our developer leaves on the 14th and after that nobody knows the system.

Repo access available under NDA. Decision maker is me. Budget is roughly one developer for six months.

Nine sentences, and it contains the problem, the constraint, the risk, the access, the decision maker and the budget shape. We could quote from that. More importantly, we could tell you if we were the wrong people for it.

Compare it with the version we receive more often:

Looking for a PHP developer to help with our platform. Need someone experienced with Laravel, MySQL and APIs. Please send your rates and availability.

That is not a bad brief because it is short. It is a bad brief because nothing in it can be estimated, and the only honest reply is a list of questions. If you send the first version you will get a considered answer within a day. If you send the second you will get boilerplate from everyone, and you will end up choosing on price because nothing else is comparable.

Common questions

How much of my time will this actually take?

Around thirty minutes a day once things are settled, and more like an hour a day in the first fortnight. If that is genuinely not available from anybody, say so before starting. It is a reason we occasionally decline work, and it is a kinder conversation to have in week zero.

What if I do not have a technical person to review the work?

Then that review needs to be part of what you buy. Ours is reviewed internally by a second engineer, so you are not the last line of defence. What you still own is whether the thing built is the thing you wanted, and nobody can do that part for you.

How detailed should the first brief be?

A page. If you can state the problem, the constraint, the decision maker and what “done” looks like, that is enough to have a real conversation and get a sensible range. Detail beyond that is better produced together than written alone, because half of it will turn out to be wrong.

Should I start with a small paid trial?

Yes, and we structure it that way by default: ten working days on real tickets in your tracker, and you walk away owing nothing if it is not right. A trial on real work tells you far more than a longer interview process, and it tells us whether the half hour a day exists.

What if we need to change direction mid-project?

Then we reprice and you decide. Changing direction is normal and it is not a problem in itself. What causes damage is changing direction without anyone writing down what it costs, and then discovering the disagreement at handover.