Like Uber, but for... How to write a software project brief

Every software project starts with a brief. Some start with a sentence that has been mistaken for a brief. In our line of work, the most common one is short, confident and contains a ride-hailing company.

“We need something like Uber, but for dog groomers.”

We have nothing against dog groomers. We have nothing against Uber. We just have questions - about forty of them - and the first one is always the same: which part of Uber? The map? The payments? The surge pricing? The marketplace behind it, which is really two apps, a dispatch system and a payment system pretending to be one? Or just the little car moving across the screen, because it looks nice?

This is a field guide to the briefs we meet in the wild, why each one makes an accurate estimate impossible, and what to write instead. There’s a template at the end. You can copy it. Nobody will know.

Species 1: The one-sentence brief

Natural habitat: a contact form, a LinkedIn message, a voice note recorded while parking.

“Need app for business, how much?”

This is the software equivalent of calling a builder and asking how much a house costs. The honest answer is somewhere between a garden shed and a hospital. Any studio that replies to a single sentence with a single number is either psychic or planning to make up the difference later - in a change request, with interest.

The one-sentence brief isn’t wrong, though. It’s just the first sentence. We genuinely like getting them; most good projects start exactly like this. The trick is knowing it opens a conversation, not a quote.

Species 2: The 80-page committee brief

Natural habitat: a shared drive, filed as FINAL_v7_reallyfinal_JM-edits.docx.

Written by six departments over nine months, it contains a twelve-page company history, a glossary, a RACI matrix, three contradictory definitions of “customer” and, on page 61, wedged between a compliance appendix and a stock photo of a handshake, the one requirement that actually matters.

Every department got its feature in. None of them was allowed to say which ones are optional. So everything is priority one, which means nothing is.

The length isn’t the problem. The problem is that a brief written to keep everybody happy describes a political compromise, not a product. We’ll read all 80 pages - we really will - and then we’ll ask which three things the system must do on launch day. The silence that follows is usually the most informative moment of the whole project.

Species 3: The competitor screenshot

Natural habitat: an email with no text and one attachment, IMG_4471.png.

“Like this, but better.”

A screenshot shows what a product looks like. It says nothing about the admin panel behind it, the payment provider, the five integrations, the support team, or the years of polishing that made it feel that simple. Photographing the front of a building doesn’t get you the plumbing.

Screenshots are useful, though. Send them - with one line each on what you like. “Checkout fits on one screen” is a requirement. “Like this” is a mood board.

Species 4: “The budget is flexible”

Natural habitat: the first call, delivered with a confident smile.

Translation: there is a budget, it is not flexible, and we’ll find out the exact number by proposing something above it.

We understand why people hide the budget. The fear is that a studio will simply estimate up to whatever number it hears. But without a range we’re designing in the dark. A booking system for twenty thousand can be a solid, focused tool. A booking system for two hundred thousand is something else entirely. Both are good answers - to different questions. A range lets us propose the best thing that fits inside it, instead of a beautiful plan you’ll politely decline.

What actually goes into a good software brief

Here’s the part under the jokes. A brief that gets you an accurate estimate is usually one or two pages long and answers seven questions.

1. The problem, not the solution. “Our dispatchers spend two hours a day phoning drivers to confirm pickups” beats “we need a mobile app with push notifications”. The first lets us find the cheapest thing that solves it - which might be an app, a text message, or a shared spreadsheet with a better formula. The second locks you into an app before anyone asked whether an app was the answer.

2. Who the users are. Office staff on desktops? Field workers with gloves and patchy signal? Customers who’ll open it once a year? Ten users and ten thousand users are different systems at different prices, even when the screens look identical.

3. The three things it must do on day one. Not twenty. Three. Everything else goes on a “later” list, which isn’t a graveyard - it’s phase two. No other question does more for an estimate than this one.

4. Existing systems it has to talk to. Accounting software, the old ERP, a payment provider, a CRM, the spreadsheet everybody secretly depends on. Integrations are where estimates quietly go to die, so list them early, even if you’re not sure they matter. “We use some kind of invoicing thing, Dave knows” is a perfectly good place to start.

5. The deadline - and why. “Before the trade fair on 14 March” is a deadline. “ASAP” is a feeling. Knowing the reason lets us say what can ship by that date and what can follow a month later without anyone noticing.

6. A budget range. See Species 4. A range is enough. “Between 15 and 30 thousand” tells us what fits, what doesn’t, and where the trade-offs are.

7. What success looks like. Fewer phone calls. Orders processed in minutes instead of hours. A launch that doesn’t need a press release, just a quiet Monday. If you can describe how you’ll know it worked, we can build towards it - and you’ll have a tiebreaker every time two features compete for the same week.

That’s it. Notice what’s missing: a technology stack, a database, wireframes and the word “blockchain”. If you have opinions on those, great, put them in. But that part is our job, and most briefs are better without it.

Why this gets you a better estimate

Software estimates go wrong for one reason more than any other: the thing that was estimated wasn’t the thing that got built. Somewhere between the brief and the launch, the “simple booking form” grew a calendar, reminders, cancellations, refunds and a staff rota. Each of those was obvious to somebody. None of them was written down.

A brief that names the problem, the users, the must-haves and the integrations doesn’t stop scope from moving. It just means everyone can see it move, and decide on purpose.

Whether you’re planning a web application, a mobile app or a replacement for the ERP that’s held together by one heroic Excel file, the questions are the same.

The copy-paste brief template

Fill in what you know, leave blank what you don’t. Blank is information too.

PROJECT BRIEF

The problem:        What hurts today, in one or two sentences.
Users:              Who, how many, on which devices.
Day-one must-haves: 1.
                    2.
                    3.
Later, maybe:       The nice-to-haves. Be honest.
Talks to:           Existing systems, tools, spreadsheets.
Deadline:           The date, and why that date.
Budget range:       From ... to ...
Success means:      How we will know it worked.
Not "like Uber":    Unless it actually is like Uber.

The short version

A good brief isn’t long or polished. It’s honest about the problem, specific about the first three things, and upfront about time and money. Write that, and whoever you send it to can give you a real number instead of a range wide enough to park a bus in.

And if all you have right now is the one sentence - that’s fine too. Send us the sentence. We’ll bring the forty questions. We promise to ask about Uber only once.