An engineering lead multiplies an hourly rate by a headcount and calls it a budget. Then the invoice lands, 30% to 40% higher, and nobody on the call can say exactly when it stopped matching. Somebody still has to explain that difference to whoever signed off on the original figure.

Pricing a build off the rate card alone creates that difference, a pattern that repeats across enterprise software and AI products alike, even with experienced vendors and detailed-looking proposals. The only real defense is knowing, before any signature goes on the contract, which line items the rate card never touched.

The Problem Starts With What the Estimate Leaves Out

A mid-size company scopes an internal operations platform. The vendor comes back with 1,000 development hours at $150 an hour. That’s $150,000, clean and simple, straight off the rate card, the same math behind most custom software development cost estimates.

Three months in, the number moves. Each of the additions traces back to the same missed line items, not to scope creep or a vendor padding the bill:

• QA. Two hundred hours once the platform’s five integrations start producing edge cases nobody scoped for.

• Security review. Required because the platform touches customer data, running for three weeks and costing $18,000, which nobody budgeted for.

• Infrastructure. Cloud hosting and deployment work for a real production environment, a different job entirely from standing up a demo, adding another $12,000 the original estimate never mentioned.

Every dollar traces to work the rate-card number was never built to price.

The final sum comes to $210,000, which is 40% more than the original number. Nothing about the build changed in that time. The estimate was the part that never held up.

Why Hourly Rate Times Headcount Fails

A rate card prices labor. Getting that labor to ship something that works and holds up over time costs more than the labor alone.

Multiply a developer’s hourly rate by an estimated number of hours and the result covers labor, not a budget. That number pays for time spent writing code. A good deal of real work happens alongside development, and none of it is included in that hourly rate. Skip pricing it upfront, and it shows up later anyway, usually as a change order once the build is underway, when the client has far less room to push back.  

Vendor size doesn’t change the pattern. A large agency with a polished proposal template can price a build off the same narrow rate-card logic as a solo freelancer, just with more zeroes attached. What determines whether the final number matches the quoted one is whether the estimate priced the full scope of work up front.

What A Rate Card Really Prices

Two very different data sources show exactly how narrow a rate card’s hourly number really is. The Bureau of Labor Statisticsputs the mean hourly wage for a U.S. software developer at $63.98. Buyers of outsourced development work pay closer to $202 an hour, according to IBISWorld’s 2026 Software Development Services procurement benchmark, which tracks pricing across vendors including Infosys, HCL Technologies, and Capgemini. 

Profit margin doesn’t explain that whole difference between $64 and $202. Most of it is project management, QA, infrastructure, and the overhead of running a team that a single developer’s billed hours never cover. 

Even before any of that, wages alone understate the cost of employing a developer. Benefit costs, health insurance, retirement contributions, payroll taxes, add roughly 43 cents for every dollar of wages at the average U.S. private employer, according to the Bureau of Labor Statistics’ most recent Employer Costs for Employee Compensation report. 

That alone puts the true cost of a $63.98-an-hour developer closer to $91 an hour, before a single hour is spent on a specific client project. It’s part of why a rate card built around a raw wage figure starts short before scope even enters the picture. 

The Five Line Items Rate Cards Miss

The categories missing from a rate-card estimate are rarely a mystery once a project is underway. They tend to be the same five, and they get scoped late, well after everyone has already signed off on the estimate. 

1. Design. UX research and prototyping have to happen before a single feature ships correctly.

2. Project management. Coordination across design, engineering, and the client scales with team size and project scope, not with how much code gets written.

3. QA. The cost climbs faster than the integration count does, through device testing, edge cases, and regression cycles.

4. Infrastructure. Cloud hosting and CI/CD pipelines are the DevOps work that keeps a product running once it’s live.

5. Compliance. Weeks a rate card never accounted for, covering security review, data handling requirements, and regulated-industry audits.

The Los Angeles digital product development agency, Goji Labs, has scoped this exact pattern across more than 500 shipped products, enough to know it by sight. 

“Clients almost always price the build and skip the parts that make it work in production. QA, compliance review, and the infrastructure to run the thing reliably can add a third to the number they walked in with,” says the agency’s Founder and CEO David Barlev. 

Those five categories are where production work starts showing up in the budget.

Why QA Cost Tracks Integration Count

