Why it’s hard to quote software development to the dollar

A mentor once told us something that stuck: anyone who quotes software to the dollar figure is essentially making it up.

And they were right.

They shared something that really resonated with us. They said that the only thing that ever got them closer to a reliable dollar figure was their own time and experience working in the industry. Over the years, as they gained more exposure to different kinds of projects, their quotes naturally became sharper.

But even then, they admitted it was never perfect. Software is simply too unpredictable for any one person - or any one company - to guarantee accuracy down to the dollar. Their experience gave them instincts, but not certainty. And that’s the key: not everyone has the benefit of decades of trial, error, and pattern recognition to draw from. For most businesses and clients, leaning on experience alone isn’t a sustainable or scalable method.

Software development isn’t like buying a chair or a car where you can compare features and prices. By its very nature, software is unpredictable. Until you start building, you don’t truly know how complex a feature will be, how many interdependencies you’ll uncover, or how long it will take to refine and test.

The Problem With Fixed-Dollar Quotes

If someone hands you a quote down to the exact dollar with absolute confidence, there are really only three possible outcomes:

1. They’ve underquoted.
2. Which means they’ll be underpaid for their service. At some point, the developer will likely start cutting corners - especially towards the end of the project - because they can’t afford to keep working at a loss.
3. They’ve overquoted.
4. To protect themselves, they’ve added a large buffer for mistakes. You end up paying too much, and often walk away feeling like you could have got more for your money.
5. They’ve quoted perfectly.
6. Which almost never happens. Software is simply too complex and variable for this to be a realistic scenario.

No matter which of the first two happens, the result is the same: an imbalance in the relationship. That imbalance creates frustration, mistrust, and disappointment for both sides.

An Extra Word of Caution About Milestone Payments

Some agencies still prefer milestone-based payments, where you only see the product at the end of each large phase—or worse, at the very end of the project.

On the surface, milestones sound neat: your project is broken down into chunks like authentication, settings, or subscriptions. But the catch is that this structure is traditionally a waterfall method.

That means you’re forced to lock in assumptions about your product at the very beginning—assumptions that may no longer be true by the time the milestone is delivered. For example, customer feedback, market shifts, or even new business priorities might emerge during development. Yet with a milestone approach, it’s often difficult (and expensive) to adjust once things are already in motion.

This creates two big risks:

• Limited flexibility. Once milestones are set, it’s hard to pivot without additional cost or conflict.
• Delayed visibility. You might not see any part of your product for six months or more, which is a long time to wait before finding out whether it’s even heading in the right direction.

By contrast, Agile sprints give you frequent checkpoints and the ability to adjust based on what you’re learning along the way—without being locked into outdated assumptions.

Why a Range Works Better

Instead of fixating on a single dollar figure, it’s far more effective to work within a range. Here is why it works best.

• It supports Agile delivery. By working within a range, you give the development team the flexibility to adapt as the project unfolds. This way, you’re not locked into assumptions made months earlier—you can adjust priorities as new insights, user feedback, or business goals emerge.
• You define what matters most. From your side, the most valuable thing you can do is highlight the features and outcomes you absolutely must achieve, as well as any critical timelines. Then, let your team come back to you with what’s achievable within the range, based on their experience and expertise.
• You’re buying time and focus, not arbitrary milestones. At Moonward, like most professional service providers, we charge for our allocation and time. This ensures you’re paying for our team’s knowledge and energy—rather than being boxed into rigid milestone contracts that quote for predefined features.

From the client’s perspective, the best way to do this is to:

• Highlight the features you absolutely must have. Be clear on what functionality is essential versus what would be nice to have.
• Define success metrics. What does “done” look like to you? Is it user adoption, speed, revenue, or something else?
• Share any critical timelines. If you’ve got a hard deadline—like a launch event or seasonal push—make sure the team knows.

With this clarity, the development team can come back with what they feel is achievable within the range, based on their own experience and expertise. This creates a more honest, flexible partnership and avoids the pitfalls of “perfect” quotes.

The Bottom Line

Quoting software to the dollar sounds neat and tidy—but in reality, it rarely serves either side well. By working in sprints, we embrace the uncertainty of software development with a framework that prioritises transparency, adaptability, and trust.

Because at the end of the day, building great software isn’t about guessing a number—it’s about building the right thing, the right way.

‍