If AI Makes the Work Faster, What Should Clients Pay For?

AI is making me reconsider the relationship between time and price in client services. If a tool helps produce a first draft or page layout much faster, what should a client pay for: the minutes, the finished work, the judgment behind it, or some combination? I do not think “hourly is dead” is a useful answer. I do think the question deserves a more honest conversation.

This is a reflection on how I am thinking about the work, not an announcement of a new Double Atari rate card. I want clients to benefit from better tools. I also want proposals to explain the work that remains after the impressive part of a demonstration ends.

What happens when the fast part of the job gets much faster?

One of my favorite experiments was recreating aspects of TypeStyler, software I used for DIY band posters in the late 1990s. My friend Phil had been sharing old posters, which sent me down a rabbit hole of manuals, examples, and interface memories. The prototype took under an hour, as I described in the TypeStyler experiment.

That is exciting. It is also a bad basis for quoting an unrelated production website. A tribute prototype is not a tested client implementation with content requirements, accessibility checks, integrations, approvals, launch risk, and ongoing ownership.

The same distinction shows up in my WPVibe.ai workflow. Watching an assistant help change a WordPress page can feel like the work has collapsed into a prompt. But someone still has to decide what should change, supply the right context, inspect the result, and take responsibility for what ships.

My concern is not that speed makes expertise worthless. It is that both buyer and provider can start pricing an entire project by the most dramatic five minutes of it.

What is the difference between hourly, fixed-fee, and value-based pricing?

In this discussion, hourly pricing means paying for actual time under an agreed rate and billing policy. Fixed-fee pricing means agreeing on a price for defined work. Value-based pricing starts with the importance of the problem and the value of resolving it, then negotiates a price in that context. Those are different agreements, not different labels for the same invoice.

A retainer is a recurring arrangement; it can still be based on capacity or a defined scope. It should not become shorthand for unlimited access, unlimited production, or a vague promise that SEO will eventually improve.

Is hourly pricing suddenly unfair if you use AI?

No. I can imagine plenty of situations where time is the clearest unit available. If nobody knows why an integration is failing, a bounded investigation with a budget cap may be more honest than pretending the outcome is fully specifiable in advance.

But the billing needs to match the agreement. If a task takes less billable time because a tool helps, I would not bill fictional hours representing how long it used to take. Review, testing, and client communication can be real work. Imagined manual production time is not.

There are also details worth discussing before work begins: whether unattended processing is billable, how tool costs are handled, and what happens when multiple tasks run concurrently. I would rather explain those boundaries in a proposal than debate them after an invoice arrives.

The client should not have to guess whether “AI-assisted” means less time, more output, or simply a different method. Those can all be valid arrangements, but they are not interchangeable.

When does a fixed fee make the conversation easier?

Consider a hypothetical content project: revise six service pages, map the internal links, update relevant structured data, and complete one review round. The agreed result can be inspected. That makes a defined project fee easier to discuss than a prediction about typing time.

If AI helps organize the first draft, that does not automatically change the agreed fee for a fixed scope. Equally, it does not give the provider permission to deliver unreviewed output. The client is buying the agreed work at the agreed standard, not a particular number of keystrokes.

In that example, I would specify what is included: discovery inputs, six identified pages, factual review responsibilities, one consolidated revision round, implementation, and a verification checklist. I would also identify what is excluded, such as a new brand strategy or an unplanned CMS migration.

That clarity matters more than choosing a fashionable pricing label. For a focused website audit, the useful question is what decisions and deliverables the client receives, not how many automated warnings a crawler can produce.

How do you discuss value without inventing a return on investment?

Start with the problem, not a multiplier. What decision is blocked? What does uncertainty cost? What operational risk is the business trying to reduce? What would improve if the work succeeds, and which parts can the consultant reasonably influence?

A migration plan, for example, may be valuable because the business needs to preserve access to important content and reduce launch uncertainty. That does not justify inventing a guaranteed revenue figure. Search demand, competition, sales follow-up, product fit, and implementation choices remain outside one consultant's complete control.

I also would not confuse value-based pricing with performance-based payment. A fee negotiated around the significance of a problem is different from compensation triggered by an agreed result. The latter raises additional questions about attribution, measurement quality, timing, and shared responsibility.

Before attaching money to an outcome, I want the measurement to work. A tracking audit may reveal that the supposed “lead” is only a button click. That is a poor foundation for either a performance promise or a performance-based invoice.

Does AI always reduce the total effort?

