- Hourly billing is appropriate for undefined or ongoing work, but creates open-ended cost exposure on large projects.
- Fixed-bid delivers apparent certainty, but vendors pad estimates 30–50% and change orders erode savings quickly.
- Outcome-based story point pricing rewards delivered outcomes over logged hours. It was DevHawk's own model in our Fraction era, and its limitation is that it still meters every unit of scope.
- Flat monthly pricing charges for a crew of AI agents rather than for hours or points, which removes both the hourly meter and the fixed-bid risk premium.
- Ask any vendor to break down their quote by feature. If they cannot, you have a lump sum built on trust, not transparency.
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.
How does hourly billing work, and where does it break down?
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.
How does fixed-bid pricing work, and why do projects still run over budget?
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.
How does outcome-based story point pricing work?
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.
We know this model well because it was ours. In our Fraction era, we priced work at $99 per story point, and we retired the model in 2026. Here is the honest assessment of it, from the people who ran it.
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.
The model genuinely improved on hourly and fixed-bid. Buyers saw cost by feature before committing, and removing a feature visibly lowered the price. It worked especially well for feature development and any project where deliverables could be clearly defined in advance.
But its limitation is structural, and it is the same limitation hourly and fixed-bid share: it meters scope. Every feature is a line item. Every addition is a negotiation. Estimate inflation is a real risk (if a vendor inflates story point estimates, you pay more per feature than you should), and without independent delivery tracking you are back to trusting vendor self-reporting. The model also rewards prepared buyers and punishes vague briefs.
All three of these models price the work. The newest model prices the capacity.
How does flat monthly pricing work, and why is it the AI-era model?
Flat monthly pricing: the vendor charges a fixed monthly fee for development capacity, typically a crew of AI agents covering the full development job, rather than metering hours, scope, or points.
AI collapsed the cost of producing software. When a crew of AI agents can handle requirements, code, testing, shipping, and maintenance continuously, the old question (“what does this feature cost?”) stops being the right unit of account. The new question is “how much capacity do I need?”
At DevHawk, flat monthly comes in two forms. Run the agents with your own team from roughly $3,000 per agent per month, plus a one-time $9,000 onboarding in the first month for customization, integration, and training; you connect your own AI provider account and pay AI usage directly, at cost. Or have DevHawk run the factory for you from $9,000 per month with a three-month minimum; no setup fee, and AI usage is included.
What the model removes: the hourly meter (working efficiently no longer costs the vendor revenue), the fixed-bid risk premium (there is no scope bet to insure), and the change-order negotiation (adding a feature consumes capacity and gets prioritized, rather than triggering a renegotiation). What it asks of you instead: an honest conversation about how much capacity your roadmap actually needs, and a minimum commitment long enough for the factory to learn your systems.
Where it does not fit: one-off projects so small that a single month of capacity exceeds the work, or exploratory engagements where you genuinely do not know what you want built. For the first, buy off-the-shelf or find a small fixed-bid shop. For the second, pay for time.
How do the four pricing models compare side by side?
| Dimension | Hourly | Fixed-Bid | Outcome-Based | Flat Monthly |
|---|---|---|---|---|
| Cost certainty | Low: total cost unknown until done | Medium: padded upfront, change orders add up | High if scope is well-defined | High: fixed monthly, sized to capacity |
| Scope flexibility | High: anything can be added | Low: changes trigger renegotiation | Medium-high: reprioritize without full renegotiation | High: priorities shift within capacity |
| Vendor incentive alignment | Weak: more hours = more revenue | Partial: delivery incentive, but change orders shift it | Strong: vendor earns by shipping work | Strong: retention depends on continuous delivery |
| Best fit | Ongoing exploration, undefined scope | Commodity builds with a complete, stable spec | Feature development with a well-defined brief | Roadmaps: continuous building and running |
| Main risk | Runaway hours, no link to outcomes | Scope creep via change orders, estimate padding | Estimate inflation, poor delivery tracking | Paying for capacity you don’t use |
How do you choose the right pricing model for your project?
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.
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, and read the change order provisions carefully.
If your project is a single well-defined build and you want feature-level cost transparency, outcome-based pricing still exists in the market. Prioritize vendors who can show you their estimation methodology and give you real-time delivery tracking, not just a rate card.
If you have a roadmap rather than a project, things to build and things to keep running, flat monthly is built for exactly that. You size the capacity, the agents work continuously, and the cost stays fixed while priorities move.
A practical test before signing anything: ask the vendor to break down their quote by feature (or, for flat monthly, by capability). 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.
Not sure which model fits your project?
Book a systems review: a working conversation about what you're building, which agents fit, and what the monthly would be.
Book a systems reviewFree intro call. No commitment.
Where does DevHawk fit in the pricing model landscape?
DevHawk prices on the flat monthly model: run our AI agents with your own team from roughly $3,000 per agent per month (plus one-time onboarding), or have us run the factory from $9,000 per month with AI usage included. Before any engagement, a systems review scopes which agents and capabilities your roadmap actually needs, and you are never billed for capabilities you don’t use.
We came to this model the honest way: we ran the outcome-based model for years at $99 per story point, and it was a real improvement on hourly and fixed-bid. But once AI agents collapsed the cost of producing software, metering scope stopped making sense for us and for buyers. Charging per point of work is a habit from the era when work was scarce.
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. Flat monthly removes the scope bet altogether and replaces it with a capacity decision. 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.
Frequently asked questions
What is the main difference between hourly and fixed-bid pricing?
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.
When does hourly billing make sense for a software project?
Hourly billing is appropriate when scope is genuinely undefined or ongoing: exploratory research phases and investigations are 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.
How does outcome-based story point pricing work?
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. It was DevHawk’s own model in our Fraction era, at $99 per point, before we moved to flat monthly pricing in 2026.
Why do fixed-bid projects often run over budget?
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.
How does flat monthly pricing work?
Flat monthly pricing charges a fixed fee for development capacity instead of metering hours or scope, typically a crew of AI agents that handles requirements, code, testing, shipping, and maintenance continuously. At DevHawk, that’s roughly $3,000 per agent per month run by your own team (plus one-time onboarding), or a managed factory from $9,000 per month with AI usage included. Adding a feature consumes capacity and gets prioritized rather than triggering a change order.
Which pricing model is best for an AI software project?
Flat monthly tends to fit AI projects best. AI features are complex to scope, which makes hourly billing unpredictable and fixed-bid heavily padded, and even story-point pricing turns evolving requirements into a stream of re-estimates. Capacity pricing absorbs that evolution: the agents keep working, priorities shift, and the monthly stays fixed.
- Flyvbjerg, B., Budzier, A., Lee, J.S., Lunn, D., & Bester, D.W. (2022). The Empirical Reality of IT Project Cost Overruns. Journal of Management Information Systems, 39(3), 607–639. https://www.tandfonline.com/doi/full/10.1080/07421222.2022.2096544
- Panorama Consulting. (2024). 2024 ERP Report. Via Accounting Today, March 6, 2024. https://www.accountingtoday.com/news/one-third-of-enterprise-software-projects-have-time-cost-overruns-says-report