The POMVP: When “Just Build Something Quick” Meets “But Make It Production-Ready”

POC + MVP = POMVP

Let me paint you a picture.

Your customer walks into the room (or pings you on Slack) and says: “We just need a quick proof of concept. Nothing fancy. Just show us it works.”

Okay, Cool. You’ve heard this before. Napkin sketch territory. A weekend warrior special.

Then, three sentences later: “Oh, and it needs to handle our 10,000 daily users, integrate with Salesforce, pass a security review, and we want to demo it to the board next Thursday.”

Congratulations. You’ve just been handed a POMVP — a Proof of Minimal Viable Product — the Frankenstein’s monster of modern software development and/or AI development that nobody asked to name but everyone is building.

The Old World Had Clean Lines

There used to be a relatively sane taxonomy in software development.

A Proof of Concept was a disposable experiment. It was the architectural equivalent of a napkin sketch — you drew it, you proved the idea wasn’t insane, and you threw the napkin away. Nobody expected the napkin to hold water. It existed to answer one question: “Can this even work?”

A Minimum Viable Product was the first real swing at building something. Stripped down, sure. Missing features, absolutely. But it was architected to be lived in. It had foundations. Load-bearing walls. A front door that locked. It answered a different question: “Will anyone actually use this?”

The POC was a sketch on a napkin. The MVP was a tiny house. Different animals. Different budgets. Different conversations.

That distinction is now dead, and AI killed it at the scene.

Welcome to the Blurred Middle

Here’s what’s actually happening in the real world right now, particularly in AI and agentic software:

Someone wants to prove that an AI agent can, say, automatically triage customer support tickets, route them to the right team, and draft initial responses. Classic POC territory. “Just show me it can work with our data.”

But “showing it works with our data” means connecting to their actual systems. Their actual customer data. Their actual security requirements. Their actual uptime expectations. You can’t demo a support triage agent with fake tickets and a mocked API and expect anyone to be convinced. The proof is the product. The demonstration is the deployment.

This is like saying, “Just build me a quick prototype car so I can see if the engine concept works — but I need to drive it on the M1 to test it.”

You’re no longer building a napkin sketch. You’re not building a tiny house either. You’re building a tiny house that needs to pass a building inspection and survive a mild storm, but you only have the budget and timeline for a napkin sketch.

That’s the POMVP.

Why AI Made This Worse (Or Inevitable)

Traditional software had a natural firewall between POC and MVP. You could fake a database. You could mock an API. You could hardcode responses and wave your hands during the demo. The illusion was cheap to maintain because software components could be convincingly simulated in isolation.

AI doesn’t work like that. Especially agentic AI.

An AI agent’s entire value proposition is that it behaves intelligently in real conditions. You can’t mock intelligence. You can’t hardcode emergent behaviour. A language model talking to fake data in a sandbox proves absolutely nothing to a stakeholder who wants to know if it’ll hallucinate when Karen from accounting submits a ticket in ALL CAPS with three typos and a passive-aggressive tone. Apologies Karen.

The proof is in the production pudding. Always.

So the POC, by necessity, starts looking like an MVP. It has to talk to real systems. It has to handle real edge cases. It has to not embarrass anyone in front of the board.

And suddenly your “quick two-week spike” needs:

• Real authentication and authorization
• Actual error handling (not just try/except: pass and a prayer)
• Logging and observability (because when the agent does something unhinged, someone will ask why)
• Data privacy compliance (because that’s real customer data now)
• Some semblance of scalability (because if the demo goes well, they’ll want to “just expand it” by Friday)

You’re not building a throwaway anymore. But nobody’s paying you for a keeper either.

The Architecture Tax Nobody Wants to Pay

Here’s where it gets genuinely painful.

The POMVP creates an impossible architectural tension. If you build it like a true POC — fast, dirty, disposable — one of two things happens:

1. It works, and they want to keep it. Now you’re maintaining a house of cards in production. You’ll spend the next six months rebuilding the plane while it’s flying, which everyone pretends is normal and nobody admits is insane.
2. It works, and they want to “just add a few things.” This is the software equivalent of saying, “The surgery went great, now can you just swap out the skeleton?” Features get bolted onto an architecture that was never designed to hold them. Every new addition is another floor added to a building with no foundation.

If you build it like a true MVP — properly architected, well-structured, built to last — one of two things happens:

