Writing a brief¶

Your brief is the only thing students see before they choose. It has to make them want the project, tell them honestly what the hard part is, and leave them room to design a solution — in about a paragraph.

What the published briefs have in common¶

Almost every published brief follows roughly the same shape.

A short, memorable title — most are two or three words ("Draught Detective", "Digging for Data", "Wise Banking").
A named client: one person, plus the organisation they represent.
Roughly 100–200 words of prose, in a single paragraph. No headings, no bullet lists, no requirements tables.
Opens with the context and the problem, in plain language a second-year student can follow without domain knowledge.
States what the team should build, usually as "Your task is to…" or "The goal of this project is…".
Names the technical challenge — the interesting, hard part that makes it worth seven weeks.
Leaves the design open. Almost none of them specify a language, framework or architecture.

Four things worth doing¶

Aim at the hard bit, not the whole product

The briefs that work describe one substantial technical challenge, not a full product backlog. If your brief could plausibly take a startup a year, narrow it until it could take a small team seven weeks.
Make room for everyone to contribute

Every member must make a substantial technical contribution and gain real programming experience. Briefs that split naturally into components — an interface, a data pipeline, a model, a test harness — allocate more easily than a single monolithic algorithm.
Say what you can supply

If the project depends on data, credentials, API access, documentation or hardware, mention it. Access that has not been approved is one of the most common risks teams report in week 1.
Leave the technical approach open

There are very few constraints on the technical approach teams take, and they are free to use open-source tools and new languages. Specify a stack only where the project genuinely requires it.

The shape, annotated¶

This is Draught Detective, from a published set, broken into the four moves almost every successful brief makes.

Move	Example
Title	Draught Detective — two words, memorable, hints at the problem without explaining it.
Client	Fran Sutton, Cambridge Carbon Footprint — a named person and the organisation they represent.
Context	"A key priority in making homes more energy efficient is to find and plug air draughts…" — the problem, in language a second-year needs no domain knowledge to follow.
The build	"A cheap and easy phone app could help the builder to setup and calibrate the equipment, then provide practical guidance to prioritise the most urgent repairs…" — what to make, without dictating how.

Reading the published briefs is the best preparation for writing one — see the 2026 design briefs and the 2025 and 2024 sets.

What makes a brief hard to work with¶

A product backlog, not a project

A list of twelve features reads as a contract. Teams then spend Meeting 2 negotiating it down, and finish feeling they failed. Describe one substantial challenge instead.
Dependencies you can't actually clear

If the project needs data or system access that requires approval you don't control, the team can lose weeks. Either secure it before the brief goes out, or design the project so it isn't blocking.
A prescribed architecture

Naming the framework, database and deployment target removes most of the design work — which is the part being assessed. Constrain only what genuinely has to be constrained.
A single indivisible problem

Every member must make a substantial technical contribution. A brief that is one tightly-coupled algorithm is hard to share out; one with distinguishable components is much easier.

Sending your brief in¶

Where it goes

Email the group project address so it reaches the whole organising team. Ask them for the current cut-off date and any format they prefer: group-project@cl.cam.ac.uk.