The quality of the quotes you get back depends heavily on what you send out. A vague request gets either a vague estimate or a padded one, because the studio has to cover everything it cannot see. A clear brief gets you numbers you can compare, and it shortens the first meeting from an interrogation to a conversation.
You do not need technical knowledge to write a good brief. You need to describe your business problem clearly. Here is what we look for.
Start with the problem, not the solution
The most useful paragraph in any brief describes what is going wrong today and what it costs you. "Our dispatchers spend the first two hours of every day rebuilding the schedule from texts and voicemails, and things still get missed" tells a studio more than three pages of feature lists.
Describe the current process step by step, including the workarounds. Who does what, in which tool, and where does it break down? The workarounds are often where the real requirements are hiding.
Say who will use it
List the kinds of people who will touch the system: customers, field staff, office staff, managers, an outside partner. For each, a sentence or two on what they need to do and how often. Say whether they are on phones, desktops, or both.
The number of user types is one of the biggest drivers of cost, so this section does a lot of work.
Describe the must-haves, then stop
Write down what the first version has to do to be worth launching. Then write a separate list of things you would like eventually. Keeping these apart is the single most helpful thing you can do for an estimate.
A good test for the must-have list: if the system launched with only these things, would people use it instead of what they use now? If yes, the list is complete. If you keep adding to it, you are describing version three.
List what it has to connect to
Name every system the new software needs to read from or write to: accounting, payroll, CRM, email, payment processor, an industry-specific platform, a database someone built years ago. Include the product names and, if you know them, the versions.
If you are not sure whether something has a way to connect, say so. That uncertainty is exactly what a studio needs to price.
Share the constraints
- Budget range. Many owners hesitate here. Sharing a range does not mean a studio will spend all of it; it lets them propose the right shape of project instead of guessing. A studio that quotes double your range has told you something useful early.
- Timing. Is there a real deadline, such as a season, a contract, or a launch event? Or is it "as soon as reasonable"?
- Rules you have to follow. Industry regulations, data you are obligated to protect, accessibility requirements, anything a lawyer or auditor will ask about.
- Who decides. Name the person who can approve scope and answer questions. Projects stall when nobody owns decisions.
Attach examples
Screenshots of the spreadsheets you use today. Sample documents, reports, and forms. Links to products you like and a line on why. A photo of the whiteboard. Real artifacts remove guesswork that no description can.
What to leave out
You do not need to choose a programming language, a database, or a hosting provider. You do not need wireframes, although rough sketches are welcome. Detailed technical specifications written before talking to a studio often lock in decisions that should have been discussed.
A simple outline
- The problem today and what it costs.
- How the current process works, step by step.
- Who will use the new system and on what devices.
- Must-haves for the first version.
- Nice-to-haves for later.
- Systems it needs to connect to.
- Budget range, timing, and constraints.
- Who makes decisions.
- Attachments and examples.
Two to four pages is plenty. Longer is fine if the extra pages are real examples rather than more features.
What should come back
A good studio will respond to a good brief with questions, not just a number. Expect them to push on the must-have list, ask about the riskiest integration, and possibly suggest a short paid discovery phase before a fixed estimate. That is a sign they read it.
If you have a brief ready, or half of one, send it to us. We are happy to tell you what is missing, even if we are not the right studio for it.