Many business owners put off a software or web project because they don’t know how to explain it. They worry they’ll use the wrong words, miss something important or get quoted a fortune for something simple. You don’t need technical language to brief a developer well.
Here’s the good news: a developer doesn’t need you to be technical. They need you to be clear about your business, your problem and what success looks like. The technical decisions are their job. Explaining the business is yours.
A good brief saves money, because it reduces guesswork. Guesswork is where budgets go to die.
Start with the problem, not the solution
When you brief a developer, the most useful thing you can write is a plain description of what’s going wrong now. “Our engineers write job notes on paper, the office types them up the next day, and invoices go out a week late” is far more helpful than “we need an app”.
Describing the problem leaves room for the developer to suggest a better or cheaper approach. You might find a simpler answer than the one you had in mind.
What to include when you brief a developer
- About the business. What you do, roughly how big you are and who your customers are. A few sentences is plenty.
- The problem. What’s happening now, what it costs you in time or money, and who it affects.
- Who will use the system. Staff, customers, both? How many? On phones in a van or on desktops in an office? This changes a lot.
- What it needs to do. Write this as a list of things people should be able to do. “An engineer can mark a job complete and add photos.” “The office can see all jobs completed today.” These are sometimes called user stories, but plain sentences are fine.
- What it connects to. List the tools you already use, such as your accounts package, email platform, calendar or website. Include names if you know them.
- Must-haves versus nice-to-haves. Be honest. This is the single most useful thing for keeping cost under control.
- Budget and timing. Give a range, even a rough one. And say if there’s a real deadline, like a busy season or a contract start.
- Examples. Screenshots of tools you like (or hate), with a line on why. This is often clearer than any description.
You don’t need the right technical words. You need the right business details, written down before the first meeting.
Why you should share a budget
Lots of people keep their budget secret, hoping to get a lower quote. In practice it tends to backfire. Without a figure, a developer has to guess whether you want a basic version or a polished one, and quotes end up all over the place.
A range lets them tell you what’s realistic for that money and what would need to wait for a later phase. That’s a much more useful conversation.
What to leave out
- Technology choices you’re not sure about. Don’t specify a programming language or platform unless you have a genuine reason, such as an existing system that has to be extended.
- Every possible future idea. Mention your longer-term plans in a short paragraph, but keep the main brief focused on version one.
- Vague adjectives. “Modern”, “user-friendly” and “intuitive” mean different things to everyone. Show examples instead.
Questions to ask the developer back
The way you brief a developer is only the start of a conversation. When you get responses, ask:
- What have you assumed that isn’t in my brief?
- What would you cut to bring the cost down?
- Who will own the code, the data and any accounts once it’s built?
- How will we test it before it goes live?
- What does support look like after launch, and what does it cost?
- How will you keep me updated during the build?
Their answers will tell you as much as the quote. A developer who asks lots of questions back is usually a good sign. One who quotes instantly for something complex, less so.
Comparing quotes fairly
Quotes for the same brief can vary widely, and that’s normal. They’re rarely pricing identical work. Before you compare figures, check that each one covers the same scope, includes testing, includes hosting or not, and says what happens with changes. A cheaper quote that excludes half of what you need isn’t cheaper.
A template to get you going
Open a blank document and add eight headings: about us, the problem, users, what it must do, connections, must-haves and nice-to-haves, budget and timing, examples. Spend an hour filling it in. It doesn’t need to be polished. It just needs to be honest.
Where to take it next
If you’ve got a rough brief and want a second pair of eyes, we’re glad to read it and ask the awkward questions early. For software projects that’s our custom development team, and if the brief is really about a website, start with website design and development.
