Are agencies cooked?

I spent most of my career — heck, more than half of my life — in digital agencies. Starting out doing contract work with my study group, moving to other agencies later with some brief stints into product development and the IT department of a big NGO, I somehow always ended up in engineering leadership roles. Twenty-plus years of client pitches, discovery workshops, offer documents, and estimation sessions. About a year ago, I switched to a more product-focused role, but — even though I do not miss all of this — some part of me is a little jealous. Despite all the negativity, I believe that the age of agents and vibe coding holds a lot of opportunity for digital agencies. At least for the ones that are willing to adapt and finally shake off some bad habits.

End of last year I ran a workshop on agentic coding with an agency. There was a lot of genuine excitement about the possibilities. We were talking about automated ticket screening, pull requests prepared by agents, test harnesses and how all this would push efficiency of development and maintenance to a new level. But then someone asked the question that made the Zoom go quiet:

"How do we bill for this?"

And all I had to answer was: "I don't know? 🤷‍♂️"

I knew that billing was broken for a long time. But the more I think about it, the more I realize: the problem isn't AI. The problem is that agency billing has been broken for as long as I've been in this industry. AI is just making it impossible to ignore.

The original sin#

When you bill by the hour, your financial incentive is to take longer. Solve it in 12 hours? You get paid for 12 hours. Meander through it in 40? Jackpot. You want to milk that cow until the moment right before it kicks you and walks off to a different supplier.

Sure, most agencies don't unconsciously pad hours. That extra meeting to "align stakeholders"? "Save" on automated tests? We just charge for the bugfixing! Refactoring costs money and reduces the time spent on the next feature. Who wants that? All perfectly defensible. All quietly profitable.

The client's goal is to get maximum value for minimum spend. The agency's goal — under hourly billing — is the exact opposite. We've built our entire industry on a model where success for us and success for our clients are fundamentally misaligned.

But how did we get here?

Act I: The dark ages#

For the first years when I started out in this job, waterfall development was the standard. After two years of designs and specifications, we would receive a detailed requirements document. But here's the thing: there often were no estimations. At least not from engineering. Sales would haggle out a price with the client, shake hands, and then hand us a budget we had no part in creating. Our job was to stay within it.

The pressure was immense. Budgets were always too tight, timelines always too aggressive. And when things inevitably went sideways, it was the developers who caught the blame. "Why can't you just work faster?" Lots of frustration, lots of burnout, lots of people leaving the industry entirely. The first project manager I worked with is a primary school teacher now. Being a father of three tells me a lot about his stress level, given that he gladly traded the agency for 25 of those 😱

Act II: Agile to the "rescue"#

Then Agile came along. I very vividly remember my first discussion with coworkers around the topic: "They want to do 'Scrum'. That means you do whatever the client wants! It's a disaster!"

This illustrates both how bad our understanding of agile principles was, as well as how toxic the relationship to customers had become. And what we made of the agile ideas aligned strongly to that. Burned one too many times by exploding budgets that the client was not going to extend, for many agile became just a synonym for time and material.

"We can't control the scope, so they have to take all the risk."

I myself was a strong supporter of the idea, but boy have I been wrong. In reality this just made a bad situation worse. The relationship stayed toxic, but now the client was on the receiving end. We still had to do huge estimations of the full project, so they could compare us to three other, equally wrong suppliers. But instead of clear responsibilities, there was a tug of war for each single ticket that went over estimation.

Act III: The estimation trap#

Is it a trap if you set it for yourself? 🤔 Because thats what happened. Developers complained that they can't take responsibility for budgets and timelines they where not included in. So they was invited to a lot of meetings (bad) and had to estimate all work themselves (worse). "You were the one who told us it would take two weeks!" In hindsight, the outcome was obvious, but at the time, we didn't know enough about ourselves.

Daniel Kahneman and Amos Tversky called it the planning fallacy: our systematic tendency to underestimate the time, costs, and risks of future actions while simultaneously overestimating their benefits. In 2002, American kitchen remodeling projects were expected to cost $18,658 on average. The actual cost? $38,769. More than double. And that's just kitchens — made up of well-known parts like stoves, sinks, and countertops. Imagine what happens with software, where even the requirements are unclear.

Here's what Kahneman discovered through decades of research: even when people are explicitly told about past failures in similar projects, they still insist their current estimates are realistic[1]. Canadian taxpayers in one study consistently mailed their forms a week later than predicted, while maintaining zero misconceptions about their past record of being late. We somehow believe that this time will be different.

So what makes us think our sprint planning is any better?

If you haven't read Thinking, Fast and Slow, I strongly recommend it. The planning fallacy is just the tip of the iceberg. Kahneman's work on anchoring, loss aversion, and the distinction between experiencing and remembering selves explains so much about why client relationships go sideways — and why our intuitions about estimates are systematically wrong.

The attachment to estimations sometimes took almost comedic turns. I remember one proud project manager who told me that the team had almost no failure rate in estimating efforts. The Jira timelogs showed that the largest part of tickets were within a range of 10% of the estimation, which is really hard to believe. And — as expected — digging deeper revealed that the developers logged exceeded time on the global "Education" time logger, since they assumed they had to improve to meet the standards. In the worst cases, desperate individuals even resorted to unpaid work just to please the estimation gods.

We went from "sales makes up a number and blames developers" to "developers make up a number and blame themselves." Progress! 🎉

The better way (that nobody uses)#

You get my point. Estimations have always been wrong. There has to be a better way.

