Why quotes vary so wildly
Send the same one-paragraph idea to five software companies and you'll get five prices, sometimes ten times apart. It's not that some are honest and others aren't. Each is guessing at what you mean, and each guess leads to a different product.
A good brief removes most of the guesswork. It doesn't need to be long or technical. It needs to describe your problem, your users and your constraints clearly enough that every team quotes for the same thing.
What to include
The problem, in your words
Describe what's going wrong or what you want to make possible, before you describe any software. "Our dispatch team spends two hours a day phoning drivers to find out where they are" is far more useful than "we need a GPS tracking app".
Who will use it
List the kinds of users, roughly how many of each, what devices they use and which languages they work in. A tool for ten office staff on laptops is very different from one for two hundred field agents on low-cost phones.
What happens today
Walk through the current process, step by step, including the spreadsheets, notebooks, phone calls and workarounds. This is where most hidden requirements come from.
Must-haves and nice-to-haves
Split features into what the first version can't launch without and what can wait. Teams can then quote a sensible first release instead of everything at once.
What it has to connect to
Payments, accounting software, WhatsApp, an existing website or database: each integration has a cost, and leaving one out is the most common reason projects grow.
Volumes and peaks
How many orders, users or documents per day, and what does your busiest day look like? Software that copes with an average day can fail on the busiest one.
Budget range and the reason for any deadline
A range lets teams propose the best product for your money instead of guessing. If there's a deadline, explain why. "Before the festival season" helps a team plan; "as soon as possible" doesn't.
Questions to ask every team
- Who owns the code, designs and data? The answer should be you, from day one.
- Where will it be hosted, and in whose name? Cloud and app store accounts should belong to your company.
- How will we see progress? Look for regular demos of working software, not status reports.
- What's included after launch? Bug fixes, updates and support should be explicit.
- What happens if we part ways? Documentation and a clean handover should be part of the deal.
What a good quote looks like
A good quote breaks the work into features or releases, states its assumptions, lists what's not included and explains the main risks. It might suggest cutting something to launch sooner. If a quote is a single number with no detail, ask for the breakdown before comparing it with others.
Red flags
- A price given before anyone has asked about your users or your process.
- Pressure to sign quickly, or a discount that expires tomorrow.
- Vague answers about who owns the code or the accounts.
- No mention of testing, security or what happens after launch.
- A promise that everything is possible for the same price.
When you're not sure what you need
That's common, and it's fine. Many teams offer a short, paid discovery phase that turns an idea into a clear scope, a prototype and a fixed estimate. It costs a fraction of the build and often saves far more than it costs, by removing features nobody needed.
Want help shaping your brief? Our Blueprint phase is designed for exactly this.
