The M in MVP Has Changed: Riding Jevons Paradox from Minimal to Maximal Viable Product

The Farm Visit Problem

For years, I sold people farm visits when they wanted ready meals.

I’d been building automation and AI pilots with the lean startup gospel tattooed on my brain: Do the smallest thing fast. Ship it. See what the customer thinks. Minimum Viable Product. The holy trinity of startup wisdom.

So I’d show up with my MVP—functional, scrappy, honest about its limitations—and wait for the feedback loop to spin up.

Instead, I got this:

“Don’t waste my time with this half-baked shit.”

Not in those words, usually. But that energy. The polite version was: “This is interesting, but can you come back when it does X, Y, and Z?” The subtext was clear: Why are you showing me ingredients when I ordered dinner?

I thought I was being agile. They thought I was being cheap.

The MVP playbook assumed customers would meet you halfway—that they’d squint at your prototype and see the vision, fill in the gaps with imagination, join you on the journey from seed to harvest. Some did. Most didn’t. Most wanted the ready meal. They wanted to taste the thing, not tour the farm.

I kept building small. They kept wanting big. I blamed them for not understanding how software works. They blamed me for not understanding how their time works.

Then I started using Claude Code, and the argument became moot.

Part I: Anyone Can Do This (But They Don’t)

Here’s what happened.

I’d been designing a security product called Injectionator—a system that protects AI applications from prompt injection attacks. The architecture was ambitious: a dual-LLM pattern with a trust scoring system, multiple inspection stations, four operational modes, inbound and outbound scanning pipelines.

In the old world, this was a six-month build with a team. I knew because I’d scoped projects like it before. You’d need backend engineers, maybe a frontend person, someone who understood security, a devops human to keep the lights on. You’d cut features ruthlessly. You’d ship the scraggly MVP and pray.

Instead, I built it in weeks. With Claude Code. Just me.

Not a prototype. Not a “proof of concept” that falls over when you breathe on it. A working system with 80+ passing tests, comprehensive documentation, a web framework, validation layers, the works. Then I kept going—because why not?—and built a gamified demo called “Meatbag vs. HR” where players try to hack a vulnerable chatbot while watching their attacks flow through an animated security pipeline.

Attack cards. Mock LLM simulators. Theming systems. Pipeline visualizations with little icons showing where your injection got caught.

This is not an MVP. This is what an MVP wanted to be but couldn’t afford to become.

When I showed people, they asked the same question every time:

“How many people on your team?”

The answer—“Just me and Claude”—never lands right. There’s a pause. A recalibration. You can watch them pattern-match to the only explanations that make sense in their mental model: He’s lying. It’s simpler than it looks. The code is garbage. He had help he’s not mentioning.

What they can’t compute is the actual truth: the economics of building changed, and nobody sent them the memo.

The Jevons Paradox of Software

In 1865, an English economist named William Stanley Jevons noticed something strange about coal.

Steam engines had gotten dramatically more efficient. You’d think England would burn less coal as a result—same output, fewer resources. Logical, right?

Wrong. Coal consumption exploded. The efficiency gains made steam power cheap enough for new applications. Factories that couldn’t afford steam engines suddenly could. New industries emerged. The savings didn’t get pocketed—they got reinvested into more.

This is Jevons Paradox: when you make something more efficient, you often increase total consumption rather than decrease it.

I’ve been living inside this paradox, except the resource isn’t coal. It’s ambition.

AI coding tools like Claude Code don’t make software smaller. They make it bigger. They don’t save time—they spend that time on features you would have cut, polish you would have skipped, edge cases you would have punted to “version 2.”

The marginal cost of “one more feature” collapsed. So I built more features. The activation energy for “let’s make this actually good” dropped to near zero. So I made it actually good.

I wasn’t trying to build something maximal. I just stopped having reasons to build something minimal.

This isn’t unique to me. It’s happening everywhere, to everyone who actually uses these tools:

Projects that once needed months get prototyped in days
Startups that couldn’t afford a ten-person backend team now field two developers and an AI copilot
Enterprises redeploy saved developer-hours into new initiatives instead of layoffs
Solo founders build things that make venture-backed teams nervous

The old MVP logic was: Build less because building is expensive.

The new logic is: Build more because the marginal cost collapsed.

And here’s the thing—anyone can do this. The tools are available. Claude Code isn’t secret. Cursor isn’t invite-only. The documentation is free. The barrier to entry is a credit card and curiosity.

But most people don’t.

They read the articles, nod along, maybe try it for an afternoon, then go back to building small. They’re still visiting farms when the customer wants a ready meal. They’re still showing up with ingredients when they could show up with dinner.

Why?

Part II: The Critiques (And Why They’re Partially Right)

Let’s steel-man the skeptics. There are two main attacks on what I’m describing, and both contain truth.

Attack #1: “It’s Just Vibe Coding”

Andrej Karpathy coined “vibe coding” in early 2025 to describe a new way of programming where you “fully give in to the vibes”—type natural language, accept AI suggestions without reading them, copy-paste error messages until things work.

Nine months later, the term became both Silicon Valley’s most hyped methodology and a cautionary tale.

The Cursor CEO put it bluntly: “If you were vibe coding, you would close your eyes and just ask for a house to be built. You wouldn’t examine the foundations, you wouldn’t look under the floorboards, and you wouldn’t look at the wiring.”

The data backs up the concern:

One study found AI-assisted developers produced 3-4x more code but generated 10x more security issues
40% of AI-generated code contains vulnerabilities
45% of developers report frustration debugging AI-generated code
A security analysis found 170 out of 1,645 apps built with one vibe-coding tool had issues allowing anyone to access personal information

