When you send a developer a vague request, you get a vague price back. Imagine a quote of “somewhere between $15,000 and $60,000” (example numbers only). That range is not evasion. It is an honest measure of how much the developer cannot see yet.
A fixed price needs fewer unknowns. A good one-page brief removes most of them before the first call.
#Why vague briefs produce ranges
A developer pricing a project is guessing at hidden work. “We need a customer portal” could mean a login and a list of invoices, or it could mean roles, approvals, payment handling and a connection to your accounting software. The price differs by an order of magnitude, so the developer protects themselves with a wide range.
Every unknown you resolve narrows the range. The goal of the brief is not to design the system. It is to make the edges of the project visible.
#The one page
Aim for one page, written in plain words. These are the parts, in order.
- The problem, in two sentences. What is going wrong or taking too long, and for whom. Leave out the solution you have in mind for now.
- Who uses it and what they do today. Name the roles (front desk, dispatcher, bookkeeper) and describe the current routine, including the spreadsheet or inbox they use.
- Must-haves and nice-to-haves. Keep the must-have list short. If everything is a must-have, nothing can be traded off later.
- Out of scope. Say what this project will not do. This line prevents more arguments than any other.
- Systems it must connect to. Accounting, email, your website, a payment processor, a phone system. Name each one and, if you know it, what has to pass between them.
- The data it starts with. Where it lives, roughly how much, and how clean it is. Years of rows in a spreadsheet are a project of their own.
- What success looks like, in plain words. “A new employee can book a job without asking anyone” is useful. “Improved efficiency” is not.
- Deadline and budget range.
- Who decides. One name, and who else must be consulted.
#Give a budget range, and say why
Many owners avoid sharing a budget, afraid the price will rise to meet it. In practice the opposite helps you. A range such as “we have in mind $20,000 to $30,000” (again, example numbers) lets the developer propose what fits: a smaller first version, a different approach, or an honest “this will not fit.”
Without a number, the developer has to guess whether you want the basic version or the full one, and will often quote the larger to be safe. A range plus a must-have list is the fastest route to a fixed price you can compare.
The same applies to dates. If there is a real deadline, such as a trade show or a contract renewal, say so and say what happens if it slips. If there is no deadline, say that too.
#Say who decides
Projects stall when feedback arrives from five people who disagree. Name the person who makes the final call, and list anyone who must be asked first (the accountant, the operations lead). Developers will ask who approves the scope, so having the answer ready shortens the process.
#What a good question from a developer looks like
Once your brief is in, expect questions. Good ones are specific and tied to cost:
- “When two people edit the same record, which version wins?”
- “Do old orders need to be searchable, or only the last year?”
- “Is the accounting export a file someone uploads, or should it sync on its own?”
- “What happens today when a customer cancels halfway?”
These questions are a good sign. They show the developer is finding the hidden work, and each answer takes a chunk out of the range. Be wary of the opposite: a quote that arrives with no questions at all is a quote that will change later.
If you do not know an answer, say so. “I don’t know yet, can we decide that in a workshop?” is far more useful than a confident guess.
#Start from a template
You do not need to invent the format. There is a ready-to-fill version at the one-page project brief. Fill it in, send it to two or three developers, and compare the questions they ask along with the prices they give.
