Why We Stopped Billing by the Hour for Software Development

Quick Answer

• Generation got cheap. Ownership did not.
• Hourly billing now prices the fastest part of the job.
• The cost sits in review, testing, and the years afterward.
• An unfunded promise of support is not a promise.
• We now price the responsibility, not the clock.

On 3 September, OpenAI released the GPT-6 Astra. The rollout is still staged as I write this, so most people have not used it yet. That is roughly the rhythm now. Every few months the ceiling moves, and the thing that was hard in March is ordinary by September.

I have stopped finding this surprising. What I have not stopped thinking about is a smaller question that got harder every time the ceiling moved.

If the machine can do more of the building, what exactly am I charging for?

Why did an hour stop measuring anything?

Some months ago I sat with a task that took about an hour to build, working out what to put on the invoice.

An hour was accurate. It was also close to meaningless. That hour covered the fastest, cheapest, least risky part of what we had agreed to do. Everything that mattered sat on the other side of it: reading the output properly, testing the paths nobody prompted for, deploying it safely, and being reachable for the next three years when something in it moved.

Charging for the hour meant charging most for the part that had become nearly free, and least for the part that carried all the risk. It also meant we were rewarded for being slow. I could not defend that to a client, and I could not defend it to myself.

Why is accountability the thing being priced?

We have already written at length about what happens after a vibe-coded application reaches real users, including documented incidents where the missing piece was not the tool but the person answerable for what shipped. I will not repeat that argument here.

What that piece did not answer is the commercial question sitting underneath it. If accountability is the scarce thing, it has to appear somewhere on an invoice. Otherwise it is a promise nobody funded, and promises nobody funded tend to weaken quietly at exactly the moment they are needed.

An hourly rate cannot carry that promise. It records how long somebody sat with a problem, which in 2026 says very little about how much risk they absorbed on your behalf.

What are clients actually buying now?

Capability got distributed. Every firm in Bangalore, Calicut and Chicago now reaches for roughly the same tools. Nobody wins a pitch in 2026 by claiming to be a faster engineer.

What did not get distributed is the promise. Someone has to say: this is ours, we will keep it running, and here is who picks up. That is not a technical claim. It is a commitment, and commitments cost money in a way that keystrokes no longer do.

I notice the split in conversations too. Some people I talk to are delighted by how much faster everything has become. Others, usually the ones who have run software for a few years, ask quieter questions. Who reviewed this? What happens when it breaks? Who is left when the person who prompted it moves on.

Both reactions are reasonable. They are just about different time horizons.

What did we actually change?

We moved from billing hours to pricing the task and the responsibility attached to it.

That change was not comfortable. Explaining that a one-hour task carries a price unrelated to the hour takes a longer conversation than sending an invoice. Some of those conversations went badly before they went well. A few clients wanted the old model and I understood why.

What made it defensible was being specific about what the price covers. Not effort. Coverage. Who reviews the code before it merges, who is named on the project, what happens on a Saturday night, how long we stay responsible after delivery.

Not sure what your software costs after year one?

Send me the repository and the date it went live. I will tell you what I think it needs, and whether we are the right people to do it. If we are not, I will say so.

How do you price something you cannot schedule?

This is the practical difficulty, and it is why hourly pricing fails on the support side too.

The work that keeps software alive does not arrive on a calendar. It arrives when a platform decides, when a regulator decides, or when somebody discovers a vulnerability in a library you adopted two years ago. You cannot estimate it in advance because none of it is yours to schedule.

A short list of things nobody plans for:

• Dependency and SDK drift, including deprecations nobody chose
• Platform requirement changes from Google Play Console and the App Store
• Regulatory movement, which in India means RBI tokenisation rules and the DPDP Act arriving with deadlines attached
• Security review of generated code specifically, since models optimise for working rather than for validating input
• Written reasoning, so the next engineer inherits context instead of archaeology
• A named person who picks up

You cannot quote hours against that list. What you can price is coverage: the commitment that when any of it lands, someone is already responsible and already paid to care.

Which pricing model actually fits now?

I get asked this by founders who are not trying to save money so much as trying to understand what they are buying. It deserves a straight answer, including where our own model is a poor fit.

Model	Where it still works	Where it breaks in 2026
Hourly	Discovery, advisory work, scope that is still unclear	Anything AI-assisted. Speed shrinks the invoice while the risk stays constant
Fixed price per project	Tight scope, one-off delivery, no change expected	Ownership ends at handover, so nobody has funded month fourteen
Task plus stated ownership period	Defined deliverables where someone stays responsible afterwards	Requires an honest scope conversation the client may not want on day one
Ongoing retainer	Live systems, regulated sectors, anything integrated with other software	Looks expensive until the week it does not