Even Karpathy stepped back from his own creation. His latest project was entirely hand-coded. “I tried to use Claude/Codex agents a few times but they just didn’t work well enough at all,” he posted.

The vibe coding critique is real: AI can hide complexity as easily as it generates it. You can build a house of cards that looks like a mansion. You can ship something “maximal” that’s actually maximal technical debt.

Fair. Point taken. Moving on.

Attack #2: “Building Is Easy, Distribution Is Hard”

Here’s the other shoe:

Great, you built something. Now who’s going to use it?

GTMfund, a venture firm, now operates under this thesis: “Distribution is the final moat in the AI era.” Their argument is that building software products has never been easier—so why are so many well-funded startups failing? Because they focused on product development and not on distribution excellence.

The math is uncomfortable: AI reduces the cost of software creation. Automation reduces the cost of operations. The bottleneck shifts to the one area that does not scale automatically—marketing, sales, getting humans to give a damn.

The number of customers in the world stays roughly the same. People don’t suddenly buy 10x more products just because they’re easier to build.

You can prototype a SaaS in a weekend, but you can’t prototype product-market fit. You can generate 10,000 lines of code in an afternoon, but you can’t generate trust. AI gave everyone a Ferrari, but most of us are still stuck in the same traffic.

This critique is also real. I’ve built Injectionator, but I haven’t sold it. I’ve made the ready meal, but the restaurant doesn’t have customers yet. The demo is polished, but polished demos don’t pay rent.

Fair. Point taken. And yet—

Part III: You, The Meatbag, Are The Throttle

Here’s what both critiques miss:

These are human problems. They always were.

Vibe coding produces insecure, unmaintainable garbage—but you’re the one who shipped it without reviewing. The tool didn’t fail. Your judgment did. As Simon Willison put it: “If an LLM wrote every line of your code, but you’ve reviewed, tested, and understood it all, that’s not vibe coding—that’s using an LLM as a typing assistant.”

Distribution is hard and doesn’t scale—but it was always hard. Building was your excuse not to think about it. You could hide in the code, tinker with features, delay the uncomfortable work of selling. Now you can build the thing in two weeks. What’s your excuse now?

The technology didn’t introduce these problems. It removed the thing that was hiding them.

And that brings me to the word I keep coming back to: throttle.

A throttle does two things:

Press harder to go faster—it’s an accelerator
Choke the flow to limit speed—it’s a constraint

You are both.

Claude Code removed the mechanical resistance from building software. What’s left is you. Your imagination. Your willingness to own outcomes. Your courage to ship something “too big” and risk looking foolish. Your discipline to review the AI’s work instead of vibing your way to production. Your stomach for the distribution grind that building can no longer shield you from.

Some people press the throttle. They build maximal products because the marginal cost collapsed and they’re curious what happens when you don’t artificially constrain yourself.

Others choke it. They stay minimal—not for strategic reasons, but because the scale is disorienting, because taking responsibility for something big is scarier than taking responsibility for something small, because it’s easier to blame the tools than to engage with them.

The difference isn’t skill. It’s not talent. It’s not access—the tools are the same for everyone.

The difference is how hard you’re willing to press.

The Ready Meal Test

Here’s how I think about it now.

When I show up to a customer with something I’ve built, I ask myself: Is this a farm visit or a ready meal?

Am I asking them to imagine what this could become, to squint at the ingredients and trust the recipe? Or am I handing them something finished, something they can taste, something that respects their time?

The old answer was: We can’t afford ready meals. The best we can do is farm visits, dressed up with vision decks and roadmaps.

That answer is obsolete.

The technology isn’t what changed. The excuse is what disappeared.

You can still build minimal. Sometimes you should—there are legitimate reasons to test a hypothesis cheaply before investing. But you can no longer hide behind can’t. The question is no longer “Can I build this?” The question is “Will I?”

That’s a different kind of question. It doesn’t have a technical answer. It has a human one.

The Moment of Decision

Dear Reader, here’s where I’m supposed to tell you to “try Claude Code” or “embrace AI tools” or whatever the call-to-action playbook says I should write.

I’m not going to do that.

What I’m going to tell you is that you’re standing at a throttle, and you’ve always been standing at a throttle, and the only thing that changed is how obvious it’s become.

The technology works. The tools are available. The barrier isn’t access or knowledge or some secret prompt engineering technique that the cool kids know. The barrier is the same thing it’s always been:

How much responsibility are you willing to take on?

Build maximal, and you own the maintenance. Ship the ready meal, and you own the Yelp reviews. Stop hiding in “we’re still iterating” and you have to face whether the iteration actually matters.

Some people will read this and feel permission. They’ve been waiting for someone to say it’s okay to build big, to stop apologizing for ambition, to ship something that doesn’t have “beta” as a permanent excuse.

Other people will read this and feel exhausted. They don’t want to press harder. They want the AI to press for them. They want the throttle to push itself.

Both reactions are valid. I’m not here to judge.

I’m here to tell you that the choice is visible now in a way it wasn’t before. The economics changed. The excuses evaporated. What’s left is you, deciding.

Press or choke.

Ready meal or farm visit.

Minimal or maximal.

The M in MVP changed.

It used to mean “minimal” because minimal was all we could afford.

Now it means whatever you decide it means.

The technology isn’t limited.

You are.

Or not.

That part’s up to you.

Steve Chambers builds security tools for AI applications at Injectionator. He wrote this article with Claude, then reviewed every word himself—because vibe coding is not the sin, but pretending you’re not responsible for the output is.