What am I actually paying for in an hourly software quote?

You are paying for people and elapsed time: the number of engineers assigned, multiplied by the hours they book, multiplied by a rate. That was a reasonable measure of the cost of building software when most of the effort was a person typing an implementation, and it is a much weaker measure now that a large share of the implementation is generated.

Why does hourly billing penalise a supplier for using AI?

Because the invoice is a function of hours, so any tool that removes hours removes revenue. An agency at $150 an hour that finishes a feature in four hours instead of ten bills $600 rather than $1,500 for the same delivered result, which means the better they get, the less they earn.

Does that mean hourly billing is always wrong?

No, it still fits open-ended work where nobody can define the outcome in advance, such as ongoing support or exploratory research. It stops fitting the moment the deliverable is describable, because then you can price the deliverable rather than the hours it takes to produce it.

What should replace hourly billing?

Price the outcome and the timeline instead of the input, with a scope specific enough that both sides know what finished means. A defined deliverable can be priced directly, so the supplier is paid for the result rather than for the hours spent producing it. What matters is whether the contract pays the supplier more for taking longer, and a scoped price removes that incentive on its own.

If the code is generated, why does software still cost money?

Because the expensive work still exists in other parts of the project. Deciding exactly what to build, proving that what got built works, integrating with systems you do not control, and operating it after launch are all still real work, and they are now the majority of the cost.

How can I tell if a supplier is passing AI savings to clients?

Ask how their price changed after they adopted AI, and how they add capacity when a project needs to go faster. A supplier that answers by describing more people is still selling headcount, whatever their marketing says, because headcount is still the mechanism that grows their revenue. A supplier passing on the saving will point to a smaller team and a lower total instead.

Is a cheaper hourly rate a cheaper project?

Usually not, because rate and total cost are different numbers. A low rate attached to a long timeline and a large team routinely costs more than a higher rate attached to a small team that finishes, which is why the total and the scope matter more than the hourly figure.

What is a reasonable market rate for software development?

Clutch's pricing guide reports that most software development companies listed there charge between $24 and $49 an hour, with ranges varying by region up to $100 to $149 in markets such as Canada and Australia. Treat those as context for reading a quote rather than a target, since the rate says nothing about how many hours will be billed.

Why do agencies grow by hiring?

Because under an hourly or staffing model, headcount is the mechanism that grows revenue, so adding people is both how the work gets done and how the business gets bigger. That incentive is invisible on your invoice and it affects every staffing decision made on your project.

Does a smaller team mean lower quality?

Not when the verification is automated rather than manual. Quality comes from what has to pass before a change is released, so a small team with a strong automated check can hold a higher standard than a large team relying on review capacity that does not grow with the work.

How should I compare two quotes that are structured differently?

Convert both to a total for the same defined scope and timeline, then ask each supplier what happens to that number if the work takes longer than planned. The structure that makes the supplier share the risk of overrun is the one that matches your interest.

What questions should I ask before signing?

Ask what the total is for this scope, what changes it, who is actually on the team, what has to pass before code is merged, and how the supplier adds capacity if things fall behind. Specific answers to all five tell you more than any price list, because a rate says nothing about how many hours will be billed against it. A supplier who answers "more people" to the last question has not changed how their business scales.

Stop paying for headcount you no longer need: Reveneau

Every software quote you have ever received is the same equation in a different format. People, multiplied by hours, multiplied by a rate. The agency presents it as a proposal, the staffing firm calls it a blended rate, the enterprise vendor hides it in a statement of work. It is the same equation.

That equation was honest for a long time. When building software meant a person typing an implementation, hours were a decent measure of cost, and headcount was a decent measure of capacity. Both measures are now much weaker than they were, and almost nobody has changed their prices.

Here is what that looks like on the buying side.

1. The market still prices the input

Clutch's pricing guide, updated this month, reports that most software development companies listed there charge between $24 and $49 an hour, with regional ranges going up to $100 to $149 in markets such as Canada and Australia. The average project on the platform comes in around $132,000 and runs about 13 months.

None of those numbers is a price for a working product. They are prices for a quantity of people-time, and the total is whatever that quantity turns out to be. Which is why the rate you negotiate so carefully is the least interesting number in the document. A low rate attached to eleven people and thirteen months is more expensive than a high rate attached to four people and four months, and the low rate is the one that feels like success in the meeting.

Meanwhile, 90% of technology professionals now report using AI at work. The input being billed is not the input being consumed.

2. The model now rewards your supplier for being slow

