Hourly, fixed-bid, and outcome-based pricing each carry different risks. Here is how each model works, where it breaks, and which one fits your project.
Most first-time software buyers receive a quote before they understand how software is priced. That ordering matters. If you do not know how a number was constructed, you cannot evaluate whether it is reasonable, compare it against other quotes, or know what happens when scope changes. The pricing model determines more than cost — it determines who carries the risk.
Hourly billing: the vendor charges a fixed rate for time spent, either by the hour or day. Total cost equals the rate multiplied by hours logged. The buyer carries all cost uncertainty.
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 are asking a vendor to investigate something rather than build something, paying for time is fair. It also works for small engagements with an existing trusted vendor where you can monitor progress closely.
The structural problem is incentive misalignment. Under hourly billing, the vendor’s revenue increases with hours worked. 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 scope might expand or where you cannot monitor progress closely.
The second problem is cost uncertainty. You do not know what the project will cost until it is 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 have already committed. For non-technical buyers on large projects, hourly billing on a complex scope is a significant financial risk.
Fixed-bid pricing: the vendor agrees to deliver a defined scope for a defined price. Cost appears certain upfront, but the certainty is only as reliable as the completeness of the scope it is fixed against.
Fixed-bid works best for commodity projects with well-documented requirements — off-the-shelf integrations, standard e-commerce builds, templated applications with minimal custom logic. If you have the technical fluency to write a complete spec and hold a vendor to it, fixed-bid can be appropriate. The more precisely you can define “done” before signing, the more accurately a vendor can price it.
The structural problem is that vendors know scope rarely stays fixed. To protect their margin, most experienced agencies pad fixed-bid estimates by 30 to 50 percent to cover the risk of ambiguity. You are paying for certainty — but you are 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. Anything outside the original spec becomes a negotiation at rates that favor the vendor, because you have already committed. A 2022 peer-reviewed study in the Journal of Management Information Systems analyzed 5,392 IT projects and found that cost overruns follow a power-law distribution — extreme overruns happen far more often than most managers expect. A Panorama Consulting report found that roughly a third of enterprise software projects ended over budget. Three rounds of “minor” changes can quietly move a $70,000 project to $110,000.
Story point pricing: the vendor prices by unit of work delivered rather than time spent. Each feature is assigned a story point estimate before work begins. You pay per point completed at a fixed rate.
Story point pricing requires the project to be broken into discrete, estimable units before pricing happens. That upfront work is the point — it forces both sides to define what is being built with enough specificity that it can be estimated and tracked. A vendor earns by completing work, not by logging hours. Speed and quality are both in their interest.
This model 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, when you need visibility into what has been built and what remains, and when the project involves AI components where hourly billing would create open-ended cost exposure.
The structural risk is estimate inflation and poor delivery tracking. If a vendor inflates story point estimates, you pay more per feature than you should. Without a tracking system that connects story points to delivered features, you are back to trusting vendor self-reporting. The model also requires a reasonably complete brief upfront — vague requirements produce wide estimate ranges and reduce cost certainty. Outcome-based pricing rewards prepared buyers.
Fraction’s Instant Project Estimator turns a product brief into a structured feature breakdown with story point estimates. Free and instant — no calls required.
Scope Your Project for FreeFree and instant. No call required.
The table below summarizes the key dimensions across all three models. No single model dominates every category — the right choice depends on your project’s scope definition, your risk tolerance, and your ability to monitor delivery.
| Dimension | Hourly | Fixed-Bid | Outcome-Based |
|---|---|---|---|
| Cost Certainty | Low — total cost unknown until done | Medium — padded upfront, change orders add up | High if scope is well-defined |
| Scope Flexibility | High — anything can be added | Low — changes trigger renegotiation | Medium-High — reprioritize without full renegotiation |
| Vendor Incentive Alignment | Weak — more hours = more revenue | Partial — delivery incentive, but change orders shift it | Strong — vendor earns by shipping work |
| Best Fit | Ongoing work, undefined scope, trusted relationships | Commodity builds with a complete, stable spec | Feature development, AI builds, complex products |
| Main Risk | Runaway hours, no contractual link to outcomes | Scope creep via change orders, estimate padding | Estimate inflation, poor delivery tracking |
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 are buying. Set a clear budget ceiling and check in frequently. Without close monitoring, hourly billing on a large undefined project is an open-ended financial commitment.
If your project is a commodity build with a complete spec and minimal custom logic, fixed-bid is reasonable. Spend real time on the spec before you sign. Read the change order provisions carefully. Understand exactly what falls inside and outside the defined scope — because anything outside becomes a negotiation after you have already committed.
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 card.
A practical test before signing anything: ask the vendor to break down their quote by feature. If they can, you have something to evaluate and compare. If they cannot — or will not — you have a lump sum and a relationship built on trust. That is 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 has been built, what is in progress, and what is pending at any point during the engagement.
The model is not 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.
Every pricing model is ultimately a contract about who carries the risk. Hourly billing transfers it to the buyer. Fixed-bid transfers it to the vendor, who 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 are being quoted under — and why — is the most useful thing you can do before evaluating any proposal. The number matters less than the structure behind it.
Hourly billing charges for time spent regardless of what gets built, so cost uncertainty sits entirely with the buyer. Fixed-bid locks in a price against a defined scope, but vendors typically pad estimates by 30–50% to cover scope ambiguity, and change orders can push the final number well past the original quote. The core difference is who carries the risk of scope uncertainty.
Hourly billing is appropriate when scope is genuinely undefined or ongoing — maintenance retainers, bug fix agreements, and exploratory research phases are all reasonable candidates. It also works for small engagements with an existing trusted vendor where you can monitor progress closely. The key condition is that you are buying time, not a specific outcome.
Outcome-based pricing charges a fixed rate per story point — a relative unit of work complexity. Before work begins, the project is broken into discrete features, each assigned a story point estimate. You pay per point completed. This aligns vendor incentives with delivery rather than hours logged, and gives buyers a transparent view of what has been built versus what remains.
Fixed-bid contracts define scope at a single point in time. Requirements evolve during any meaningful build. Each change outside the original spec becomes a negotiated change order, often at unfavorable rates because the buyer has already committed. A 2022 Journal of Management Information Systems study of 5,392 IT projects found that cost overruns follow a power-law distribution — extreme overruns are far more common than most buyers expect.
The main risks are estimate inflation and poor delivery tracking. If a vendor inflates story point estimates, you pay more per feature than you should. Without an independent tracking system connecting story points to delivered features, you are back to trusting vendor self-reporting. The model also requires a reasonably complete brief upfront — vague requirements produce wide estimate ranges and reduce cost certainty.
Outcome-based pricing tends to fit AI projects best. AI features are complex to scope and can involve open-ended exploration that would make hourly billing expensive and unpredictable. Fixed-bid works poorly when requirements evolve, which is almost always the case with AI builds. Story point pricing rewards shipped outcomes over logged hours and gives non-technical buyers visibility into what has actually been delivered.
Praveen Ghanta is a five-time founder and serial entrepreneur. He is the founder of DevHawk.ai, an AI-powered engineering management platform, and Fraction.work, which connects fast-growing companies with top fractional tech and growth marketing talent. Previously, he founded HiddenLevers, a risk analytics platform for wealth management that he bootstrapped from inception to acquisition by Orion Advisor Solutions in 2021, serving thousands of advisors and $600B in assets. He earlier founded SmartWorkGroups, acquired by Intralinks in 2000.
Connect on LinkedIn →Describe your software or AI project. Get a full scope with story-point pricing, sprint estimates, and a downloadable plan in minutes. No calls, no waiting.
Scope Your Project for FreeWorking on a data strategy? Talk to a Fraction CTO. → Book an intro call
