How to scope a software project before you ask for quotes

Ask five development companies to quote for a loosely described app and you will get five numbers that differ wildly. That is not because some of them are dishonest. It is because each has filled the gaps in your brief with its own assumptions, and those assumptions are where the cost lives.

You do not need a hundred-page specification to fix this. What you need is a clear, honest account of what you are trying to achieve, who it is for, and what constraints apply. This article sets out how we would prepare that brief if we were on the buying side.

Describe the outcome, not the feature list

Most briefs start with features: a dashboard, user accounts, notifications, a mobile app. Features are the answer to a question the brief has not yet asked. Start instead with the problem and how you will know it has been solved.

Compare two openings. One says the business needs a customer portal with login, order history and document downloads. The other says customers phone the office several times a day to ask where their order is, which ties up two members of staff, and the goal is for most customers to answer that question themselves. The second tells a supplier what matters, lets them suggest cheaper routes to the same result, and gives everyone a way to judge success.

Features are the answer to a question the brief has not yet asked.

What a useful brief contains

A good brief usually fits in a few pages. It should cover:

1. The problem and the goal. What is happening today, why it matters commercially, and what good looks like.
2. The users. Who will use the system, roughly how many, how often, and on what devices. Internal staff and paying customers have very different expectations.
3. The current process. How the work gets done today, including the spreadsheets, emails and workarounds. Screenshots are gold.
4. Systems it must connect to. Accounting, CRM, payments, stock, identity. Name the actual products and versions where you can.
5. Constraints. Deadlines that are genuinely fixed, regulatory requirements, data residency, accessibility, and any technology the business is committed to.
6. Priorities. What must exist in the first release, what would be good to have, and what can wait.
7. Budget range. Even a broad range helps a supplier propose something realistic rather than guessing.

Being open about budget is the item people resist most. The worry is that suppliers will simply quote up to the number. In practice, a range lets a good supplier tell you what is achievable within it and what trade-offs are involved, which is far more useful than a quote for a system you cannot afford.

Separate the first release from the vision

Most projects get into trouble because the first release tries to be the whole vision. It is worth writing both down, then being ruthless about the first. A useful exercise is to walk through a single user completing their most important task from start to finish, and list only what is needed for that journey to work. Everything else goes on a later list.

This is not about cutting corners. A smaller first release reaches real users sooner, and real usage is the most reliable way to discover what the next release should contain. It also limits the cost of being wrong about an assumption, which, on any project worth doing, you will be at least once.

Unknowns are fine if you name them

There will be things you do not know. Perhaps it is unclear whether an old system has a usable API, or how much historical data needs migrating, or whether a third-party provider can support a particular workflow. List these openly. A supplier can then price a short discovery piece to answer them, rather than burying a large contingency in the main quote.

For anything with meaningful uncertainty, we generally recommend a paid discovery phase before committing to a full build. A few weeks spent mapping workflows, testing integrations and prototyping the key screens with a UI/UX design process turns guesses into decisions. It also gives you a low-risk way to see how a supplier works before signing a larger contract.

What to ask suppliers

Once the brief is ready, the questions you ask are as revealing as the quotes you receive:

• What assumptions have you made, and which ones carry the most risk?
• What would you cut or simplify to reduce cost, and what would you refuse to cut?
• Who will actually work on the project, and how will we communicate day to day?
• How do you handle changes in scope once work has started?
• Who owns the code, the designs and the infrastructure accounts at the end?
• What does support and maintenance look like after launch, and how is it priced?

Pay attention to suppliers who push back on parts of your brief. Disagreement, explained well, is a sign someone has thought about your problem rather than just pricing the list you sent.

Comparing the quotes

When responses arrive, resist comparing the totals first. Line up what each supplier has actually included: design, testing, deployment, project management, documentation and post-launch support are often treated very differently. A lower figure that excludes testing and hosting setup is not cheaper. Look for the proposal that shows the clearest understanding of your problem, and that is honest about risk.

If you would like a second opinion on a brief before it goes out, or want help running a discovery phase for a custom software project, you can get in touch. We are happy to tell you if the right answer is a product you can buy rather than something you need built.