Hourly rate or fixed price: who pays when the job turns out bigger

Search fixed price software development and the commercial results are published by companies that sell software development, and every one of them lands on the model it happens to sell. The pages that do not sell development sell time tracking, or are written for the freelancer deciding what to put on the invoice. Nobody on either search is writing for the person paying.

Across the two searches, read on 31 August 2026, the commercial results were development shops, a staffing shop, a talent marketplace and a time-tracking vendor. Their guides run the same order: define both models, set the good and bad points in two columns, finish on the one the publisher happens to sell. What none of them prints is the condition a buyer is entitled to attach before agreeing to either one, which is strange, because there is a buyer who is required to write that condition down in public and whose rule book is free to read.

The two rules quoted below were read on the United States federal acquisition site on 31 August 2026, alongside the government’s own guidance for buying software this way and the six seller guides holding page one for this search on the same day. The rules supplied the conditions attached to each way of paying; the seller guides supplied what a company says about those conditions while selling one of them.

One price for the job when somebody has read the code and can name the work in a sentence. Hours when nobody can yet say what the work contains, and then only against a written ceiling. Anything else is a bet on a guess, and the arrangement decides who pays for the guess being wrong.

What fixed price software development actually means

One agreed figure for a named piece of work, paid whether the work takes the seller forty hours or four hundred. That is the whole mechanism, and the federal acquisition rules state its consequence more plainly than any company selling it: a firm-fixed-price contract “places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss”, and it “provides maximum incentive for the contractor to control costs and perform effectively and imposes a minimum administrative burden upon the contracting parties”. Both sentences sit in the description at FAR 16.202-1, read 31 August 2026, where the section shows an effective date of 13 March 2026.

Read that from the paying side and the trade is obvious. You are handing the seller every hour nobody predicted. Nobody gives that away for nothing, and the sellers on this search say so on their own pages.

Saigon Technology’s comparison guide, marked updated 12 August 2026 and read 31 August 2026, lists it in its own drawbacks column: vendors often add buffers of 20 to 50 percent to cover their risk, so the buyer pays more than necessary. SOLTECH’s time-and-materials guide, read the same day, gives the mechanism in one sentence. A provider committing to a fixed price on work that has not been described clearly “will most likely add a risk factor, or padding, to protect themselves.” As of 31 August 2026, SOLTECH’s page displays no publication or update date to an automated read, so the read date is the only date that sentence carries.

Neither page publishes a figure of its own. As of 31 August 2026, neither Saigon Technology’s comparison guide nor SOLTECH’s time-and-materials guide renders any hourly rate or price to an automated read, which is worth knowing before you treat either one as a source on what anything costs.

So the certainty you are buying is real, and it is priced. It sits inside the number, and unless the person quoting has read your code, the padding is doing most of the work.

Somebody in AxonBuild’s outreach corpus describes what that looks like from the buying side. They asked a developer for a small internal tool, were given a price and a date to go with it, decided against both, and then put the thing together themselves inside one working day. Their number is not repeated here and it does not matter. The gap between a quote for an undescribed job and the job itself is the padding, and on small work the padding can be larger than the work.

What you are really buying when you pay by the hour

Paying by the hour has a formal name in the one place where a buyer is obliged to write down why they chose it. The federal acquisition rules call it a time-and-materials contract, and define the payment as “Direct labor hours at specified fixed hourly rates that include wages, overhead, general and administrative expenses, and profit” plus “Actual cost for materials”. The rate already contains the seller’s overheads and the seller’s profit, so it is a long way from a wage, and comparing it against a salary tells you nothing.

Three conditions come attached to it at FAR 16.601, read 31 August 2026 with an effective date of 13 March 2026, and each one translates cleanly into a question a private buyer can ask.

The first is a sentence no seller has any reason to volunteer: “A time-and-materials contract provides no positive profit incentive to the contractor for cost control or labor efficiency.” In plain words, nothing in the arrangement pays the seller to be quick. Every hour spent is an hour billed. That is the shape of the deal rather than an accusation about anybody’s character, and the rule book states it out loud instead of hoping nobody works it out.

