Why software estimates change when the real problem isn’t settled

You ask for a software estimate, get a number, then two weeks later the number changes. That feels shady until you realize the estimate was built on a moving target.

Most business owners think software estimates change because developers are sloppy, or because somebody is sneaking in extra cost. Sometimes that happens. But more often, the real reason is simpler: the actual problem hasn't been settled yet.

Think about building an addition onto your office. If you tell a contractor, "I need more space," that is not a settled problem. Do you need one office, a warehouse bay, a break room, or climate-controlled storage? Are you expanding for staff, inventory, or customers? Until that part is clear, any price is half guesswork.

Software is the same way.

A lot of estimates are really pricing one of three very different jobs:

• replacing a manual process
• connecting systems that don't talk to each other
• creating a new workflow your team will actually follow

Those are not the same project.

Say you run a service business and tell a developer, "We need a custom app for scheduling." Maybe you do. But maybe the real problem is double entry between your calendar and invoicing system. Maybe it's missed handoffs between office staff and field staff. Maybe it's that nobody agrees on who owns the schedule. If that underlying issue isn't nailed down, the estimate will keep changing because the job keeps changing.

This is why I push people to define the problem before they define the product. Don't start with, "We need a portal, dashboard, app, CRM, or AI feature." Start with, "What is breaking, for whom, and what should happen instead?" If you skip that step, you end up paying to design the wrong building on the right lot.

I've seen plenty of projects where the first conversation sounds like a custom software development job, but after a little digging it's really an integration issue, a reporting issue, or a decision issue. That's also why articles like 6 things to clarify before you ask a developer for an estimate and How to tell if your software requirements are ready to build matter more than people think.

Here's the part nobody likes: early estimates are often directional, not precise. If the developer is honest, they should say that out loud. If someone gives you a highly detailed fixed number before key decisions are made, be careful. They may be guessing, or worse, lowballing to get the job and planning to fight about scope later. I wrote about that directly in Myth: You Can Price Custom Software Accurately Before Key Decisions.

For businesses around Northwest Arkansas and the Ozarks, this comes up constantly because teams are trying to move faster without adding more admin work. The temptation is to demand a fast quote. I get it. But a fast wrong quote is less useful than a slower honest one.

So what should you do?

Write down the business problem in one sentence. Name who feels it every day. List what has to be true for the project to count as a win. Then ask for an estimate based on that version of the problem—not the half-formed solution in your head.

Because when the problem is fuzzy, the price is fiction.