Most agencies don't price software projects. They guess, then round up until it feels safe.
I've watched it happen for years. A client describes what they want in two sentences, someone on the team does sums in their head, and a number comes out — usually the same number the agency quoted on the last project that felt vaguely similar. Sometimes it's too high and you lose the deal. More often it's too low, and you spend the next three months explaining to your team why the project that was meant to take six weeks is still going.
Before starting Scopeyard, I spent six years running a profitable product development studio where we built software for banks and charged a daily rate that wasn't cheap. The projects that hurt us weren't the ones where we charged too little per hour. They were the ones where we guessed the scope, committed to a price, and discovered the real shape of the work only after we'd signed.
The numbers back this up. Around 70% of software projects exceed their initial budget, with an average overrun of about 27%, and changing requirements alone can push costs up by as much as 50%. Underestimated complexity is behind roughly 43% of overruns. None of that is a rate problem. It's an estimation problem dressed up as a pricing problem.
So here is how to price a software development project without guessing.
The thesis in one line:
Defensible Price = Sized Scope × Blended Rate × Uncertainty Buffer + Contingency
Everything below is just how you fill in each term honestly.
1. Refuse to price what you can't see
The single biggest mistake is quoting a fixed price off a conversation. The client says "we need a customer portal," you picture a customer portal, and you price the portal in your head. The problem is that the portal in your head and the portal in theirs are almost never the same thing.
This is the Cone of Uncertainty, a concept Barry Boehm introduced back in 1981. At the very start of a project, before requirements are clear, estimates can be off by as much as a factor of four in either direction — roughly a 16x spread between your optimistic and pessimistic guesses. As you learn more, that cone narrows to something like ±10–15%.
The lesson isn't "estimate harder." It's "don't commit to a precise number while you're still standing at the wide end of the cone." If a client wants a firm fixed price on day one, what they're really asking is for you to absorb all the uncertainty for free. Don't.
2. Charge for discovery, then price the build
The way out of the cone is a paid discovery phase. Map the requirements, the integrations, the data, the edge cases, the non-functional bits everyone forgets — auth, roles, audit logs, performance. You come out the other side with something you can actually size, and the client comes out with a specification they own.
Price discovery as its own small engagement so it's not a favour you're doing for free:
| Project size | Discovery / scoping fee | Typical duration |
|---|---|---|
| Small build | $1,500–$4,000 | 3–5 days |
| Mid-size build | $4,000–$12,000 | 1–2 weeks |
| Large platform | $12,000–$30,000+ | 3–6 weeks |
Discovery does two things. It pays for the most valuable thinking you do, and it earns you the right to quote the build with confidence instead of bravado. Clients who refuse to pay for any discovery are usually the same clients who will refuse to pay for the scope creep later.
3. Size the scope before you touch the rate
Once you can see the work, break it into deliverables, then into the pieces of work under each one. You're not aiming for perfection. You're aiming for a list specific enough that a developer who wasn't in the room could look at it and roughly agree.
Then estimate each piece as a range, not a point. The technique I trust most is three-point (PERT) estimation: for each item, write an optimistic number (O), a most-likely number (M), and a pessimistic number (P), then compute:
Expected effort = (O + 4M + P) / 6
So a piece you think is "about 20 hours, maybe 12 if it's clean, maybe 40 if the third-party API fights us" comes out at (12 + 80 + 40) / 6 ≈ 22 hours. The pessimistic case drags the number up, which is exactly what you want, because the pessimistic case happens more often than anyone plans for. Forcing yourself to name P out loud is how you stop pretending integrations are simple.
Sum the expected efforts across every item and you have a build estimate grounded in the actual work, not in vibes.
4. Apply a blended rate, not a headline rate
Now multiply effort by rate — but use a blended rate that reflects who actually touches the project, not your most expensive engineer's number stretched across the whole thing.
Rates vary wildly by where your team sits. In 2026, offshore development runs roughly $18–$40 per hour in India, $25–$70 in Eastern Europe, and $23–$90 across Latin America, while onshore US fully-loaded rates land around $80–$150 per hour. A senior, a mid-level developer, a QA person and a project manager all bill differently, so blend them by how much of each the project really needs.
One number people forget: your true loaded cost is typically 1.4 to 1.8 times the quoted rate once you account for management overhead, ramp-up, QA, meetings and the inevitable rework. If you price at your raw rate, you're quietly funding all of that out of your margin. Set your blended charge-out rate above your blended cost rate on purpose, not by accident.
5. Turn the range into a buffer, not false precision
Three-point estimation gives you a spread. Don't throw it away by quoting only the middle. The gap between your expected estimate and your pessimistic estimate is your uncertainty buffer, and how much of it you carry into the price depends on how clear the scope is.
| Scope clarity | Uncertainty buffer | When it applies |
|---|---|---|
| High — detailed spec, known stack, stable requirements | 10%–15% | Post-discovery, client signed off on scope |
| Medium — clear goals, some unknowns, new integrations | 15%–30% | Most real projects |
| Low — vision-stage, shifting requirements, R&D | 30%–50%+ | Quote a range or refuse fixed price entirely |
When clarity is low, the honest move is to quote a range or move to time-and-materials with a cap. Quoting a single confident number on a vague project isn't confidence. It's you volunteering to eat the difference.
6. Add a contingency you can name out loud
A buffer covers the work you can see being bigger than expected. Contingency covers the work you genuinely cannot see yet — the requirement that surfaces in week four, the data that turns out to be filthy, the stakeholder who appears halfway through with opinions.
I add a separate contingency line, usually 10–20% on a well-scoped project and more when the client is new or the domain is unfamiliar. Critically, I show it. A client who can see a labelled contingency understands they're paying for resilience, and they're far less likely to fight you when you draw it down. The agencies that hide contingency inside a padded number are the ones who end up in awkward "why is this costing more" conversations later.
7. Tie scope changes to money before they happen
Most overruns aren't a single bad estimate. They're forty small "could you just also…" requests that nobody priced. Changing requirements increase costs by up to 50% precisely because each change feels too small to charge for in the moment.
So agree the mechanism up front: anything outside the signed scope goes through a short change request with its own estimate and price, and nothing starts until it's approved. This isn't bureaucracy. It's the only thing that keeps a fixed-price project fixed. It also protects the relationship — the client always knows what they're spending, and you never have to swallow work silently and resent it.
This is the part where pricing meets delivery, and where most of the leakage actually happens. You can estimate beautifully and still lose your margin if "approved" and "out of scope" live in someone's memory instead of on a record. At Scopeyard we built the milestone and approval layer for exactly this — so every change, sign-off and approved scope is logged, and what the client agreed to is never in dispute. If you run a product agency, that record is the difference between a contingency you draw down on purpose and an overrun you discover too late. It's also why a structured tool beats running delivery out of a general task board; I've written more on that in the Asana comparison.
Final thoughts
Pricing software projects well isn't about having a magic rate or a clever formula. It's about being honest at each step: don't price what you can't see, size the real work, estimate in ranges, blend your rate to reality, and make uncertainty and contingency visible instead of hidden.
Remember the wider picture. Only about 31% of software projects come back clean, while half are challenged and the rest fail outright — and small, tightly scoped projects succeed far more often than big vague ones. Good pricing isn't separate from that. A defensible price forces a defensible scope, and a defensible scope is what actually gets delivered.
Stop guessing and rounding up. Size the work, show your buffer, and charge for the thinking. The client who wants a real number will respect you for it, and the client who only wants the cheapest guess was never going to be profitable anyway.