1. It takes too long, and they lose patience. The window closes. The budget moves. The champion who was pushing for it gets reassigned. You built a beautiful house that nobody moved into.
2. The concept doesn’t validate, and you’ve over-invested. You spent three months engineering a beautiful, scalable, well-tested system that proved the idea was bad. Congratulations on your pristine, useless codebase.

The POMVP lives in the no-man’s-land between these outcomes, and there’s no clean playbook for it.

The Rise of Disposable Software (And Why It Changes Everything)

Here’s the thing nobody in enterprise software wants to say out loud: a lot of software doesn’t need to live very long anymore.

We’ve spent decades building software like we’re constructing cathedrals. Multi-year roadmaps. Elaborate architecture diagrams. Migration plans for migration plans. We’ve treated every line of code like it needed to survive for a decade.

But the reality of AI tooling in 2024–2025 is that the landscape shifts so fast that the thing you build today might be obsolete — not in years, but in months. Sometimes weeks.

That agentic workflow you spent four months perfecting? A new model release just made it possible in four lines of code with a different approach. That custom RAG pipeline you hand-tuned? A new framework just commoditised it.

Software is becoming more like a campfire than a cathedral. You build it, it serves its purpose, it burns down, and you build another one somewhere else.

And honestly? That’s not a bad thing. But it fundamentally changes how you should think about building. This section along could be a blog post in itself — I will get back to this at some stage.

So How Do You Actually Build a POMVP?

I don’t have a perfect answer here — anyone who does is selling you something. But here’s what I’ve learned from living in this awkward middle ground:

1. Invest in the seams, not the walls.

Build cheap, replaceable components connected by well-designed interfaces. The individual pieces can be held together by bubble gum and hope, but the way they connect should be clean. This means if (when) you need to rip out and replace a component, you’re doing surgery with a scalpel, not a chainsaw.

Think of it like building with LEGO instead of concrete. Each brick can be cheap and simple, but the connection system is standardised and reliable.

2. Make the throwaway parts obviously throwaway.

The worst POMVP sin is building something disposable that looks permanent. Label your hacks. Comment your shortcuts. Create a TECH_DEBT.md that’s brutally honest. Future you (or future someone) needs to know which walls are load-bearing and which are cardboard painted to look like brick.

3. Protect the data layer like it’s the only thing that matters, because it is.

Components come and go. Frameworks rise and fall. Models get replaced. But data is the one thing that persists and compounds. If there’s one place to invest properly in a POMVP, it’s how you store, structure, and protect data. Get this wrong and nothing else matters.

4. Build for deletion, not extension.

Traditional software architecture optimises for adding features. POMVP architecture should optimise for ripping things out. Every component should be removable without bringing down the house. This is a fundamentally different design philosophy, and most engineers aren’t trained for it.

5. Be honest about what you’re building.

The biggest POMVP disasters I’ve seen come from a mismatch in expectations. The builder thinks they’re making a POC. The stakeholder thinks they’re getting an MVP. Nobody says this out loud until things go wrong.

Name it. Call it a POMVP if you want — or call it whatever you like — but have the uncomfortable conversation upfront: “This will be real enough to prove the concept with real users and real data, but it is not production software. Here’s what it would take to make it production software. Here’s what we’re deliberately not doing and why.”

This will also help with asking for a budget. It can be a two phase operation with POC to MVP and funds being ringfenced and stage gates applied if it shows promise.

The Uncomfortable Truth

The POMVP isn’t going away. If anything, it’s becoming the default mode of building as AI tools accelerate how fast we can create functional software while simultaneously increasing the complexity of what “functional” means.

We’re in an era where a single developer with the right AI tools can build in a weekend what used to take a team a quarter — but the expectations have scaled proportionally. The speed created capacity, and the market immediately consumed it by raising the bar for what a “quick proof of concept” means.

The napkin sketch now needs to hold water.

The prototype car needs to survive the motorway.

The campfire needs to heat the cathedral.

Pick your metaphor. The point is the same: the gap between “proving it works” and “making it work” has collapsed, and if you’re building software — especially AI software — in 2025, you’re probably already building POMVPs whether you’ve named it or not.

The least we can do is be honest about it.

Link to the full video reakdown here: https://youtu.be/tw_5KmMTMuQ

If you’ve found yourself trapped in POMVP purgatory — building something that’s too real to be a prototype and too rough to be a product — you’re not alone. The whole industry is here. We just haven’t all admitted it yet.

P.s If “POMVP” becomes an industry-recognised term you heard it here first. Dan Murphy @ 10:03 on the 16th April 2026 with a coffee in hand.