The second is the fix for the first: “The contract or order includes a ceiling price that the contractor exceeds at its own risk.” That means a number in writing, past which the extra hours stop being yours, rather than a budget you both keep an eye on. In the federal rules it is a condition of using hours at all.

The third is the one that reframes the whole question: “The contracting officer prepares a determination and findings that no other contract type is suitable.” Somebody has to write down, before any hours are agreed, why nothing else fits. Hours are the fallback, not the starting point.

Almost nobody offers a private buyer the second condition unprompted, and nobody at all applies the third. You can apply both yourself, in two sentences, in an email.

Who pays when the job turns out bigger

Whichever side did not name the work. Hours put every extra day on you; one agreed figure puts it on the seller, who has already priced for the possibility. Both arrangements survive an overrun. What separates them is which side finds out about it, and when.

The second row is the fee, and it is the easiest one to forget you agreed to. A fixed price cuts both ways, and on a job that turns out easier than expected you have already paid for the hard version. That is fair enough, as long as you knew that was the trade.

The third row is where an app that already runs differs from a build that has not started. The government’s own guidance for buying software agrees with the rules on this point: the TechFAR Hub page on designing a contract for agile development says that “FFP contract types have the advantage of shifting risk to the contractor, which gives the contractor the maximum incentive to control costs and perform efficiently” where requirements are easily identifiable, and that hours “may be suitable if circumstances do not allow the agency to define its requirements sufficiently to allow for a FFP type contract and uncertainties involved in contract performance do not permit costs to be estimated with sufficient accuracy to use a FFP arrangement”. Read the TechFAR Hub contract design page on 31 August 2026. As of that date the page displays no publication or update date to an automated read.

The fourth row is the one that decides how the arrangement feels to live inside. Under one agreed figure, anything you add after the number is set has to be talked about, because the seller has no room to absorb it. That conversation is often described as friction, and it is the arrangement working: every addition gets weighed against what it costs before it gets built. Under hours the same addition needs no conversation at all. It just appears in the next total, which is the more comfortable of the two arrangements right up to the moment you read the invoice.

The last row rests on how the money is staged rather than on how it is calculated. Metamindz’s cost comparison post, dated 14 May 2025 and read 31 August 2026, prints the split it treats as typical for a fixed price: 30 percent upfront, 40 percent midway, 30 percent on completion. The same post says that materials billed inside an hourly arrangement carry a markup, usually 15 percent to 35 percent, which is a line item most buyers never think to ask about. How the money is held between the moment work starts and the moment you accept it, and what each way of holding it does when somebody walks away, is worked out arrangement by arrangement elsewhere.

What each hiring route asks for, on an application that is already live, is set out where what it costs to put somebody onto an existing app, route by route compares those four routes, and this page does not repeat a single band of it. What one hour of somebody’s time sells for, by experience and by the kind of work, is gathered separately, and no rate band appears on this page at all.

Fixed cost software development with a ceiling, the option almost nobody offers you

Two sources on this search arrive at the same arrangement from opposite directions. The seller guides read alongside them on 31 August 2026 all present the question as a choice between two things, which is the part that costs buyers money.

The federal rules get there by requirement. Hours are allowed only with a ceiling the seller crosses at its own expense, which is the second condition above.

Atomic Object gets there by choice. The shop publishes its own model as an alternative to the two everybody else compares, and describes it in its own words: “This budget is fundamentally based on an hourly rate of work for each software maker on the project over a set period of time. As such, this is fundamentally a T&M contract with a Not To Exceed limit.” Its page sets the risk against the two standard models directly, putting the risk on the seller under a fixed price, on the buyer under open hours, and shared between both under its own, so that the financial risk “does not fall solely on a single entity”. Read 31 August 2026; as of that date the page displays no publication or update date to an automated read, and publishes no rates.

A regulator requiring a cap and a company voluntarily selling one is about as much agreement as this subject produces. For work nobody can size yet, that shape is the practical answer: an hourly rate, a written number the hours cannot pass, and a rule that the seller tells you when the spend crosses about half of it rather than when it runs out.

