How to Price Projects When AI Wrote Half the Code

A developer on your team spends three hours building a feature that would have taken eight hours a year ago. The client gets the same outcome. Do you charge for three hours or eight?

Most agencies are quietly answering this question right now without having answered it out loud. The choices being made by default will define margins, client relationships, and competitive positioning for the next few years.

There’s no universally correct answer. But there are wrong ways to handle it, and some approaches hold up much better under pressure than others.

The Problem With Time-Based Billing in an AI World

Time and materials pricing made sense when developer time was the primary input into software. You hired skilled people, they worked hours, and the client paid for those hours. The relationship between time spent and value delivered was close enough that billing for time as a proxy for value was defensible.

AI tools have broken that proxy. A developer with strong AI tool skills might deliver work in two hours that another developer (or the same developer a year ago) would have needed twelve. The output is similar. The input is not.

If you’re billing hourly, you’re now in a position where:

• Being good at AI tools lowers your revenue
• Being slow (or avoiding AI) pays better per project
• Clients with any insight will notice the pattern

That’s a bad dynamic. The business model punishes competence.

Fixed-price projects have the opposite problem. If you quoted based on eight-hour assumptions and now complete the work in three, you pocketed the difference, which is the normal business logic of fixed-price work. Except clients are becoming aware that AI changes completion times significantly, and some are starting to ask about it in proposal conversations.

What Clients Are Actually Asking

Client awareness varies widely, but a consistent pattern is emerging: sophisticated buyers ask directly, while smaller clients often don’t think to ask until after they’ve had a few projects.

Questions that have started appearing in RFPs and proposal conversations:

• “What percentage of your development work uses AI assistance?”
• “How does AI change your pricing vs a year ago?”
• “If AI writes the code, what are we paying you for?”

That last question isn’t hostile. It’s fair. And it has a good answer that most agencies haven’t yet learned to articulate.

What clients are paying for isn’t keystrokes. It’s:

• Judgment: which of the three AI-generated approaches is actually right for their system
• Architecture: decisions that don’t show up in any single file but shape everything downstream
• Review: catching what AI got wrong before it ships
• Context: knowing the client’s constraints, team, and technical history
• Accountability: being the party responsible when things go wrong

AI handles the mechanical parts of software production. The parts that require experience, client knowledge, and professional judgment remain human work. That’s worth paying for, and pricing should reflect it.

Three Models That Work

1. Value-Based Pricing

Price based on the outcome, not the inputs. What is this feature worth to the client’s business? A checkout flow that converts 2% better for a $5M annual revenue business is worth real money regardless of how long it took to build.

Value-based pricing requires you to understand the client’s business well enough to quantify the outcome, and to have the confidence to charge accordingly. Most agencies are uncomfortable with this model because it requires negotiating on business value rather than scope, and it means some projects will generate excellent margins while others are thin.

Where it works: clients with measurable revenue outcomes (e-commerce, SaaS, lead generation sites) where you can connect your work to business results. It’s harder to apply to internal tools or branding projects where ROI is diffuse.

2. Output-Based Pricing

Charge per feature, per component, or per deliverable. Scope the project in terms of what will be built, not how long it takes.

“$4,000 for the user authentication system (registration, login, password reset, email verification, social OAuth).”

This is easier to defend than hourly billing because you’re quoting on what the client gets, not how long you take. If AI lets you build the auth system in two days instead of five, that’s your efficiency to keep.

The catch: scope definition is harder than it sounds. “User authentication system” means different things to different clients. Good output-based pricing requires detailed specifications, which you should be writing anyway.

Where it works: established agencies with good discovery processes who can define scope accurately. It fails for projects where requirements are fuzzy or change frequently.

3. Retainer with Defined Capacity

Monthly fee for a defined amount of capacity: a set number of developer-days or story points per month. The client uses that capacity on whatever matters most, and unused capacity doesn’t roll over.

AI efficiency doesn’t directly affect this model because you’re selling access to skilled judgment over time, not a fixed block of time itself. You scope what can realistically be done in a month with AI-assisted development, price the month accordingly, and deliver against that scope.

This model works well for ongoing product development relationships where requirements evolve and the value of predictability (for both parties) is high.

Where it works: long-term relationships with sophisticated clients who want a development partner rather than a project vendor.

The Transparency Question

Some agencies are preemptively addressing AI efficiency in their proposals. Something like:

“We use AI coding tools on all projects, which lets us move faster and catch more edge cases. Our pricing reflects what the work is worth and what it takes from us in skill and judgment, not raw hours.”

This is honest and positions the agency well. It turns AI from something to hide into something to be proud of.

A small number of clients will push back and ask for hourly billing specifically. This is a compatibility signal. Clients who only want to pay for hours are betting against your efficiency. That’s a relationship that will struggle as AI tools improve.

Clients who understand they’re paying for outcomes and judgment tend to be better partners. Proactively framing your pricing this way acts as a filter.

What to Do With the Efficiency Dividend

The honest answer: keep most of it, pass some of it on.

Trying to maintain exactly the same billing on projects that now take half the time is a path to client resentment. If a client knows a project type well and sees your quote go up year-over-year while the timeline goes down, the math is visible.

A reasonable approach: price AI-assisted projects somewhere between what you’d have charged in 2024 and what pure hourly billing would give you now. You’re faster and more capable than you were. Charge accordingly, modestly less than the pre-AI equivalent, not dramatically less.

More importantly, reinvest efficiency gains into quality: more thorough review, better testing, more careful architecture conversations. Clients don’t need to know this is happening. They’ll feel it in fewer bugs and better delivered work.

Proposals That Hold Up Under Scrutiny

If your pricing model changes, your proposal documents need to support it.

A proposal that used to say “200 hours at $150/hour = $30,000” needs to become something different. Options:

Scope-based: “User authentication system, product catalog with search, checkout with Stripe, order management dashboard: $28,000.”

Phase-based: “Phase 1: Discovery and architecture ($4,000). Phase 2: Core feature development ($18,000). Phase 3: QA, performance optimization, and launch ($6,000).”

Outcome-based: “A fully functional e-commerce platform capable of handling your projected 500 orders/day at launch, with a two-week onboarding period and 30 days of post-launch support — $30,000.”

All three are harder to argue with on a per-hour basis, because they’re not quoting per hour.

One Concrete Change to Make Now

If you’re still billing hourly and this post is resonating, the single highest-leverage change is: stop quoting projects as time estimates.

Instead, quote total project fees based on scope. When clients ask how many hours it will take, answer: “Our projects are priced based on what we’ll deliver, not how long we take. We commit to the outcome at the price we’ve quoted.”

Some clients will push back. The right clients won’t.

The underlying point is this: AI has changed what goes into building software, not what software is worth. Pricing should reflect the value to the client and the skill it takes to deliver, not the computational work of generating code. Agencies that make this shift explicitly will have cleaner relationships and better margins than those still waiting for the right moment to have the conversation.