Founders often ask for an estimate with a feature list and little else. They usually get a number back. The trouble is that two teams can read the same list and quote prices that are miles apart, and neither number tells you much.
An estimate is only as good as what it is based on. A little preparation gets you better estimates, and makes it much easier to compare the teams giving them.
What to have ready
1. The goal, in one or two sentences
What are you trying to achieve, and for whom? "A booking platform for physiotherapy clinics, so patients can book and pay without calling" says far more than twenty features. It lets a team suggest a simpler way to get there.
2. Who will use it
List the kinds of users: customers, staff, admins, partners. Each one usually means its own screens, permissions and edge cases. This is one of the biggest drivers of cost, and it is often missing from briefs.
3. What success looks like at launch
What has to be true on day one for this to be worth it? Ten paying customers? A demo for investors? Staff no longer using spreadsheets? This shapes what goes into the first version and what can wait.
4. Must-haves and nice-to-haves, separated
Go through your feature list and mark each item. Be honest. If everything is a must-have, nothing is, and you will be quoted for all of it.
5. What already exists
Designs, a prototype, an old version, a spreadsheet the business runs on, existing systems it must connect to. Integrations with other software are often where the hidden work lives, so name them early.
6. Your constraints
A deadline and why it matters. A rough budget range, if you are comfortable sharing it. Anything regulated, such as health data or payments. Constraints are not a weakness in a brief; they help a team give you a realistic answer instead of an ideal one.
7. Who decides
Who will answer questions and approve things during the build? Projects slow down when decisions wait on someone who is never in the room.
What you do not need
You do not need a technical specification, a chosen tech stack or polished designs. A good team should help you with those. If a team will not talk to you until you have them, they are probably not the right partner for a first product.
How to read the estimates you get back
- A range is more honest than a single number. Nobody can price a product that does not exist to the dollar.
- Look for the assumptions. What is included, what is not, and what would make it bigger. If they are missing, ask for them.
- Check whether it is phased. A good estimate usually splits the work into what comes first and what follows, so you can start smaller.
- Notice the questions they asked. A team that asked about your users and your goals before quoting understood more than one that replied in an hour.
The short version
Bring the goal, the users, what success looks like and your constraints. Leave the technical decisions to the conversation. Then judge the estimates on their assumptions, not just their totals.
If you would like help turning an idea into a clear scope and an honest estimate, this is how I work with founders. Whatever you decide, the plan is yours to take to any team.