selling-the-dream.md

2026-11-12 | 8 min read

Selling the Dream (and Invoicing the Cleanup)

ConsultingSoftware DeliveryCloudAI

A smiling office cleaner in yellow rubber gloves tips a full bin onto the carpet of an open-plan office at dawn, a clipboard reading CLEANUP x 2 under her arm, while two colleagues with coffees and briefcases walk past yesterday's papers on the floor — Same mess as yesterday. Invoice attached.

A good share of my work starts the same way. A company calls, and the first sentence is some version of “we were told this would be simple.” By the time my team and I arrive, the promised savings are gone, the scope has grown a second head, and people in meetings have started asking the question I’ve learned to recognise as the real start of the project: “wait, what is $ADD_YOUR_TECHSTACK_COMPONENT, and why are we paying for it?”

Selling things that won’t happen has quietly become normal in IT. Not as an accident, and not as the occasional bad apple, but as a sales technique. You promise something attractive, you win the deal, and then you let the chaos you created push the client into spending more, because by then walking away costs more than staying.

I want to be careful here. I don’t have data showing this is getting worse. What I have is an observation from years of being the cleanup crew: it has been in the industry forever, and it is getting annoyingly worse. Take that as my opinion, not as a statistic.

The pitch has a shape

Once you’ve seen a few of these, you notice the same moves every time.

Fail #1: “You’ll save this much”

There is a number. There is never math behind the number. No baseline, no assumptions, nothing you could hand to your finance team and say “check this”. Six months later somebody finally does the math, and it runs the other way.

Fail #2: “It will be just this and nothing more”

A clean, small scope. One service, one migration, one platform, done. Except that the one service depends on four other things nobody put on the slide, and those things have licences, operators and their own upgrade cycles.

Fail #3: “We accidentally forgot to put this in the calculation”

My favourite. Mid-project, the scope is rewritten because something essential was “accidentally” left out. Monitoring. Backups. Identity. Security reviews. The client didn’t catch it in the offer, because the client isn’t an expert — which is exactly why they hired someone who claimed to be one.

Put the three together and you get a cleaning lady who makes a fresh mess every morning, so everybody has to live in it, and then charges double to clean it up. Nice business model. Recurring revenue, even.

Sounds familiar? I think it does.

This is not new. It even has a name.

Don’t take my word for any of this. The research has been pointing at the same thing for over a decade.

McKinsey and the University of Oxford looked at more than 5,400 IT projects back in 2012. Large projects, the ones with budgets above $15M, on average ran 45% over budget and 7% over time, and delivered 56% less value than predicted. Read that last number carefully: it’s an average shortfall in value, not the share of projects that failed. They also found that 17% of projects go so badly they can threaten the existence of the company, and that every additional year a project runs adds 15% to the overrun.

Bent Flyvbjerg and Alexander Budzier looked at 1,471 IT projects for Harvard Business Review in 2011. The average cost overrun was 27%, which sounds survivable. But one in six projects was a “black swan”, with an average cost overrun of 200% and a schedule overrun of almost 70%. And a 2022 study of 5,392 IT projects found that overruns follow a power law with a fat tail. In plain words: the average lies to you, because the disasters are not rare enough to ignore.

The quote is the shortest bar on the chart. It is also the only one anybody signed.

The part that matters most is the name Flyvbjerg gave to one of the causes: strategic misrepresentation. Estimates that are deliberately optimistic so that the project gets approved. The system rewards the attractive business case over the accurate one, so attractive business cases are what you get.

So no, it isn’t only incompetence. Sometimes it is a strategy.

The savings nobody calculated

Cloud is where I see Fail #1 most often, so let me stay there for a moment.

In the Flexera State of the Cloud 2025 report, respondents estimate that 27% of their cloud spend is wasted. It’s a self-reported estimate, so treat it as one, but it has been the same number since 2023. And 84% of organisations say they struggle to manage cloud spend at all. Those are the same organisations that were, at some point, promised savings.

On the other side, a16z argued in 2021 that at scale, repatriating workloads can run at one third to one half of the equivalent cloud cost. That claim is contested, and the rebuttal is worth reading just as carefully as the original.

Then there’s 37signals, who reported moving from roughly $3.2M a year in cloud spend to roughly $1.3M, and projected more than $10M saved over five years. That’s their projection, not an audit.

Don’t get me wrong, I’m not telling you on-prem wins. I spend my days building cloud infrastructure. The point is simpler: for them, the savings promise ran the other way, and they only knew because they did the math. Whoever sells you a migration in either direction should be able to show you that math. If they can’t, the number on the slide is a decoration.

Everyone sells the dream now

Here is the part that annoys me most. Everybody sells vision. Very few people selling it have a track record to back it.

