March 13, 2026
Most first-time software buyers receive a quote before they understand how software is priced. That ordering matters. If you don't know how a number was constructed, you can't evaluate whether it's reasonable, compare it against other quotes, or know what happens when the scope changes.
This is especially true for AI product development, where scope is harder to pin down and the range between vendor quotes can be enormous. If you're building AI features, hiring engineers to develop a custom product, or evaluating agencies for custom AI development for B2B applications, the pricing model determines more than cost. It determines who carries the risk.
This article explains the three software development pricing models you'll encounter when hiring a development partner. Each has a legitimate use case. Each has a structural flaw. The goal isn't to declare a winner. It's to give you a framework so you know which model fits your project, and what to watch for in each.
How it works. The vendor charges a rate for time spent, either by the hour or by the day. You receive invoices against that rate as work progresses. The total cost is the rate multiplied by the hours logged.
When it makes sense. Hourly billing is appropriate when scope is genuinely undefined or ongoing. Maintenance retainers, bug fix agreements, and exploratory research phases are all reasonable candidates. If you're asking a vendor to investigate something rather than build something, paying for time is fair. The work itself is the output.
It also makes sense for small, trusted engagements where you have an existing relationship and some ability to monitor progress. If you've worked with a team before, know their pace, and can verify what's being done, hourly billing is low-friction and flexible.
The structural problem. Under hourly billing, the vendor's revenue increases with the hours worked. That's not an accusation of bad faith. It's an incentive structure. A vendor who takes longer earns more. A vendor who works efficiently earns less. Most vendors are professional enough to work against this, but the structure itself should give you pause on any project where you can't monitor progress closely or where scope might expand.
The second problem is cost uncertainty. You don't know what the project will cost until it's finished. Early estimates are often optimistic, not because vendors lie, but because complexity reveals itself during a build. By the time you know the real cost, you've already committed.
For non-technical buyers in particular, hourly billing on a large project is a significant risk. You're paying for activity, not outcomes. There's no contractual mechanism that connects the invoice to delivered value.
How it works. The vendor agrees to deliver a defined scope for a defined price. You know the number upfront. If the project stays within scope, you pay that number and nothing more.
When it makes sense. Fixed-bid works best for commodity projects with well-documented requirements. If you're building something that has been built many times before, with a clear spec and minimal ambiguity, a vendor can price it confidently without padding for unknowns. Off-the-shelf integrations, standard e-commerce builds, and templated applications with limited custom logic are reasonable candidates.
It also works when you have the technical fluency to write a complete spec and hold a vendor to it. The more precisely you can define "done" before signing, the more accurately a vendor can price it, and the less room there is for dispute later.
The structural problem. Fixed-bid pricing is only as reliable as the scope it's fixed against. Vendors know this. To protect their margin, most experienced agencies pad fixed-bid estimates by 30 to 50 percent to cover the risk of scope ambiguity. You're paying for certainty, but you're also paying for the vendor's insurance policy against your unclear requirements.
The deeper problem is change orders. Fixed-bid contracts define scope at a point in time. Requirements evolve. When they do, anything outside the original spec becomes a negotiation, often at an unfavorable rate, because you're no longer a prospect. You've already committed. The vendor holds the leverage.
This isn't speculation. A 2022 peer-reviewed study published in the Journal of Management Information Systems analyzed 5,392 IT projects and found that cost overruns follow a power-law distribution, meaning extreme overruns happen far more often than most managers expect. A Panorama Consulting report covering enterprise software projects through 2023 found that roughly a third ended over budget, with additional technology needs, resource constraints, and scope creep cited as the top causes. Three rounds of "minor" changes, each reasonable in isolation, can quietly move a $70,000 project to $110,000.
Fixed-bid pricing creates the appearance of cost certainty. It delivers it only when scope is genuinely complete before signing, which is rare on anything involving custom logic or AI product development.
How it works. The vendor prices by unit of work delivered rather than by time spent. The most common unit in software development is the story point, a relative measure of complexity assigned to each feature or task before work begins. You pay per story point completed, at a fixed rate.
Story point pricing requires the project to be broken down into discrete, estimable units before pricing can happen. That upfront work is the point. It forces both sides to define what's being built with enough specificity that it can be estimated and tracked.
When it makes sense. Outcome-based pricing is well-suited to feature development, AI builds, and any project where deliverables can be clearly defined in advance. It works particularly well when:
You want to prioritize features and control spend incrementally, adding or removing scope without renegotiating the entire contract.
You need visibility into what's been built and what remains, not just a progress update from the vendor.
The project involves meaningful complexity or AI components where hourly billing would create open-ended cost exposure.
It also works when you're a non-technical buyer who wants vendor incentives aligned with delivery. Under this model, a vendor earns by completing work, not by logging hours. Speed and quality are both in their interest. For companies pursuing custom AI development for B2B products, this alignment is especially valuable. AI features are hard to scope precisely, and a model that rewards shipped outcomes over logged hours reduces the risk of paying for a team that's "exploring" indefinitely.
The structural problem. Outcome-based pricing requires two things that not every vendor can provide: a consistent, transparent estimation process and a tracking system that connects story points to actual delivered features.
If a vendor inflates story point estimates, you pay more per feature than you should. If there's no independent way to verify what's been built against what was scoped, you're back to trusting vendor self-reporting. The model is only as good as the infrastructure behind it.
It also requires more upfront work from the buyer. You need a reasonably complete brief before estimation can happen. If your requirements are vague, the story point ranges will be wide, and cost certainty will suffer. The model rewards prepared buyers.
No single model is right for every project. The right question is: what does your project actually look like?
If your project is ongoing, exploratory, or genuinely undefined, hourly billing is appropriate. Pay for time when time is what you're buying. Set a clear budget ceiling and check in frequently.
If your project is a commodity build with a complete spec and minimal custom logic, fixed-bid is reasonable. Spend time on the spec before you sign. Read the change order provisions carefully. Understand what falls inside and outside the defined scope.
If your project involves custom feature development, AI components, or anything where you want cost certainty without sacrificing scope flexibility, outcome-based pricing is worth pursuing. Prioritize vendors who can show you their estimation methodology and give you real-time delivery tracking, not just a story-point rate.
A practical test: ask any vendor to break down their quote by feature. If they can, you have something to evaluate. If they can't, or won't, you have a lump sum and a relationship built on trust. That's not always wrong. But it should be a conscious choice, not a default.
Fraction uses outcome-based pricing at $149 per story point. Before any work begins, the project is scoped into features with story point ranges and assumption flags. Delivery is tracked through DevHawk, so buyers can see what's been built, what's in progress, and what's pending at any point during the engagement.
The model isn't right for every project. If you need ongoing maintenance support or want a vendor to explore an undefined problem space, hourly billing is a better fit. Fraction's model works best when you have a defined product to build and want cost certainty against a transparent scope.
If you're not sure what your project scope looks like yet, the Fraction Instant Project Estimator is a reasonable starting point. Put in a product brief, get back a structured feature breakdown with story point estimates. It's a free way to get a reference number before you talk to anyone.
Every pricing model is a contract about who carries the risk. Hourly billing transfers risk to the buyer. Fixed-bid transfers it to the vendor, who then prices it back into the quote. Outcome-based pricing distributes it according to scope clarity: the clearer the brief, the more predictable the cost.
Understanding which model you're being quoted under, and why, is the most useful thing you can do before you evaluate any proposal. The number matters less than the structure behind it.
Sources
