What to Send a Developer Before You Ask for a Quote 📋
Send the same idea to three development shops and you can easily get quotes that are forty thousand dollars apart. Founders usually read that as evidence that someone is trying to overcharge them. Occasionally that is true. Far more often, the three shops were quoting three different products, because the description they received left too much to the imagination and each of them filled in the blanks differently.
The fix is not a longer document or a fancier deck. It is a short, specific brief that answers the handful of questions every developer has to answer internally before they can put a number on anything. Here is what goes in it, and how to sharpen your idea before you write a word of it.
Why Vague Requests Get Expensive Quotes
Developers price uncertainty. When a brief says "users can share their progress" without saying where, with whom, or what happens next, an estimator has two choices. They can assume the small version and risk eating the difference later, or they can assume the large version and pad the number. Responsible shops pad. That is not greed, it is arithmetic: they are quoting a range of possible products and have to protect against the expensive end of it.
The quotes that come in suspiciously low are usually the other choice, and the gap reappears later as change orders. Either way, you pay for the ambiguity. Clarity is the rare thing in this business that costs you nothing and usually lowers the number, because every question you answer up front is a contingency somebody does not have to budget for.
Pressure-Test the Idea With AI Before You Write Anything
Before you describe your app to anyone who will charge you for their time, describe it to something that will not. Claude and ChatGPT are unusually good at this particular job, and it costs you an evening rather than a discovery engagement.
The catch is that these tools are agreeable by default. Describe your idea in neutral terms and you will get a tidy summary of why it is promising, which feels wonderful and teaches you nothing. You have to explicitly ask them to work against you. Tell the model to act as a skeptical investor, or as the competitor who would most like to see you fail, and to give you the strongest objections rather than a balanced view.
The questions worth putting to it are the uncomfortable ones. What has to be true for this to work, and how would I check whether it is? Who solves this problem today, even badly, and why would someone switch? What is the simplest version that still solves the actual problem? Where does this fall apart at a hundred users, and at ten thousand? If this fails in a year, what is the most likely reason? Ask it to name the assumption your whole idea rests on, then ask how you could test that assumption for under five hundred dollars.
Two cautions. An AI tool does not know your market, your customers, or your city, so treat its objections as prompts for you to investigate rather than findings. And it will happily invent statistics if you let it, so do not carry any number it produces into a business plan without checking the source yourself.
Use AI to Cut the Feature List, Not Grow It
The brainstorming half of this is easy and fun: dump every feature you have imagined into a conversation and let the model suggest more. The valuable half is what comes next. Ask it to sort that list into what is genuinely required for a first launch and what can wait, then ask it to argue against every item that landed in the required column. Anything that survives that argument is probably real.
The step almost everyone skips is asking what each feature implies. Go through your list and ask what a developer would have to build behind the scenes to support each one. User accounts bring password resets, email delivery, and privacy obligations. Payments bring a payment provider, refunds, failed charges, and tax questions. Push notifications bring server infrastructure and two sets of app store rules. Chat brings moderation and abuse reporting. None of these are reasons not to build something, but they explain why a feature that sounds like one line in a brief can be three weeks of work, and seeing that before you get a quote is what lets you make trade-offs deliberately instead of by sticker shock.
One habit makes all of this dramatically more useful: keep the conversation in one place and paste your working brief back in as it evolves, so the model is reacting to your current thinking rather than the version you described an hour ago.
The Six Things Every Developer Needs From You
This is the whole brief. Two pages is plenty, and a clear two pages will get you a better estimate than a vague twenty.
Your core user flows. Not a feature list, a walkthrough: someone opens the app for the first time and what happens, step by step, until they get the thing they came for. Three or four flows written as plain sentences tell a developer more than any diagram, because flows are where the hidden screens live.
Must-have versus nice-to-have. Two explicit columns, with the launch version deliberately short. This single distinction does more to make quotes comparable than anything else on this list, because it tells every shop to price the same product.
Apps you like, and specifically why. Naming two or three existing apps saves a paragraph of description each time, as long as you say what you like about them. "Like Venmo" is ambiguous. "Like Venmo, in that sending money takes three taps and the social feed is the main screen" is a specification.
Where it needs to run. Web, iPhone, Android, or some combination. This is one of the largest single drivers of cost, and founders often say "an app" while meaning quite different things. If you are not sure, say so and ask for the trade-offs rather than guessing.
A budget range. A range, not a number, and an honest one. More on this below, because it is the item founders resist most. A good development shop will use the range to help you understand whats realistic. This prevents everyone from wasting a ton of time thinking through features that will just get scrapped later because of the budget.
Real timeline constraints. Not "as soon as possible," which every client says and no developer can plan around. If there is a trade show, a funding milestone, a school year, or a season your business depends on, name the date and say what happens if it slips.
Why Sharing a Budget Range Makes You a Stronger Client, Not a Weaker One
The fear is understandable: name a number and you will be charged exactly that number. It is worth being clear that this does happen, and it is a reason to choose your shortlist carefully. But withholding the range does not protect you from a firm inclined to work that way, and it costs you something real with everyone else.
Software has no fixed price the way a refrigerator does. Almost any idea can be built at wildly different levels of ambition, so without a range, a developer is guessing which version you want and will often guess wrong in whichever direction hurts. Give a range and a good shop will tell you plainly what is achievable inside it, what would have to be cut, or that the project cannot be done well for that money. Hearing that in week one is a gift. The alternative is discovering it in month three.
If you have no idea what a realistic range looks like, our post on what it costs to build a mobile app is a reasonable place to calibrate before you commit one to paper.
What a Good Developer Should Send Back
Your brief is also a test, and the responses tell you a great deal. The first thing a strong shop sends back is questions, not a number. Someone who quotes a two-page brief without asking anything has either built your exact app before or is not thinking very hard about yours. I promise you, it's the latter.
When the estimate does arrive, look for written assumptions, so you can see what they believed they were pricing and correct anything they got wrong. Look for phases rather than a single lump figure, because a proposal broken into stages is one you can stop, adjust, or extend as you learn. Look for what is explicitly excluded, which is where uncomfortable surprises usually hide. And look for plain language about who owns the finished code, which we covered in detail in our guide to who actually owns your code. A shop that answers that question clearly and in writing before you ask is telling you something good about how the rest of the project will go.
Send Us Your Brief
If you have written something along these lines, or even half of it, we are happy to read it and give you a straight answer on what it would realistically take to build, where we think the cost is hiding, and whether the first version should be smaller than you are planning. No charge and no obligation to hire us. Reach out through our Contact Us page and send it over.
