6 things to clarify before you ask a developer for an estimate

You ask for a software estimate, and the developer replies with more questions than answers. That can feel annoying — but usually it’s a good sign.

A serious estimate is not a menu price. It’s closer to asking a contractor what it costs to add a room before anyone knows whether you want a screened porch, a full bedroom, or a bathroom with plumbing tied into an old house. If you want a number that’s actually useful, here are six things to get straight first.

1. What problem are you actually trying to solve?

Don’t start with “I need an app” or “I need a dashboard.” Start with the business problem. Are you trying to stop double entry, speed up quoting, reduce missed follow-ups, or give customers a better booking experience?

That sounds basic, but it changes everything. A lot of businesses ask for a whole new system when the real issue is one bad bottleneck. I’d rather hear “our team re-enters the same customer data in three places” than a list of features. If you’re not sure where the real pain is, read Before You Buy New Software, Find the Bottleneck You Actually Have.

2. What is the smallest version worth building first?

This is the question most people skip, and it costs them. If you ask for the full dream project, your estimate will include every unknown, every edge case, and every nice-to-have you mentioned in passing.

A better move is to define the first useful version. Think of it like opening a restaurant with a tight menu before building the full bar, patio, and private event space. For many businesses, an MVP or first phase is the smartest way to control risk, which is why I usually push people to think in stages instead of one giant build. If that framing is new, What an MVP actually is and why you probably need one lays it out well.

3. What kind of estimate are you asking for?

A rough ballpark, a budget number, a fixed-price quote, and a sprint forecast are not the same thing. If you ask for “an estimate” without saying which one you mean, you and the developer may be talking about two completely different levels of certainty.

Early on, the honest answer is often a range, not a single number. That’s not a cop-out. It’s just reality: estimates are forecasts based on what’s known today, and vague requests produce fuzzy numbers. If you want a fixed quote, be prepared to define scope much more tightly and accept that changes later will have consequences. This is also where Fixed price vs hourly: which billing model protects you becomes a useful read.

4. What systems, data, and outside dependencies are involved?

This is where “simple” projects stop being simple. If the software has to connect to QuickBooks, your CRM, a booking platform, an old database, a vendor API, or a spreadsheet somebody in accounting guards like a state secret, the estimate changes.

Integrations, data cleanup, data migration, security requirements, and compliance work are where hidden cost lives. The same feature can be easy in a clean setup and a mess in a tangled one. If your project involves connecting tools, get specific before asking for pricing, and look at 7 questions to ask before connecting two software systems. If you already know your project depends heavily on software talking to other software, that’s really an API integrations conversation, not just a generic “build me a feature” request.

5. Who decides, and how fast can they decide?

This one gets ignored all the time. A project may only require a certain amount of engineering effort, but the calendar time can stretch if approvals take a week, stakeholders disagree, or nobody owns the final call.

In plain English: waiting is expensive. If a developer has to stop every few days and wait for answers, the estimate should reflect that risk. This is especially true for businesses juggling multiple departments or ownership groups, whether they’re in Bentonville, Springfield, or a smaller shop with one overloaded manager wearing six hats.

6. What counts as “done” — and what is out of scope?

If you don’t define success, you’ll argue about it later. “Build a customer portal” is vague. “Customers can log in, view invoices, download PDFs, and submit support requests” is much more useful because it gives the developer something testable.

Just as important: write down what is not included. Good estimates need assumptions, constraints, and exclusions. Does the price include design, QA, deployment, training, documentation, post-launch fixes, and hosting setup? Or is it just coding? If you want a clearer picture of what ready looks like before development starts, read How to tell if your software requirements are ready to build.

The short version: don’t ask a developer, “How much for software?” That’s like asking a mechanic, “What’s it cost to fix my car?” before anybody pops the hood.

Clarify the problem, define the first useful version, name the dependencies, decide who’s in charge, and get specific about what done means. Then ask for the estimate. You’ll get a better answer, and you’ll make better decisions with it.