I would not build a pricing policy around that assumption. Faster generation is only one part of a workflow. Reviewing a plausible but incorrect answer, undoing an unwanted change, or supplying missing context can consume the time that the first draft appeared to save.

Even measuring the change is difficult. In its February 2026 update on experienced open-source developers, METR described selection effects and time-measurement problems that made its newer productivity estimates unreliable as a simple measure of current AI impact (METR's developer-productivity study update). That study is not a pricing survey of consultants, but it is a useful warning against applying one productivity percentage to every kind of work.

For my own experiments, I want to distinguish time to first output from time to acceptable delivery. I also want to count revisions and defects. A page that appears in ten minutes but takes two hours to untangle is not the same result as a page that is ready for a careful final review.

What should clients get from the efficiency?

They should get a better deal in a way they can understand. Depending on the engagement, that might mean a lower price, a shorter turnaround, more useful exploration, or additional verification within the same budget. It should not just mean the same unclear deliverable arrived sooner.

I would discuss that choice explicitly. If a client values speed above extra variations, do not turn every saved hour into more options to review. If the project is high risk, using some of the efficiency for testing may be more valuable than delivering a day earlier.

There is a provider-side reality too: tools, judgment, reusable systems, and accountability have value. A fair arrangement can reward efficient delivery while making the client benefit visible. Neither side needs the other to work slowly for the agreement to make sense.

What would I change in a proposal before changing the pricing model?

I would make the work easier to understand first. My preferred proposal would identify the problem, the deliverables, what counts as acceptance, the client's responsibilities, and how a change in scope gets approved. It would describe where AI assistance is appropriate and what still requires human review.

I would also address sensitive information. A tool being convenient does not mean every client file belongs in it. Permission, access boundaries, and the client's requirements should shape the workflow before anyone starts experimenting.

For ongoing work, I like the idea of a bounded monthly cycle: choose priorities, implement agreed changes, verify them, and review what happened. That connects a recurring engagement to decisions and delivery rather than an indefinite list of “optimizations.” It is a model worth evaluating, not a promise of unlimited service.

What am I going to measure as this evolves?

I want to test the economics with the same skepticism I bring to website reporting. These are the questions I would document as the approach develops, rather than presenting a conclusion I have not earned.

• Time to accepted work: distinguish drafting, review, implementation, and verification instead of measuring only generation speed.
• Rework and defects: record what needed correction and whether the error reached the client or live website.
• Scope predictability: compare the agreed deliverables with the work actually required, including unclear inputs and approval delays.
• Client benefit: identify whether the efficiency improved cost, speed, confidence, or usefulness from the client's perspective.
• Business sustainability: check whether the engagement leaves room for careful work, tool costs, and ongoing responsibility.

I do not want to defend hourly billing just because it is familiar, or declare value-based pricing the winner because it sounds progressive. I want a model that accurately describes what is being bought and rewards doing it well.

That is part of the broader Double Atari Search Lab experiment: using AI to change how the work gets done, then examining what actually improved. If you buy or deliver client services, I would genuinely like to hear where this conversation is landing for you. Let's compare notes.

Frequently asked questions

Is AI making hourly billing obsolete?

I do not think every engagement should abandon hourly billing. It can still be a clear arrangement for uncertain or exploratory work when actual time, budget limits, and approval rules are explicit. AI does make it worth discussing whether the client would benefit more from a defined deliverable, a fixed fee, or another model.

What is the difference between fixed-fee and value-based pricing?

A fixed fee sets a price for defined work. Value-based pricing starts with the importance and potential value of resolving a business problem, then negotiates the price in that context. A project can have a fixed price informed by value, but a fixed fee alone does not establish a value-based approach.

Should clients pay less when AI reduces the work time?

The answer depends on the agreement. Under hourly billing, the invoice should reflect actual billable time rather than imagined manual hours. Under a fixed scope and fee, discuss whether efficiency is reflected in price, speed, exploration, or additional verification. The client benefit should be understandable, not left as an assumption.

Does value-based pricing mean guaranteed results?

No. I would distinguish a price informed by business value from a fee contingent on a measured outcome. Either discussion needs clarity about responsibilities, uncertainty, and attribution. Search visibility, lead quality, and revenue depend on factors beyond one consultant's control, so they should not become invented guarantees.

Is Double Atari announcing a new pricing model?

No. This article is a reflection on options and the questions I want to evaluate as AI changes the work. It is not a new rate card, a change to existing agreements, or a commitment to a particular billing model. Scope, price, responsibilities, and approval terms should be agreed for each engagement.