Take an agency billing $150 an hour. A feature that used to take one of their engineers ten hours bills at $1,500. That same engineer, generating the implementation properly, finishes it in four. Same feature, same client, same standard. The invoice is now $600.

The arithmetic is not complicated and it is not hypothetical. Under an hourly model, the biggest change in software delivery productivity in a decade becomes a cut in revenue. Every hour the supplier saves is an hour they cannot bill.

Nobody sat down and designed that incentive. It is what happens when a pricing model is still used after the cost structure it was built for has changed. But look at how a rational supplier responds to it, because all three options affect you.

They can decline to use the tools seriously, and bill you for ten hours of work that needed four. They can use the tools and raise the rate to compensate, which is fine if they tell you and dishonest if they do not. Or they can keep growing the only way an hours business grows, by adding people, which is why the team on your project tends to get larger rather than better.

In none of those three does the saving reach you. That is not a moral failure on the supplier's part. It is the model doing exactly what it was designed to do, in a world it was not designed for.

The staffing version of this is worse, because it is harder to see. When you pay per person rather than per hour, the invoice does not change at all when the work gets faster. Six engineers at a monthly rate cost the same in a month where they delivered twice as much, so the entire benefit of better tooling goes to whoever is supplying you the people. You will not find that in a status report. It shows up only as a roadmap that finishes about when you expected it to, on a team that quietly got much more productive.

3. What we do instead, and why it goes into the price

We chose the other approach, and it is worth being concrete about it because the phrase "AI-powered" has lost its meaning.

We do not add people to go faster. Every line of the implementation is generated, and every change has to pass an eval suite written from the specification before it reaches your branch. Capacity comes from the generation and safety comes from the eval check, so the thing that used to require a bigger team does not require one.

That has a direct consequence for what a build costs. The work is staffed small by design, and we price it on what it actually takes us to deliver rather than on what the market is used to paying for the size of team this kind of build normally gets. The gap between those two numbers is the whole point. It goes into your price. If it went into our margin instead, we would be a normal agency with better tooling, and you would have no reason to prefer us.

We are not going to put a percentage on it. We could publish a figure that makes the saving sound impressive and nobody could check it, which is exactly why it would be worth nothing. Ask us for a total against your scope and compare it to the other quotes on your desk. That is a number you can verify, and it is the only one that matters.

What actually still costs money

The risk in an argument like this is that it turns into "software is nearly free now", which is wrong and will cost you a project if you believe it.

The expensive parts of a build still exist, in different places. Deciding precisely what to build is still hard, still slow, and still where most failures start. Proving the result works is now a larger share of the work than writing it. Integrations with systems you do not control take exactly as long as they always did, because the constraint is someone else's API and someone else's calendar. And the software has to be run after it launches, which is a cost that never appears in the quote and always appears in the yearly budget.

We described that change in detail in what custom software actually costs when the code is nearly free. The short version: the price stopped following volume and started following clarity and verification. If you want the full breakdown of what moves a number up or down, the software development cost guide is the reference version, and the pricing and engagement models page covers how to structure the contract itself.

Five questions for your next quote

Ask these in the same call and listen for how quickly the answers come.

What is the total for this scope, and what changes it? A supplier who can only give you a rate is telling you they have not thought about your project, or that they would rather not commit.

Who is actually on the team, and what do they each do all week? This is where the headcount you are funding becomes visible. If half the names are coordination roles, you are paying for the cost of the team being large.

What has to pass before code is merged? The answer decides whether their speed is safe, and it is the subject of its own argument in AI is an amplifier, not a fix.

How do you add capacity if we fall behind? If the answer is more people, nothing has changed. Adding engineers to a late project is the oldest failure mode in this industry and it is still true after the arrival of AI, as we argued in why a small senior team now outbuilds a big one.

How did your pricing change when you adopted AI? This one tells you the most. There is a good answer, there is an honest answer, and there is a long pause. A supplier whose price did not change at all kept the entire benefit, and you are funding a margin improvement you were never told about.

None of this requires you to become an expert in someone else's cost structure. It requires you to notice that you are being quoted for an input, and to ask what share of that input still exists.

You should pay for the software itself, whatever the size of the team that built it.

Sources

Software Development Company Pricing Guide, Clutch, updated August 2026. Reported hourly ranges, regional bands, average project cost and duration.
Announcing the 2025 DORA Report, Google Cloud. AI adoption at 90% of nearly 5,000 surveyed technology professionals.

Stop paying for headcount you no longer need