Value-based pricing isn't a new idea. It's been floating around management consulting and pricing literature for decades[2]. The concept is simple: price based on what something is worth to the client, not what it costs you to deliver.

A new checkout flow that increases conversions by 2% on a $10 million e-commerce site is worth $200,000 per year. Whether it takes 40 hours or 400 hours to build is almost irrelevant to that value equation.

But here's the problem: the market expects hourly rates. Procurement departments have checklists. RFPs demand rate cards. When I tried to introduce value-based conversations at agencies, I was met with polite nods followed by "but the client is asking for a day rate breakdown."

And honestly? I get it. Value-based pricing requires trust. The client needs to believe you're quoting fairly when they can't see inside the black box. Given how wrong our estimates typically are, and how adversarial the relationship has become over decades of misaligned incentives, that skepticism is warranted.

Some clients genuinely prefer hourly billing because it feels like control. "At least I know what I'm paying for!" But here's the thing: if the hours are made up — and we've established that they are — then it's false control. You're not controlling costs, you're controlling a fiction. The comfort of seeing itemized hours is an illusion built on estimates that were wrong before the project even started.

Waterfall processes, RFPs, procurement checklists — they're all risk mitigation strategies. Clients got burned, so they built walls. We got burned, so we built walls. And now we're all standing behind our respective fortifications, lobbing estimates at each other like medieval siege warfare.

Then came the machines#

Now we have agentic AI that can write code, review pull requests, generate tests, and scaffold entire applications. Gemini or ChatGPT and their successors aren't replacing developers, but they're undeniably making them faster.

How much faster depends on the task. Boilerplate code, standard CRUD operations, cookie-cutter components — these can be 4-5x faster with good agentic tooling. Complex architectural decisions, novel problem-solving, security-critical code — maybe 1.5x, if that. But agency work has a lot of the former. Setting up yet another WordPress site, building yet another checkout flow, implementing yet another contact form with validation. A senior developer with good tooling can now match the output of a small team on these tasks.

For agencies clinging to the hourly model, this is a problem. If you're billing $150/hour and a significant chunk of your work just got 3-4x faster, you have two obvious options:

1. Bill fewer hours and watch revenue crater
2. Somehow stretch work to fill the hours (hello, perverse incentives)

Neither is sustainable. The hourly model was always held together with wishful thinking and optimistic estimates. AI is just making the cracks impossible to ignore.

But here's the thing: AI doesn't just break the old model. It makes the better model finally possible.

The trust problem, solved#

Remember the core barrier to value-based pricing? Trust and risk. The entire RFP and procurement apparatus exists because of trust deficit and the risk of betting on the wrong supplier.

But what if you would just... show them?

With agentic development, the cost of a first iteration has dropped dramatically, and therefore the risk. What used to take weeks now takes days. What used to require a team now requires one senior developer with good tooling.

So here's my radical suggestion: stop doing estimations. Build the first version instead.

Think about how much time goes into a typical RFP response. Reading the requirements. Clarification meetings. Internal estimation sessions. Spreadsheets with hourly breakdowns. Reviews. Revisions. More meetings. I've seen teams spend two to three weeks on a single proposal — and that's before you factor in the proposals you don't win.

What if you spent that time building instead?

Take the time and money you'd lose in pointless Excel sheets and estimation sessions and spend it on building a working prototype. Version zero. It's on the house. Yes, the CFO just fainted, but hear me out — you were already spending this time on RFP theater. At least now you have something to show for it.

"Here's a working version of what you described. It's rough, but it works. Now let's talk about what it's worth to you to make it production-ready."

Now you're not arguing about hours or day rates or whether your senior developers should cost more than juniors. You're having a conversation about outcomes. About value. About partnership.

The client can see what they're getting. They can click around, find the gaps, understand the scope in a way no requirements document could ever convey. And you can have an honest conversation about what the next iteration is worth.

Some clients will take the prototype and run. But honestly? Those clients were never going to be good partners anyway. The ones who stay are the ones who understand that the value isn't in the prototype — it's in the expertise to make it real.

The new market#

Vibe coding is generating an endless stream of little solutions. Non-technical founders are shipping MVPs. Marketing teams are building internal tools. Everyone with an idea and some patience can now produce something that kind of works.

And a certain percentage of those projects will become valuable enough to invest in properly. Valuable enough to spend money on the last 20% that famously costs 80% of the effort. The part where you need actual engineering expertise, proper architecture, security reviews, scalability planning.

That's the market agencies need to focus on.

Not competing on who can estimate less hours for a greenfield project. Not racing to the bottom on day rates. But being the experts who take something rough and make it real. Who look at a vibe-coded prototype and say: "Here's what it would take to make this production-ready, and here's what that's worth based on the value it'll generate."

Are agencies cooked?#

I don't think agencies are cooked. I think the hourly billing model is cooked, and it should have been cooked decades ago.

The planning fallacy isn't going anywhere. We'll always be terrible at predicting how long things take. But maybe that's okay. Maybe instead of fighting our cognitive limitations, we should build business models that don't depend on them.

The agencies that thrive in the AI era will be the ones that finally break free from the estimation trap. The ones that stop selling time and start selling outcomes. The ones that use AI's speed not to bill fewer hours, but to bypass the trust problem entirely by showing instead of telling.

Twenty-five years of watching this industry tie itself in knots over estimates and hours and rates. And now, finally, we have the tools to do something different.

The question isn't whether agencies are cooked. The question is whether they're brave enough to change the recipe.