Ask for it in those words. Sellers who work by the hour can usually say yes, because a cap moves the overrun risk to them and an honest estimate is still a guess, so expect them to ask for a defined scope or a checkpoint in return, and judge the cap by those terms rather than by whether they accept it.

Why open-ended hours end in half-finished apps

On an application a tool generated, the code cannot settle the argument about whether the work is done. Of the 21 third-party applications inside AxonBuild’s 420-finding audit ledger, drawn from 26 real applications read in June and July 2026, at least 18 carried no automated check that ran anywhere in the codebase, established by documented analysis of the code rather than by any hands-on run. The AxonBuild audit corpus sets out how that cohort was assembled.

That figure is about proof rather than quality. When nothing in the repository reports whether a change worked, neither side can point at the app and settle it. The buyer sees a screen that looks right. The seller sees a task marked complete. Nothing independent of either of them agrees or disagrees.

An hourly arrangement has no natural end in that situation. There is no moment the money is supposed to stop, because there is no written statement of what finished means and nothing in the code that would confirm it. The work stops when the buyer runs out of patience or budget, which is a different event from the app being usable. That is why what to do when the person building your app stops is a page about recovery rather than a page about billing: by the time it applies, the arrangement has already failed to define an ending.

One agreed figure forces the sentence to be written, and not through any extra honesty on the seller’s side. Nobody can put a number against a thing they have not described, so the description arrives as a condition of the quote, and the description is the ending.

The sentence does not have to be long, and it is easier to write than most owners expect, because it is about behaviour rather than about code. A customer who signed up yesterday can reset their password from the email link and get back in. The failed payments in the last month appear on the orders page with a reason next to each one. Somebody who is not logged in gets nothing from the reports page. Each of those can be checked by a person who cannot read a line of the codebase, which is exactly why they work as an ending, whichever way the work is billed.

When paying by the hour is the honest answer

There is a job where hours are not the weaker option, and it is the first one. Somebody must open the code and the running app before anybody can say what is actually wrong, and reading a codebase for the first time is genuinely unpredictable work. An app with three services and no documentation takes as long as it takes.

Paying by the hour for finding out, and one price for doing the named thing afterwards, is the arrangement that matches the actual uncertainty. It also matches the government’s own test: hours where the requirement cannot yet be defined, one figure once it can. Two other cases fit the same rule. A fault nobody has been able to reproduce is a search rather than a repair, and any fixed number attached to it is guesswork with a decimal point. Work that arrives unpredictably, a few hours here and there across a live app, has nothing to quote against.

Two arrangements sit either side of that one and are counted elsewhere. Buying a block of somebody’s availability month after month, rather than either hours or a named job, is a third arrangement with its own arithmetic. Paying a builder’s meter to keep trying is its own way of buying hours, and it is counted against a person’s time on its own page.

Zistemo, a time-tracking vendor rather than a seller of development work, adds a day rate as a third model on the same question. Its post is written for the person sending the invoice, opening on what to settle for “as a self-employed person”, and as of 31 August 2026 it displays no publication or update date to an automated read. Worth knowing, because most of the advice you will find on this question is written from that chair.

What makes one price possible at all

Three things, and all three are yours to produce. Somebody has to have seen the actual code and the running app. What “working” means has to exist as sentences rather than as an idea in your head. And the piece of work has to be small enough that one person can hold all of it at once.

The short, specific thing you send so a person can put one number against your job has a page to itself, and nothing of it is repeated here. The same is true one level up: deciding whether the app is worth repairing at all comes before deciding how to pay for the repair, and fixed cost for app development is only a sensible question once that has been settled. Whether the next dollar buys more credits or an hour of a person’s attention is arithmetic done on its own page, and this page does not redo it.

The market those repair figures come out of is tracked where what published cleanup prices actually cover counts it, and the one-paragraph version of today’s question lives there too. What a whole build sells for, before any of this is decided, is a different question with its own bands.

Upwork’s resources article on hourly against fixed-rate projects would not open to an automated fetch on 31 August 2026. Two addresses were tried, upwork.com/resources/fixed-price-vs-hourly-rate and upwork.com/resources/hourly-vs-fixed-rate, and both came back with an HTTP 403 status, so nothing about what that article contains is treated as a fact anywhere on this page. If it opens later, whatever it says will be dated to the day it was read.

