Most people who come to us know exactly what they want the software to do. What they are not sure about is how to say it in a way a developer can price.
That gap costs money. A vague brief gets vague quotes, the quotes are not comparable to each other, and the project starts with two different pictures in two heads. Here is what to write down first.
## Start with the job, not the features
Write one sentence that says what the software has to achieve. Not what it should look like, not what buttons it needs. The job.
“Our customers book appointments by calling us, and we lose bookings after hours” is a job. “We need a booking system with a calendar view and SMS reminders” is a solution you picked before anyone looked at the problem. You might be right. But if you lead with the solution, nobody checks whether something simpler would have worked.
## Describe what happens today
This is the part people skip, and it is the part that changes estimates the most.
Write down how the work gets done right now, step by step, including the parts that are embarrassing. The spreadsheet that three people edit. The WhatsApp group where orders actually get confirmed. The one person who knows how the pricing works.
Nobody is judging the mess. The mess is the specification. Software that ignores how the work actually happens gets built, paid for, and then quietly abandoned while everyone goes back to the spreadsheet.
## Say what “done” looks like
Pick something you can check without asking a developer. “A customer can book a slot and we get an email” is checkable. “The system is user friendly” is not.
Two or three of these are enough. They become the thing you both point at when the question is whether the work is finished.
## List what must not change
Every project has fixed points. The accounting software you are not replacing. The supplier that sends you a CSV in a format you cannot control. The invoices that have to keep their current numbering because your accountant needs it that way.
These are cheap to work around if they are known at the start and expensive to discover halfway through. Write them down even when they feel obvious.
## Give a budget range
People hold this back because they think naming a number means paying that number. In practice the opposite happens. Without a range, you get a quote for someone’s guess at what you can afford, and you cannot tell whether it is good value or not.
With a range, a serious developer tells you what fits inside it, what does not, and what they would build first. That conversation is worth more than the quote.
The same goes for deadlines. “We need it before the season starts in March” tells us what to cut. “As soon as possible” tells us nothing.
## What you do not need to decide
You do not need to choose a programming language, a database, or a hosting provider. If a brief specifies those, it usually means someone was told to specify them, and it narrows the quotes you get for no benefit.
You also do not need a full feature list. A long list of features written before anyone has looked at your process is mostly guesswork, and it tends to lock in the guesses.
## A test for your brief
Give it to two people who have never heard of your business and ask each of them what the software has to do. If you get two different answers, the brief is not finished yet.
## One thing to watch on the other side
If someone sends you a price without asking you anything, be careful. A quote is an estimate of work that has been understood. Nobody can understand your process from a paragraph, so a number that arrives without questions is a number that will move later, usually upwards and usually at the worst moment.
Good questions early are a sign you are talking to someone who intends to finish.
## If you want help writing one
Send us whatever you have, even if it is three lines in an email. We will ask the questions above and send back a written brief you can take to anyone, including someone other than us. There is no charge for that, and no obligation to work with us afterwards.