TL;DR: A brief a developer can quote does not need to be long or technical. It needs to answer seven things clearly: who the users are, the one thing they do in version one, what exists already, what it has to connect to, what "done" looks like, the constraints (budget range, deadline, platforms) and who decides. Write the user's journey as plain steps, list what is explicitly out of scope, attach examples of products you like, and say your budget range out loud. I have quoted a lot of projects, as a freelancer on Upwork starting with clients in Australia and then the US, and later as a fractional CTO and AI engineer, and the difference between a quote that holds and one that blows up is almost always decided by the brief, not the developer.
When a founder sends me a brief, I am trying to answer one question: what exactly am I agreeing to build, and how will we both know when it is finished? If the brief answers that, I can give a real number. If it does not, every developer who replies is guessing, and the quotes you get back will range from suspiciously cheap to alarmingly expensive, because each person filled the gaps with a different imaginary product.
This post is the guide I wish I could send to every client before the first call. It is not a template full of headings to fill in. It is the set of things that actually change a quote.
Why most briefs produce bad quotes
The usual brief is either one line ("I want an app like Uber but for dog walkers") or twenty pages describing the long-term vision, investor deck included. Both fail for the same reason: they describe the idea, not the work.
A developer quotes work. To price work I need to know which screens exist, what happens on each one, what the system talks to, and where the edges are. The idea matters for context, but two products with the same idea can differ by ten times in effort depending on decisions the brief never mentions. Does the user need an account? Is there payment? Does it work offline? Does a human on your side need to approve anything?
The good news is that none of this requires technical knowledge. It requires you to have thought through how someone will actually use the thing.
The seven things a brief has to answer
1. Who uses it
Name the user types, and keep the list short. "Students," "clinic receptionists," "facility managers." If there is an admin or staff side, say so, because a second user type often means a second interface.
2. The one thing they do in version one
Describe the core journey as numbered steps in plain language. For example: "A caller rings the clinic. The agent answers, finds out what they need, checks availability, books the appointment and texts a confirmation." Or: "A student opens the app, records a lecture, and gets back a summary and an outline."
This is the most valuable paragraph in the whole brief. If you can write it in five to eight steps, the project is scoped. If it keeps branching, the scope is not ready yet, and I would rather help you cut it than quote it. I go through that process in what to cut from an MVP.
3. What already exists
Say what is built, what is designed and what is just an idea. Existing code changes everything: sometimes it saves weeks, sometimes it costs weeks, and a developer cannot know which without seeing it. If there is a codebase, offer access before the quote. When I inherit someone else's codebase, the first week of reading tells me more than any description could.
Also list designs (Figma, sketches, screenshots), existing accounts (app store, domain, cloud, CRM) and any content or data that needs moving in.
4. What it has to connect to
Integrations are where hidden effort lives. List every outside system the product must talk to: the CRM, the calendar, payments, SMS, an existing database, a hardware device. For each one, say what has to happen, not just the name. "Connect to GoHighLevel" could mean creating a contact or it could mean a full pipeline with stages, tags and automations. On voice agent projects this list alone often decides the size of the job, which is why it gets its own section in the voice agent discovery call.
5. What "done" looks like
Write two or three acceptance checks a non-developer could run. "I can book an appointment by phone and see it in the calendar within a minute." "A new user can sign up, record a lecture and see notes without help." "The app is live on the App Store and Play Store." These protect both sides. Without them, "done" becomes a negotiation at the end of the project, which is the worst time to have it.
6. The constraints
Three numbers matter more than anything else here.
- Budget range. Many clients hide this, worried a developer will quote up to it. In practice, a range lets the developer propose the best version that fits, rather than the ideal version that does not. A good developer will tell you if the range is too low for what you described, and suggest what to cut.
- Deadline, and why. "Before a conference on the 14th" is a real constraint. "As soon as possible" is not. If the date is fixed, say so, and expect scope to flex around it.
- Platforms. iOS, Android, web, a headset, a phone line. Each one is real work. "All of them" is a valid answer, but it should be a decision, not a default. I compared the options in React Native vs Flutter vs native.
7. Who decides
Name the person who approves work and answers questions. Projects with three founders who each give feedback separately take noticeably longer than projects with one decision-maker. If approval needs a committee, a hospital compliance team or an investor sign-off, put that in the brief, because waiting time is part of the timeline.
The section most briefs forget: out of scope
The fastest way to make a quote reliable is to list what you are not asking for. "No admin panel in version one." "No Android until after launch." "No payments yet, we will invoice manually." "English only."
This feels like extra writing, but it removes the most expensive kind of misunderstanding: the feature one side assumed was obviously included and the other assumed was obviously not. An out-of-scope list is also what makes a fixed-price project fair. Without it, fixed price turns into an argument about what the price covered.
Things that help more than you would expect
Examples you like and dislike
Link two or three products and say what specifically you like about each one. "The onboarding in this app," "the way this dashboard shows calls per day." A screenshot with a note does more than a paragraph of adjectives. Saying what you dislike is just as useful.
Real sample data
For AI work especially, real inputs change the estimate. A few recorded calls, a sample of the documents the agent should answer from, or the actual spreadsheet you want imported tells me how messy the real world is. Audio from a quiet lecture hall and audio from a phone call in a garage are different problems, which I wrote about in speech-to-text for lectures vs phone calls.
What happens after launch
Say who will run the product once it ships, and whether you want ongoing support. A product you will maintain in-house needs different handover work than one the developer keeps looking after. For voice agents I treat this as a handover of ownership, and it is worth deciding upfront rather than at the last invoice.
What you do not need to include
You do not need to choose the tech stack, unless you have a real reason such as an existing team or codebase. You do not need database diagrams, user stories in formal syntax or a full specification of every screen. And you do not need the five-year roadmap. Mention where the product is heading in a sentence or two, so the developer avoids choices that block it, then keep the brief about version one.
A good brief is usually one to three pages. Longer is fine if it is mostly examples and sample data. Longer because of vision and market sizing does not help the quote.
A quick brief template
If you want a starting point, this is the shape I find easiest to quote from:
- One-paragraph summary: what it is and who it is for.
- Users: the user types, one line each.
- Core journey: five to eight numbered steps.
- What exists: code, designs, accounts, data.
- Integrations: each system and what must happen with it.
- Done means: two or three checks you could run yourself.
- Out of scope: the things you are deliberately leaving out.
- Constraints: budget range, deadline and the reason for it, platforms.
- Decision-maker: who approves and how fast they can reply.
- Examples and samples: links, screenshots, sample data.
How to read the quotes you get back
A brief like this also makes the replies easier to compare. A developer who read it properly will ask about specific gaps, push back on something in the core journey, or suggest cutting a feature to fit your budget. A reply that ignores the details and just names a price is telling you something too.
Expect questions. If a developer has none, either the brief is exceptionally complete or they did not read it closely. In my experience it is usually the second. Working across time zones makes this even more important, because a clear written brief is what lets the work move while you sleep, which I covered in working with a remote developer across time zones.
I build software, mobile apps and AI voice agents for founders across the US, UK and Europe, and I am happy to turn a rough idea into a brief and a real quote together. Read more about my background here, or book a call and bring whatever you have, even if it is one line.