Four of the pages quoted above are published by companies selling the work being priced, so each is named and credited by address rather than linked. Those four are saigontechnology.com/blog/time-and-material-vs-fixed-price/, soltech.net/time-and-materials-vs-fixed-price/, metamindz.co.uk/post/fixed-price-vs-hourly-contracts-cost-comparison, and Atomic Object’s fixed-budget model page inside atomicobject.com/client-resources/. Zistemo sells time tracking rather than development work, and its post at zistemo.com/blog/daily-rate-hourly-rate-or-agree-on-a-fixed-price/ is credited the same way because the point taken from it is a general one. The three government pages are linked where they are quoted, because a regulator publishing the conditions on its own purchasing is not selling anything.

How AxonBuild prices the work

AxonBuild quotes a fixed price, and only after checking the app. The 20-minute video call is free: you show Bilal what should work and what happens instead, and he talks through what needs checking. If you want him to make the change, he checks the app and gives you a fixed quote, you agree what the app should do, and you pay after you see it working. The check comes before the number precisely because of everything above: a figure produced before anybody has read the app is a padded guess, whichever way it is billed.

That is the whole of it. No hourly figure, no monthly figure, and no number attached to work nobody has looked at yet.

Common questions about paying hourly or a fixed price

Should I pay a developer by the hour or a fixed price?

One price for the job, if the person quoting has read your code and the work can be named in a sentence. Hours if nobody can yet say what the work contains, and in that case only with a written ceiling the seller crosses at their own expense. The federal acquisition rules apply the same test to public buyers: hours are permitted only where nothing else fits.

Is a fixed price always more expensive than paying hourly?

No, and the comparison is not really available. A fixed price includes a buffer for the hours nobody predicted, so on a job that runs smoothly you pay more than the hours would have cost. On a job that runs badly you pay less. Saigon Technology’s guide, updated 12 August 2026, puts vendor buffers at 20 to 50 percent, which is what the certainty costs.

What is the difference between time and materials and a fixed price?

Time and materials is the formal name for paying by the hour plus the cost of anything bought along the way. FAR 16.601 defines it as direct labour hours at fixed hourly rates covering wages, overhead, general and administrative expenses and profit, plus actual cost for materials. A firm fixed price is one figure agreed in advance regardless of hours. The difference is entirely about who absorbs an overrun.

What is a capped hourly agreement, and does it actually protect me?

It is an hourly arrangement with a written number the total cannot pass without your agreement. It protects you to the extent that the cap is real and stated in writing: FAR 16.601 requires a ceiling that the contractor exceeds at its own risk, and Atomic Object sells the same shape commercially, describing it as an hourly arrangement with a not-to-exceed limit. Ask for the cap and for a warning partway to it.

Can anybody give me a fixed price before they have read my code?

They can give you a number. It will contain a guess about how bad the code is, and that guess will be priced defensively, because the person quoting carries every hour they got wrong. A number that arrives before anybody has opened the app is telling you about the seller’s appetite for risk rather than about your application.

What happens if the work turns out to be bigger than the price we agreed?

Under one agreed figure the seller absorbs it, which is the point of the arrangement and the reason the figure was not the lowest one you were offered. Under hours you absorb it. The middle option is an hourly arrangement with a ceiling: the seller carries everything past the number, and you find out before you get there rather than afterwards.

What should I do if a developer will only work by the hour?

Ask for two things rather than arguing about the model. A ceiling in writing, past which extra hours are theirs, and a note from them the moment spending crosses about half of it. Both are ordinary requests and a seller who has estimated honestly loses nothing by agreeing. If both are refused on a job that has already been described in detail, that refusal is the useful information.

Is a flat fee the same thing as a fixed price?

In practice yes, for one named piece of work. The words that matter are not the label but what is attached to it: what specifically is included, what happens if the work turns out larger, and when the money moves. A flat fee for an unnamed job is the same guess as a fixed price for an unnamed job, and it will be padded the same way.