People sell a website for 5k. Fine. I can make you one for free too. And then what? Who runs it, who patches it, who notices when the form stops sending emails, who knows what the thing even depends on? The price of building something was never the interesting number.

People sell Mac Minis as small miracles, because that’s what the video the algorithm served them said last week. They aren’t wrong that it’s a good machine. They’re just repeating it. No inspiration, no message, no experience of their own behind it. The confidence is borrowed, and so is the opinion.

That’s the pattern across the board: a pitch built from somebody else’s highlight reel, delivered with the confidence of somebody who has done it a hundred times.

This is not anti-technology

Let me be very clear, because this is where people usually stop reading carefully. I’m not anti-AI. I’m not anti-cloud. I’m not anti-Mac. I use all of them every day.

I’m against people pretending to have competence they have never proven.

You can do a lot today, and you can do it properly. But there’s a difference between a silly illustration for a social post and business-grade software that has to run, be secured, be patched, be audited and still make sense in three years. If you don’t have the skills to control the full software development lifecycle, you’ll have a problem. That was hard before, and it will stay hard for some time.

That’s exactly why the SDLC had layers, and why those layers were represented by specialist roles. Architects, developers, testers, security, operations. Not because the industry loved headcount, but because each layer catches what the one before it can’t see. Remove the layers and pretend one confident person covers them all, and the defects don’t disappear. They just move downstream, to whoever gets called in later.

Go scan your own house

Before you nod along and think about that one vendor, look at your own stack. Nobody is clean, and I mean nobody.

The Black Duck OSSRA 2025 report audited 965 commercial codebases. 97% contained open source. 86% had vulnerable open-source components, and 81% had high or critical ones, up from 74% the year before. 90% had components more than four years out of date, and 56% had licence conflicts.

Sysdig’s 2023 usage report found that 87% of container images had a high or critical vulnerability. It also found that only 15% of fixable high and critical vulnerabilities were actually in use at runtime. So the raw count alone won’t tell you much either.

Go scan your dependencies, your OS images, your containers. You’ll see. I did exactly that recently when I went looking for a clean Node.js image, and there isn’t one.

And that’s normal. A perfect state is almost never reachable. The industry moves so fast that when you finish one round of cleanup, you start the next one just to keep pace. The honest vendor tells you that up front. The other one sells you “secure by default” and lets you find out.

Strapping a rocket to a car that isn’t built

This is where AI comes in, and why I think the situation is sharper now than before.

You can’t push full gas in a car that isn’t properly built. Loose wheel nuts, worn brakes, no seatbelts — at 50 km/h it’s an annoyance, at full speed it’s a crash. What a lot of companies are doing right now is strapping a rocket booster onto that car. And nothing else.

The DORA 2025 State of AI-assisted Software Development report, based on roughly 5,000 professionals, puts it more politely than I do: AI’s primary role is as an amplifier of existing strengths and weaknesses. Loosely coupled teams with fast feedback loops gain. Tightly coupled, slow organisations see little benefit, with “localized pockets of productivity… lost to downstream chaos”. And honestly, some ecosystems had a lot more weaknesses than strengths to amplify.

It gets better. In METR’s randomised controlled trial from 2025, experienced open-source developers were 19% slower with AI tools, while believing they were 20% faster. The caveats matter: 16 developers, 246 tasks, early-2025 models. But the gap between what people felt and what was measured is exactly the gap I see in sales pitches.

And Veracode’s 2025 research, testing more than 100 LLMs on 80 tasks, found that generated code introduced security flaws in 45% of test cases, over 70% for Java, and that security didn’t improve as the models did. It’s a benchmark, not production code. But who reviews the production code when the person selling it can’t read it?

Put the three together. A tool that amplifies what you already are, that makes you feel faster than you are, and that writes insecure code nearly half the time when nobody checks. In the hands of a team that controls its SDLC, that’s a real boost. In the hands of somebody selling a dream with no track record, it’s the rocket on the car.

And look at the dates on those crazy numbers again. That’s deliberate. I picked studies that look a little into the past, because the past is the only honest input we have for what to expect next. The overruns, the black swans, the out-of-date components, the vulnerable images: they were all measured before AI was writing code, or at the very start of it. That’s the baseline. Put an amplifier on that baseline and it isn’t hard to guess which way the numbers go next.

So who is driving?

I keep coming back to the same question when the next call comes in. The technology was rarely the problem. The pitch was. Somebody promised a number they never calculated, a scope they never checked, a speed they never measured, and somebody else believed it because they had no way to know better.

The industry rewards the attractive business case over the accurate one. The tools now make the attractive case cheaper to produce than ever.

So the next time someone shows you the slide with the savings on it, what will you ask them? And when they answer, will you be able to tell whether they’ve actually built the car — or just bought the rocket?

Sources

← cd ../blog/