Working together · 6 min read
How to brief a software studio and get an accurate quote
Published 4 August 2026 · Updated 14 September 2026 · By Sam Fourie, Niddo
A good brief is one to three pages: the problem, who has it, the one workflow that solves it, what exists today, what must integrate, what is out of scope, and the constraints (deadline, budget range, compliance). It does not need wireframes or a feature list. A studio that receives it can quote in days rather than weeks, and the quote will be right.
What a brief is for
A brief is not a specification. Its job is to let a studio understand the business problem well enough to ask good questions and propose the right shape of solution. Feature lists do the opposite: they lock in decisions before anyone has understood the problem, and they get priced line by line whether or not the lines make sense together.
The eight things to include
- The problem, in one paragraph. What is slow, manual, error-prone or impossible today, and what it costs you.
- Who has it. The people who will use the software, what they do all day, and how many of them there are.
- The one workflow. The path from the start of the job to the result, as it really happens, including the spreadsheets and the messages.
- What exists today. The tools, systems and data you already use, and which of them must stay.
- What must integrate. Payments, accounting, calendars, booking channels, identity checks: anything the software has to talk to.
- What is out. The things you can imagine wanting but do not need for the first version. This is the most valuable section and the one most people leave out.
- Constraints. A deadline and why, a budget range, and any compliance or data rules (POPIA, GDPR, industry regulation).
- How you will know it worked. One or two measures: hours saved, bookings handled without a phone call, days to invoice.
What to leave out
- Feature lists. Describe the workflow and let the studio propose the features.
- Screen-by-screen descriptions. Design is the studio's job; you will react to real screens far better than you can specify them.
- Technology choices, unless they are genuine constraints (an existing platform, a compliance rule, a team that must maintain it).
- Estimates of effort. You are buying that judgement; do not anchor it.
A worked example
Problem: we run 40 guided tours a week and every booking arrives from one of three booking sites, gets copied into a spreadsheet, scheduled in a shared calendar and staffed over WhatsApp. It takes one person most of their day and mistakes reach guests. Users: two coordinators and about 25 freelance guides on their phones. Workflow: booking arrives, becomes a departure, a qualified guide is assigned, guests get their tickets and reminders, the guide runs the day, we pay guides from attendance. Existing: the three booking channels, Google Calendar, a payroll spreadsheet. Must integrate: the booking channels and calendar. Out of scope for v1: customer-facing booking, invoicing, multi-language. Constraints: live before the summer season in 8 weeks; budget around $30,000; guest data under GDPR. Success: coordinators spend under an hour a day on staffing; zero missed departures.
That brief is a real shape: it is close to how One Journey started, and it is enough to scope, design and price a first release.
What happens next
A good studio replies with questions, not a price. Expect a scoping call, then a written scope that says what is in and out, a milestone plan and one figure. If the first reply is a price with no questions, the price is a guess.
Red flags in the replies
- A quote without questions.
- Hourly rates with no estimate of the total, or an estimate with no scope attached.
- No mention of design, testing or what happens after launch.
- Ownership left unspecified, or code that stays in the studio's accounts.
- A timeline that starts with a long document phase before you see anything working.
Briefing Niddo
Send the eight points above, in any form, to our contact page or bring them to a call. We come back with questions, then a plan, a timeline and a price.
Questions
People also ask.
Do I need a specification before contacting a studio?
No. A brief is enough. The specification is something a good studio writes with you during scoping, and it should be yours to keep whatever you decide.
Should I share my budget?
Yes, as a range. It changes what gets proposed: the same problem can be solved as a $15,000 first version or a $100,000 platform, and the studio needs to know which conversation you are having.
What if I only have an idea?
Write the problem and the people first; the workflow will come out of a scoping conversation. Many products we build started as a single paragraph.
How long does a quote take?
From a good brief, a scoping call within days and a written scope and price within a week or two, depending on how many questions it raises.