We use the third and fourth. Not because they are clever, but because they are the only two where our incentive and the client’s incentive point the same way. Under hourly, we earn more by being slower. Under fixed price, we earn more by disappearing at handover. Neither is a relationship I want to be in for three years.

The fixed-price trap deserves naming, because it is the one buyers walk into most often. A fixed quote feels safe. It caps the number on the page. What it usually does not say is what happens in month eight, which means the answer arrives later as a separate negotiation, at a moment when you have no leverage and a broken system.

What we got wrong in the first year

I would rather write this down than have someone discover it in a meeting.

The first version of our pricing was too vague. We priced the task and said support was included, without stating for how long or what “included” covered. That is not a model. It is a hope, and it fell apart the first time a client and I disagreed about whether something counted as a fix or a new feature. We were both right, because nothing had been written down.

The second mistake was explaining the change badly. I led with our reasoning rather than with what the client actually receives. Nobody buys your internal logic. They buy a defined response commitment, a named engineer and a clear boundary around what is covered.

The third was underestimating how uncomfortable the conversation would be. Some clients heard “we are charging more for less work,” which is a fair reading of a poorly explained invoice. That one was on me, not on them.

What fixed it was writing the boundary down. Which work is covered, which work is quoted separately, how long we stay responsible, and who to contact. Once that existed on paper, the objections mostly stopped, because the argument had never really been about price.

Why we stopped chasing app builds

This is where the thinking led, though it took me longer to get here than it takes to write.

If anyone can generate an application, then building applications is not a business worth defending. What is worth defending is software that a company actually runs on. Systems that connect to each other, carry data between departments, survive audits, and keep working through the years when nobody is looking at them.

That shifted how we think about our own work. Less about shipping another app, more about software as part of how a business operates: workflows, integrations, dashboards, the operational plumbing that is unglamorous and load-bearing.

We describe the direction internally as AI-powered operational software ecosystems for emerging markets. That phrase arrived after the decision, not before it. What came first was noticing that our most valuable work was never the code we wrote fastest.

What should you ask a development partner?

Whether or not you work with us, these questions are worth asking anyone this year.

1. How much of this will be AI-generated, and who reviews it before merge?
2. Can your team explain the result without the tool open?
3. Who is the named technical owner of my project?
4. Who responds when something breaks outside working hours, and how fast?
5. Where does the repository live if we stop working together?
6. How do you handle secrets, and who has access?
7. What is your patch cadence for dependencies?
8. Have you passed a client security review before?

A partner who answers all eight without discomfort is telling you something no proposal can.

Common mistakes buyers make in 2026

Five patterns, and what each one actually costs you.

The mistake	Why it costs you
Comparing hourly rates	The lowest rate now often signals the most generated and least reviewed code. You are optimising the wrong number.
Assuming generated means reviewed	Two different activities, performed by different people. Only one of them is fast.
Accepting a ticket queue as accountability	A queue distributes the absence of ownership rather than providing it.
Treating support as the phase after the real work	Support is where software either earns money or quietly stops.
Leaving handover to the end	Ask about repository ownership and credential transfer at signing, not at parting.

So what is the honest answer?

If the machine can build more, ownership matters more, not less. Capability without accountability is just a faster way to create something nobody can answer for.

I would rather be the firm someone calls at eleven at night than the firm with the most impressive toolchain. The tools are the same everywhere now. The person who picks up is not, and that is the part worth paying for.

FAQ

Who is legally responsible for a bug in AI-generated code?

Responsibility sits with whoever contracted to deliver and maintain the software, not with the tool that produced it. AI vendors commonly exclude generated output from indemnity. Check your development agreement for who carries defect liability and for how long after delivery.

Should software still be priced by the hour?

Hourly pricing made sense when time and output were closely linked. With AI assistance, generation is fast and review, testing and long-term support are not. Pricing by hour now charges most for the cheapest part of the work and least for the risk.

Is fixed-price development better than hourly?

Fixed price solves the wrong problem. It caps what you pay to reach delivery, then leaves ownership unfunded from day one afterwards. The useful question is not fixed against hourly, but whether the agreement states who is responsible after handover and for how long.

Does using AI make development cheaper for clients?

Sometimes, for the build. Rarely for total cost of ownership. The savings appear at generation and disappear during review, security work and maintenance. Ask a vendor what their pricing covers after delivery, not just what it covers before it.

How do I evaluate a development company that uses AI?

Ask how much of your codebase will be generated, who reviews it before merge, and whether their engineers can explain the result without the tool. Then ask who is named on your project and what the response commitment is when something breaks.

Why do apps break when nobody has changed the code?

The environment changes underneath them. Operating system releases, SDK deprecations, expired certificates, API pricing changes and payment gateway migrations all break working software. The code stayed still while everything around it moved.