Of the five line items rate cards miss, QA is the one most likely to blow past its original estimate. Its cost doesn’t scale with the number of developers writing code. It scales with how many systems the product has to work correctly against.

A standalone tool with no external dependencies needs a straightforward test plan. A platform integrating with five or six external systems needs a test matrix covering those integrations behaving normally, failing, and returning unexpected data, in every combination. 

“Add a seventh integration, and the testing surface grows by however many new interaction paths that integration creates with everything already in place,” Barlev says. 

A rate-card estimate built around headcount has no way to capture that kind of growth. QA overruns are one of the most common reasons a “final” number moves.

Compliance Cost Depends On Industry

Compliance is the line item most likely to be missing entirely from an initial estimate, and it’s a major reason enterprise software development cost estimates run over quote so often. Its cost depends more on the industry a product serves than on the size of the build.

A consumer app with no regulated data can often skip a formal compliance review. The same build serving healthcare, financial services, or children’s data needs security audits and data handling documentation before launch. 

That work can add weeks and tens of thousands of dollars, no matter how simple the underlying product looks. 

Vendors who price compliance-sensitive builds the way they’d price a general consumer app are the ones most likely to see costs run 30% to 40% over quote. 

AI Evaluation Is The New Line Item

AI development cost breaks down the same way a standard software build does, plus one line rate cards were never built to price. That line is evaluation infrastructure.

A reliable AI feature has to be tested against real-world edge cases before it ships. That testing doesn’t stop at launch. Model behavior drifts as usage patterns change, so the feature needs ongoing monitoring and re-evaluation after release too. That evaluation work sits outside traditional QA, with its own tooling and its own test datasets. It’s one reason AI product budgets, scoped like ordinary software builds, tend to run over. 

Enterprise AI work is entering a new phase, too. Deloitte’s long-running Tech Trends report calls 2026 the year the work moved from pilots and proofs of concept to production-scale deployment. That raises the stakes on evaluation cost specifically. A pilot can tolerate an AI feature that works most of the time. 

A production system serving real customers has far less room for that, and the evaluation infrastructure needed to close that distance is rarely in the first estimate a client sees.

AI Spending Is Growing Faster Than The Budgets Built For It

That evaluation shortfall sits inside a much larger wave of AI-driven spending. Global IT spending is projected to hit $6.37 trillion in 2026, up 14.2% from 2025, according to Gartner. Software alone accounts for $1,468 trillion of that, a 15.5% jump from the year before, most of it chasing AI. 

Pricing templates rarely move that fast. That’s exactly how evaluation work ends up missing from an estimate built on an older template. And it’s a big enough piece of the growth that it belongs in a build estimate before work begins.

“Most rate cards and estimation templates still reflect pre-AI software pricing, built around hours of coding and not accounting for ongoing model evaluation,” Barlev says. 

Until that catches up, treating an AI product budget like a standard software estimate will keep producing the same shortfall, for the same reason a $150,000 rate-card estimate becomes a $210,000 invoice.

In-House Teams Already Cover Some Development Costs

An in-house team may already cover some of the costs that get added separately to an external development estimate. Infrastructure and QA capacity may already sit inside the company’s existing overhead, while freelancers and small outsourced teams tend to price only the hours requested.

Everything else stays uncosted unless someone thinks to ask for it. A dedicated development partner usually lands somewhere in the middle, folding those categories into the engagement from day one so they never turn into add-ons later.

The software development pricing model a vendor quotes from matters as much as the hourly rate itself. The same $150 an hour means something very different depending on what’s bundled underneath it.

Price Every Category Before Signing

Turning a rate-card estimate into a line-item one usually just takes asking the right question before signing. That question matters most for software development services bought from an outside vendor, where nobody on the client side sees the labor directly. Renegotiating after the fact is the harder path.

If you’re signing off on the estimate, ask the vendor to break the proposal into components (design, project management, QA, infrastructure, compliance, and, where applicable, evaluation work), each priced separately rather than folded into a single blended rate. A vendor who can answer that fast, with real numbers for every piece, has clearly built this way before. 

One who has to build the breakdown from scratch is often the one whose original quote was closest to a guess. Asking the question up front surfaces most of that 30% to 40% difference before a contract is even in place. The resulting number is less clean than a rate-card estimate. It’s also the number that tends to hold.