How to write a software brief a studio can quote A fill-in checklist, a worked example and a template to copy

Why does the brief matter so much?

A quote is a guess about time. The less a studio knows, the wider it has to make the guess, or the more it has to pad it. A clear brief gets you a tighter range, fewer emails back and forth, and a better sense of which studios understood you.

It helps you too. Writing it down is often where you notice that two features contradict each other, or that the real first version is smaller than you thought.

What should a software brief include?

Ten things. A sentence or two on each is enough to start. Where you don't know, write "not sure yet": that's useful to a studio too.

1. The problem, in one line

   Who has the problem, and what it costs them today in time, money or patience.

   For example: Clinic receptionists spend most of Monday morning rebooking missed appointments by phone.

2. Who will use it

   The main kinds of user, and roughly how many at launch and in a year.

   For example: Patients booking on their phones; two or three staff managing the diary on a laptop.

3. What they must be able to do in version one

   Five to ten must-haves, written as things a person does rather than screens.

   For example: A patient can see free slots, book one and get a reminder the day before.

4. What can wait

   Nice-to-haves for a later version. This is where most of the savings are.

   For example: Online payment, a loyalty scheme, a second language.

5. Platforms

   iOS, Android, web, or not sure. Say where your first users already are.

6. What already exists

   Designs, a prototype, a live product, the spreadsheet the team uses today, any code, and who owns each.

7. Other systems it has to work with

   Payments, CRM, calendar, accounting, single sign-on, your own API. Name the actual products if you know them.

8. Constraints

   Real deadlines and why they're real, regulations, where data must be stored, devices it must run on.

9. Budget and timeline

   A range is fine. It tells the studio which size of the idea to propose.

10. How you'll know it worked

    One or two measures you could check three months after launch.

    For example: Half of all bookings come through the tool, and Monday rebooking takes under an hour.

What makes a brief hard to quote?

• Describing a solution instead of the problem. "We need an AI chatbot" is harder to price than "customers wait two days for answers to the same ten questions".
• A feature list with no priorities. Without a line between must-haves and later, a studio has to price everything.
• "Like Uber, but for…" on its own. Say which part of the comparison you mean: the map, the payments, the matching?
• Leaving out the budget. You'll get proposals for the wrong size of project, and lose a week finding out.
• Leaving out what already exists. A live product with real users changes the plan more than almost anything else.

What does a filled-in brief look like?

Here's the level of detail that's enough for a first conversation. The clinic is made up.

Notice what isn't there: no screen-by-screen design, no technology choices. Those are the studio's job, and a good one will ask before it assumes.

Is there a template I can fill in?

Copy this into a document or an email, or download it as a text file. Replace the hints in brackets as you go.

What happens after I send a brief?

At Dayframe, the brief at the bottom of this page asks the same questions in three short steps: what you're making, where it stands (with budget and timing), and how to reach you. Put the one-line problem in the description and add a link to your full document if you've written one.

Replies within one working day, from someone who'll work on it, with questions or next steps. If it's a fit, the usual next step is a 2 weeks scope sprint that ends with a clickable prototype and a fixed quote. If you'd like a rough range before writing anything, the cost estimator gives one in a minute.