A better software quote starts with a better brief

Most bad software quotes go wrong before the quote even exists.

The client describes the idea from memory. The developer fills in the gaps with assumptions. Everyone nods along. The proposal comes back looking tidy, except the price is for an imagined version of the job that nobody actually agreed to.

That’s where projects go sideways. Not because anyone is being difficult, but because the brief was too thin to hold the work.

A good brief doesn’t have to be long. It has to tell the truth about the problem.

Why one job gets quoted at $20,000 and $90,000

Here’s the experiment that convinces people. An operations manager at a wholesale distributor writes four paragraphs about wanting “a portal where customers can check stock and place orders”, sends it to four developers, and gets back $18,000, $42,000, $65,000 and $95,000. She concludes that software pricing is a lottery and at least one of these people is trying it on.

Mostly, nobody is. Each developer read the same thin brief and imagined a different job. The $18,000 quote priced a login screen over a nightly spreadsheet of stock levels. The $95,000 quote priced live inventory synced from the warehouse system, customer-specific pricing pulled from the ERP, credit limits, partial shipments and an admin area for the sales team, because that developer has built for distributors before and knows what “customers place orders” turns into by month three. They’re not four prices for one job. They’re four prices for four different jobs, and the brief is the reason.

Vagueness also carries its own surcharge. An experienced builder who can’t see the edges of the work protects themselves the only way they can, by padding the number. So a thin brief gets you quotes that are too high because of risk margin and too low because of missed scope, sometimes both in the same document, and you can’t tell which is which. The spread between your quotes is a rough measure, in dollars, of how much your brief left unsaid.

Start with the job, not the screen

The weakest briefs describe screens. Dashboard, login, customer list, reports, admin area.

You might well need all of those, but they don’t explain the work. A builder needs to know what happens today, who does it, where it breaks, what it costs you, and what should be different once the software exists.

If the current process is three different apps, two inboxes and someone called Karen who remembers which customer is awkward, say exactly that. The messy version is far more useful than a polished guess. Screens come later. Sort the job out first.

Explain the current process

Before you ask for a quote, write down how the work happens right now.

Who kicks it off? What information lands first, and where does it go? Who checks it? Which systems get updated? Where do people sit around waiting? And what happens when something doesn’t fit the normal path?

The exceptions are where the money hides. A build priced only around the happy path will punish you later. Every business has the odd cases: partial payments, missing documents, customers with special rules, staff approvals, ancient records, manual overrides, and jobs that go backwards before they go forwards. You don’t have to solve those in the brief. You do have to name them.

Say what success looks like

Decent software should change something you can actually measure. Fewer calls to the office. Faster quoting. Fewer missed approvals. A cleaner handover from sales to operations. Less time burned reconciling reports at the end of the month.

Without a target like that, the build quietly turns into a feature list, and feature lists are dangerous because every single item sounds reasonable on its own. A success measure gives the project a spine. It lets everyone ask whether a feature actually helps the outcome or just makes the first version heavier and slower to ship.

For an early idea, the success measure might just be evidence. Can customers get through the workflow? Can staff capture the data out in the field? Can you run one real job through the new process without anyone sneaking back to the old way? For a first version, proving that can be plenty.

Split must-have from nice-to-have

Most people are way too generous with the must-have list.

If everything is essential, nothing can move when the quote comes back bigger than you hoped. A good brief separates what the first version cannot launch without from what would be nice to have down the track. Must-have means the software cannot do its core job without it. Nice-to-have means the product is better with it, but the first version still proves its worth without it.

Take a booking system. Must-have is probably “customers pick a time, pay a deposit, and staff see every booking in one calendar”. The waitlist, the gift vouchers, the SMS reminders and the reporting screen are nice-to-have: worth building, later, once real bookings are flowing and you know which of them staff actually ask for.

Scope control starts right here. The split gives the developer room to shape a first version that fits the budget and still solves the underlying problem, and it lets the optional work get priced on its own instead of being smuggled into a vague fixed scope.

Name the systems it must touch

Custom software rarely lives on its own. If it has to read from Xero, update a CRM, send email, store files, take payments, publish to a website or pull from an old database, put all of that in the brief.

Integrations change the quote because they change the risk. A clean API is one thing. A legacy export, a shared drive with no structure, or a vendor portal with no proper access is a different beast. The builder doesn’t need every login before the first conversation, but they do need to know which systems are in play and which ones are going to be painful.

If you already suspect one system is going to be a nightmare, say so up front. Hiding it doesn’t make it cheaper. It just moves the cost into the middle of the project.

Give a budget range

Some clients dodge the budget question because they worry the quote will magically swell to match it. That does happen with the wrong supplier. With a good one, a range helps shape the right first version.

The same problem can usually be solved three different ways: a small prototype, a focused first release, or a larger production system with integrations, reporting and admin tools. With no budget range, the developer is left guessing which one you mean. Budget is not only about what you can afford either. A range helps everyone work out what belongs now and what can wait.

Be honest about timing

There are real deadlines and there are fake ones. A real deadline is tied to a grant, an event, a season, a contract, a compliance date, a staff change or a launch window. A fake deadline is “ASAP”.

If the date is real, explain why, so the builder can work backwards and cut scope where it makes sense. If it’s only a preference, say that too. Often you get a better result by giving the first version a few more weeks and skipping a rushed release nobody trusts.

A good brief comes back with questions

Don’t expect a good brief to end the conversation. Expect it to raise the quality of the questions. A builder worth hiring will still come back asking about the exceptions you named, the system you flagged as painful, and which of the users matters most on day one. That back-and-forth is the point of the exercise.

Be wary of the opposite: a fixed price that arrives fast from someone who read a thin brief and asked nothing. It means the number is for whatever they imagined, and the gap between their imagined job and your actual one gets settled later, through variations, arguments or a quiet drop in quality.

When the quotes land, compare the assumptions and exclusions before you compare the dollars. Two proposals $20,000 apart can be the same price once you notice one of them excludes data migration, the admin screens your staff will live in, and the first three months of fixes. The cheapest number on the page is often just the quote that left the most out.

What to send

Before you ask for a quote, send across:

• The problem in plain language.
• The current process, including the awkward parts.
• The people who will actually use the system.
• What success looks like.
• Must-have and nice-to-have scope.
• Existing systems, data and integrations.
• Security or privacy constraints.
• A budget range.
• Any real deadline.
• A few screenshots, exports or examples from the current workflow.

That’s enough to start a useful conversation.

If you want a structure to follow, use the Software Project Brief Template. If the idea is still loose, start smaller with idea to prototype. If the brief points to a serious build, web and app development is usually where the conversation heads next.

A good brief won’t make the quote perfect. It makes the quote honest enough to compare, question and improve before anyone writes a line of code. If you’ve got one half-drafted and a deadline behind it, send it over and we’ll tell you what’s missing before it goes out to anyone.