I've wrestled with the pricing side of AI quite a bit.
My efficiency at House of Giants has gone up enormously. I can move through difficult feature work much faster than I could before. I'm not going to put a neat multiplier on it because every project and task is different, but the efficiency is real.
That efficiency creates a pricing question I haven't found easy to answer.
If AI helps us finish work in a fraction of the time and we still charge the client for the amount of time it should have taken, that feels gross to me. The client should benefit when the way we work improves.
AI made it cheaper to generate lines of code. A software engagement includes a lot more than line generation. The agency model needs to adapt, and clients deserve a better explanation of what they're actually paying for.
The timesheet stopped describing the work
Hourly billing already had problems before coding agents showed up. I wrote about why we stopped billing by the hour because the incentive never sat right with me. If a senior engineer solves a problem in two hours instead of ten, hourly billing punishes the engineer for being good at the job.
AI made the accounting even stranger.
I might have one agent implementing a feature while another runs a review. A third could be working through documentation on a different project. I'm moving between them, giving context, checking decisions, reading code, correcting the approach, and deciding what is trustworthy enough to keep.
How would I put that on a timesheet?
Is the client paying while an agent runs? Does prompting count? How do I divide fifteen minutes when I'm reviewing one project, waiting on another, and answering a question from a third agent?
I can still tell a client how long I think a piece of work should take. Time matters for planning, staffing, reviews, and business commitments. It's become a bad unit for describing software production.
Any agency with no answer for how it uses AI, or why it doesn't on a given project, would be a red flag for me at this point. What matters now is how the agency uses the tools and how that efficiency shows up for the client.
Code generation got cheaper
Maybe cheaper isn't the right word.
It takes less effort to generate code now. Work that once required a developer to type through every implementation detail can happen much faster with a capable agent and the right context.
That doesn't make every part of software development cheaper in the same way.
Before an agent starts working, somebody still has to understand the client, the product, the users, and the reason the feature exists. Somebody has to decide how it should behave, which edge cases matter, how it fits into the rest of the application, and what should be left out.
After the agent produces something, somebody has to review it. The code needs to be tested, adjusted, and checked against the product definition. A convincing first pass doesn't supply the UX, accessibility, architecture, or development standards.
We talked about this in You Can Build the Wrong Thing Faster Than Ever. If you give an agent a five-minute explanation and ask it to build the product, you're going to get decisions shaped by whatever context the agent has. The code may work. That doesn't mean the decisions are good.
You're paying for the assurance that the work we produce with AI gets held to the quality bar I expect from my own code. That covers the strategy, the decision-making, the expertise, the client context, and the work of reviewing, tweaking, and adjusting the agent's output.
Working with agents forces us to write more things down. Client conversations become feature definitions, and product decisions get written into a decision log. Engineering standards become instructions that the team and the agents can follow. The project gets a more repeatable development process and a better record of why the software works the way it does.
AI also produces an unbelievable amount of explanation. Some of it is useful. Some of it is defensive word blowout that nobody needs. A senior person still has to decide what belongs in the project's actual knowledge. That filtering is part of the job now.
Milestones don't remove the fixed-bid problem
Milestone pricing initially sounded like the obvious replacement to me. Define a feature, agree on a price, build it, review it, and invoice when the client accepts it.
The problem is that this still behaves like a fixed bid. We've attached a fixed price to a fixed feature and asked both sides to pretend the original definition will remain correct while the software is being built.
Software development is messy. You learn as you build, and what you learn may change the shape of the product.
An integration can behave differently than the documentation promised. The client can see the working feature and realize the original workflow missed the point. Sometimes the team finds a simpler version that solves the problem without half the proposed interface.
Under a traditional fixed bid, those discoveries turn into change orders or margin fights. The client wants the new understanding reflected in the product. The agency wants to protect the price it set using the old understanding. Quality becomes the easiest place to quietly absorb the difference.
Pure outcome pricing has its own problem. A completed feature is an output. An outcome is a measurable change in the business, such as fewer failed transactions or lower support cost. We don't control the client's traffic, adoption, operations, or internal decision-making.
There isn't a perfect blueprint yet. Hourly stopped making sense before anything showed up to replace it.
Monthly delivery
At House of Giants, complete builds run through monthly delivery. Each delivery month has one fixed fee.
This is still a fixed bid. The one-month boundary keeps the commitment smaller and gives both sides a scheduled point to reshape what comes next.
When the product is still unclear, we start with Product Inception. When the destination and constraints are already clear enough, we can scope monthly delivery directly. Either way, the first delivery brief documents the objective, important decisions, constraints, quality expectations, and the plan for the first delivery month.
One current application engagement started with a paid Phase 0 for documentation and product definition. That gave the client something concrete to accept before the larger delivery began. We then billed against approved milestones. I'm not saying that structure is the right one, but it exposed a practical problem. I don't want to send thirty invoices during a six-month project because thirty individual tasks crossed a line in the tracker.
That's why one invoice per delivery month makes more sense. Each month can contain several feature targets and review points. The agreement fixes the fee, the date of the monthly review, the minimum result the client is buying, and the quality bar.
A delivery month is not a bank of hours. We still estimate the attention, review, and supporting capacity the work requires because that is how we know whether we can make the promise. But the fee buys the agreed result and our accountability for it, not the estimate behind it.
The plan can change as the work teaches us more. That doesn't give the agency permission to cut whatever it wants and declare victory. Each month begins with that minimum result and a prioritized set of targets. If something real changes, the client and agency record the decision together. The record names both what enters and what leaves.
Quality is not the flexible variable. If the implementation misses the behavior or standard we agreed on, the agency still owes that work. If the client learns something and wants the product to behave differently, that becomes a candidate for the following delivery month.
The line won't always be clean. It works when both sides can point at the same document and say what changed. The point is to make the trade visible while there's still time to discuss it.
Three records keep the work honest
Three working records are enough to run this model without turning it into a giant requirements package.
The delivery brief defines the objective, the minimum result, the starting targets, the fixed constraints, client dependencies, and the evidence both sides expect to review.
The decision log records what changed, why it changed, what entered or left the month's plan, and who agreed.
The review record shows what was demonstrated, what the client accepted, what the agency still owes, what belongs in future work, and whether both sides want to continue, reshape, pause, or stop.
The issue tracker is still the work queue. The repository is still the engineering record. These documents are the shared product and commercial record. They should be short enough that a client can read them without needing another meeting to explain the paperwork.
Each delivery month's fee is invoiced when it starts, unless the client's procurement rules require another schedule. If we materially miss the agreed result, the next delivery month doesn't begin. We finish what we owe under the fee the client already paid. When the client accepts the work and both sides agree to continue, the next month starts. A changed request or a client-caused delay isn't our miss, and the contract handles those cases separately.
AI transparency belongs in that relationship too. A client should know our confidentiality commitments, how their data is handled, who reviews the output, and who is accountable for the result. They shouldn't need control over our internal process, which model we use, how we prompt it, or how we organize agents, unless a legal, security, or data requirement makes that choice material.
The model we use now
This model won't fit every studio or every project. A small marketing site, a long-term embedded partnership, and a complex product build don't need the same commercial structure.
The software timesheet is getting harder to defend. We have to define product work clearly enough for an agent to participate, which puts the work around the code out in the open.
For House of Giants, one invoice per delivery month feels closer to the way we already wanted pricing to work. The client gets a predictable cost and a clear review point. We get room to respond when building the software changes our understanding of the product. AI efficiency can produce more useful progress inside the month without lowering the standard or hiding where the time went.
We may refine the model again as the tools and client expectations change. Right now, it's a more honest description of the work than a spreadsheet full of reconstructed hours. The pricing page stays the canonical source for the live numbers.