Writing a Software Brief That Gets an Accurate Quote

Why the same project gets wildly different quotes

Send the same two paragraphs to five software studios and you can get back five numbers that have very little to do with each other. It is tempting to conclude that somebody is overcharging. Usually the explanation is duller: each studio quoted a different project, because the brief left room for five different readings of what you wanted.

"An app for our customers to book appointments" could be a form that emails the front desk, or it could be a scheduling engine with staff calendars, reminders, payments, cancellations and a reporting dashboard. Both are reasonable readings. One is a fraction of the other. A studio that has been burned before prices the larger one to be safe. A studio that wants the work prices the smaller one and corrects the number later.

A good brief closes that gap. It does not need to be long, technical, or written by somebody technical. It needs to answer the questions every honest quote depends on, so the number you get back describes the project you actually have.

A brief describes the problem, not the screens

The most common mistake is to start with the solution: a list of screens, a feature list copied from a competitor, or a request for a specific technology. Start with the problem instead.

Write two or three sentences on what is going wrong today and what it costs you. "Bookings come in by phone and WhatsApp, two staff members spend most of the morning confirming them, and double bookings happen most weeks" tells a developer more than a page of feature names. It says who is affected, where the time goes, and what success looks like: fewer hours confirming, no double bookings.

A problem statement also protects you. If the studio proposes something that does not solve it, you will be able to see that before you sign anything.

The eight things every brief should answer

You do not need a template. You need answers to these, in plain language.

1. The problem. What is broken or missing today, and what it costs in time, money or customers.
2. The users. Who will use the system, roughly how many of each kind, and what each kind needs to get done. Staff, customers and administrators usually need quite different things.
3. Must-have versus later. The smallest version that would genuinely be useful, separated from everything you would like eventually. This is the single biggest lever on the quote, and the next section covers it.
4. What it connects to. Payment gateways, accounting software, WhatsApp, an existing website, a government portal, a spreadsheet that runs the business today. Every integration is real work, and an integration discovered halfway through is the usual cause of a revised quote. A payment gateway in particular brings work that is not the integration: the policy pages the gateway requires before it will activate you, which are set out in website requirements for a payment gateway. Name it in the brief and it gets quoted; leave it out and it surfaces the week before launch.
5. The data. What information the system holds, roughly how much, and whether existing data has to be moved in. Ten years of customer records in an old system is a project of its own.
6. Constraints. A date that cannot move, a regulation that applies, devices your users actually have, languages the interface must support.
7. The budget you have set, if you have one. More on this below, because it is the item people most often leave out.
8. Who decides. The name of the person who signs off, and who else has to agree. A project with an unclear decision maker takes longer, and somebody pays for that time.

If you cannot answer one of them yet, say so. "We do not know how many users to expect" is useful information. A guess presented as fact is not.

One thing more belongs in the brief rather than in the final invoice: who the accounts are registered to. The domain, the hosting, the repository and the analytics should be in your name from the first week, not handed over at the end. Leaving it unsaid is how a business ends up getting its website back from a previous developer two years later.

Must-have versus later is where the money is

Almost every first brief describes the whole vision: the version of the product that exists in three years. Quoting that as a single project produces a large number, a long timeline, and a lot of features nobody has tested with a real user.

Split the list honestly. For each feature, ask whether the first version would be useless without it. Booking an appointment is a must-have for a booking system. Loyalty points, a referral scheme and a reporting dashboard probably are not, however much you want them.

The first phase should be something real people can use, so that what you learn from them shapes the second. Our guide to SaaS app development makes the same point about MVPs, and if a mobile app is part of the plan, the native or cross-platform decision is worth settling before you brief anyone, because it changes the shape of every phase after it.

What not to over-specify

Some detail helps a quote. Some gets in the way.

Leave the technology to the people building it, unless you have a real reason: an in-house team that already maintains a particular stack, or a platform you are contractually tied to. "It must be built in a particular framework" without a reason narrows the field to studios that prefer that framework, not the ones best suited to the problem.

Do not design the screens. Rough sketches of what a user needs to see are useful. Pixel-perfect mockups produced before anybody has thought through the workflow tend to lock in decisions that should have been questioned.

Do not copy a competitor's feature list. You see their product as it is today, after years of iteration. You do not see which features nobody uses.

Describe outcomes, not mechanisms. "Staff must know about new bookings within a minute" is better than "the system must send push notifications", because it leaves room for a simpler answer if one exists.

Be honest about the budget

Many people leave the budget out on purpose, worried that a studio will simply quote up to it. The concern is understandable and mostly backwards.

A budget figure lets a studio tell you whether what you have described fits inside it, and if it does not, what would. Without it, you get a quote for one possible reading of the brief, and if it is out of reach the conversation ends there. With it, the conversation becomes "this is what the first phase could be for that amount", which is the conversation you actually wanted.

If you have not set a budget, say that too. A good studio will help you work out what the first phase is worth to you before you commit to anything. And if you want to arrive at a figure of your own first, website development cost in India sets out how to size a project on paper and which of the costs are actually published.

How a fixed quote per phase works

A brief is not a contract, and no brief is complete enough to price an entire product accurately. That is why BitsSolved quotes one phase at a time rather than the whole project up front.

The contract is the other document, and it deserves the same hour the brief gets, because it decides what you own and what happens when the work ends. What to change in a website development agreement works through the nine clauses a one page quote leaves out, with copy ready wording for each: whose name the domain is registered in, who holds the accounts, who owns the source code, when a milestone counts as accepted, what a change costs, and a handover clause with a deadline on it.

The shape is the same for every engagement. The first call is free and is mostly us asking the questions above. After it, you get the scope of the first phase in writing, including what is deliberately not in it, and a fixed price for that phase. Nothing is chargeable before you approve that quote. You see working software as it is built, not a status report at the end. If the scope changes partway through, the quote changes in writing before the work continues. You can stop after any phase and keep everything built so far, with the handover in your name.

A good brief makes that first scope faster and more accurate. It does not have to be perfect, because the first call exists to fill the gaps.

A brief you can write this afternoon

Put these on one page:

• Two or three sentences on the problem and what it costs.
• A short list of who uses the system and what each needs to do.
• Two columns: must-have for the first version, and later.
• Everything it has to connect to, and any data that has to move in.
• Dates, rules and constraints that cannot change.
• Your budget, or a plain statement that you have not set one.
• The name of the person who decides.

That page will get you better quotes from every studio you send it to, not only ours. It will also shorten the calendar, because most of what delays a website is a decision nobody had made yet: how long a website takes to build sets out the rest of the client half of the schedule, in the order it blocks the work. Our older guide to IT services for startups covers the wider question of what to outsource in the first place.

When you have it, send it over. Most first phases are web applications, SaaS products or mobile apps. If you already have a development team and want a second opinion on the plan rather than a build, that is SaaS architecture advisory. The full list is on the services page.