How to brief a development partner for a first project

TL;DR: The quality of a first project with a new development partner is shaped largely before any code is written, and the brief is the biggest part of that. A client’s document describes what the client wants built, but a partner also needs the context behind it. This guide covers what a good brief contains beyond scope, three things worth agreeing on day one and a checklist a digital agency can adapt for each new project.

The first project with a new development partner tends to set the tone for what follows. If it goes well, the relationship gets easier with every brief. If it goes badly, both sides can spend the next few projects managing around it.

Much of what shapes the outcome happens in the first week, often before the partner has written a line of code, and the brief is the biggest part of it.

A client’s document is the natural place to start. It already exists, the client has already described what they want, and forwarding it with a short covering note is efficient. But it was written for a different purpose. It describes what the client wants built, while a development partner also needs to know what shapes how it should be built, and much of that sits with the agency rather than in the document.

Why is the client's document a starting point rather than a brief?

A client's document rarely includes the history of the project, the options already considered and discarded, the internal politics that shape what will and will not be approved, or the things the client cares about but has never thought to write down. The digital agency usually knows much of this. The partner does not, unless someone tells them.

Length is not the answer either. Some of the best briefs are two pages long and some of the weakest run to forty. What matters is whether the brief contains what the partner actually needs.

What does a good brief contain beyond scope?

The client context that shapes decisions. Who the client is, what their business does, who will use what is being built and what matters most to them. For example, a partner who knows the client's customers are mostly older and use the platform on mobile will make better choices than one working from a feature list alone.

What has already been rejected, and why. This is easy to overlook and one of the most valuable parts of a brief. If the client has already tried an approach and abandoned it, or ruled out a design direction, the partner needs to know before suggesting it again. Few things cost goodwill faster in a first project than a partner confidently proposing something the client has already said no to.

Who has final say, and how quickly they respond. Every project needs a named decision maker on the client side, and the partner needs to know who that is and how long decisions usually take. A partner that knows decisions take a week can plan around it, while one that assumes they take a day is likely to stall. The useful thing to write down is the real answer: hours, days or a week.

Which constraints are real and which are assumed. A fixed launch date tied to a campaign is a real constraint. A technology choice mentioned once in a meeting may not be. Separating the two gives the partner room to recommend better options where it matters and to hold firm where it does not.

What success looks like to the end client. Not what the specification says, but what would make the client genuinely pleased at the end of the project: faster onboarding for their customers, fewer support calls. a board presentation that goes well. When the partner knows the outcome the client is buying, the small decisions along the way tend to point in the right direction.

What is worth agreeing on day one?

An escalation route. Who the partner contacts when something needs a decision, who they contact if that person is unavailable and how quickly a response is expected, written down rather than assumed.

How problems get raised. It helps to agree that problems are raised as soon as they are spotted, before there is a solution, rather than once they have been fixed or have become serious. Agreeing this explicitly removes the hesitation that can stop people raising concerns early in a new relationship.

What happens when scope moves. Scope often does move. The question is whether there is an agreed way of handling it: how a change is requested, how its effect on time and cost is assessed and who approves it. Agreeing that before the first change arrives makes it a routine conversation rather than a potential dispute.

A reusable briefing checklist

Before sending a brief to a development partner, a digital agency can check it against these points. Not every project will need all thirteen, so treat it as a prompt rather than a form.

About the client

1. Who the client is and what their business does
2. Who will use what is being built and how
3. What matters most to the client, in their words

About the project

4. What is being built and why now

5. What has already been tried, considered or rejected, and why

6. Which constraints are fixed and which are flexible

7. What success looks like to the end client, beyond the specification

About decisions

8. Who has final say on the client side

9. How quickly decisions usually arrive

10. Who the partner should contact at the agency, and the backup if they are unavailable

About working together

11. How and when problems should be raised

12. How scope changes will be requested, assessed and approved

13. How the client relationship is managed, and what the partner should and should not say to the client directly

A brief that covers the points that matter for the project does not need to be long.

Frequently asked questions

What should a brief to a development partner include? Beyond the scope of work, a good brief includes the client context that shapes decisions, what has already been rejected and why, who has final say and how quickly they respond, which constraints are real and which are assumed, and what success looks like to the end client rather than in the specification.

Should a digital agency forward the client’s brief to a development partner? It is a useful starting point but often not enough on its own. The client’s document describes what the client wants built. A development partner also needs the history, context and decision-making information that the agency holds and the client’s document usually leaves out.

How long should a development partner brief be? Length matters less than coverage. A two-page brief that includes the right context can serve a partner better than a forty-page document that does not. The checklist above is a more useful test than word count.

What should a digital agency agree with a new development partner at the start? Three things are worth agreeing: an escalation route with named contacts and response times, an agreement that problems are raised as soon as they are spotted rather than once they are solved, and a clear process for handling scope changes.

Why can first projects with a new development partner go wrong? A common reason is that the partner did not have the context it needed from the start. That usually traces back to what was, or was not, in the original brief, which is why the brief is worth the time.

How Aecor helps digital agencies

We work with digital agencies as an embedded development partner. If you have a live brief with a technical build in it and would like to talk through how to brief it, we are happy to have a free 30-minute call.

Book a free 30-minute call