The smartest MVP I've seen this year had no backend. Everything was hardcoded.
Customers don't buy your backend. They buy the experience.
A founder showed me a demo last month. Clean interface. Real-looking data. The kind of thing you’d actually pay for.
I asked about the backend.
He laughed. “There isn’t one. It’s all hardcoded.”
He built it in a morning. He’d already closed three customers.
I made the opposite mistake at TinyWhale. Month one: two founders, five developers, and a plan. We knew what educators needed. We’d seen the problem firsthand. So we built. Scheduling logic, payment rails, booking flows, Google review integrations. All of it, from scratch, the “right” way.
Month three, we let three of those five developers go.
Not because the code was bad. The code was fine. We’d spent two months building features nobody asked for. We thought we understood the problem. We understood a version of the problem we invented while writing code.
The lesson took a while to land: customers don’t care about your backend. They care about the experience.
The technique has a name. Wizard of Oz MVP. The idea is simple: build a production-looking UI with hardcoded or mocked data, no real backend. Use it for one thing only, customer demos and early validation.
Can you close a customer with this? Can you get someone to say “I would pay for this”? Can you watch a real user try to use it and understand what they actually need?
If yes, you’ve earned the right to build the backend.
If no, you’ve saved weeks of engineering time on something that wouldn’t have worked anyway.
The backend is a bet. A bet that the experience you’re building is the one customers will want. Most startups lose that bet on the first try, not because the engineering was bad, but because the feedback loop came too late.
The technique isn’t new. Eric Ries wrote about it in The Lean Startup over a decade ago. Zappos’ founder bought shoes from retail stores and shipped them manually before building any inventory system. Airbnb’s founders photographed apartments themselves before the platform could automate any of it.
What’s new is the cost. Building the “Oz” part used to take a week. Now it takes 30 minutes.
Describe the product to Claude Code. Tell it what the interface should show, what the user flow should feel like, what data should appear on screen. Half an hour later you have something running, not a wireframe, not a sketch, but a clickable interface with real-looking data that you can put in front of a customer today.
The UI looks production-grade. The interactions feel real. There’s nothing underneath. And that’s exactly the point.
I know a founder who built five separate product concepts in a single week. Five different interfaces, each with enough hardcoded data to run a real demo, each built in an afternoon. By Friday he had three customer conversations. By the following Tuesday, he knew which one to actually build.
That’s weeks of customer discovery compressed into five days. Not a single API endpoint written.
Here’s what engineers get backwards: we build in the order that feels comfortable, not the order that learns the fastest.
Backend first. Database schema. API layer. Auth system. Then, eventually, the UI. This is the correct engineering sequence. It feels right. For production systems, it is right.
For a startup in week one, you don’t need a production system. You need an answer to one question: does anyone actually want this?
Validate the experience first. Build the backend when you have signal.
Most founders I talk to know this in theory. They’ve read the books. But when they sit down to build, the engineering instincts take over. The backend feels “real.” A hardcoded UI feels like cheating.
It’s not cheating. It’s the right order of operations.
One caveat worth being clear about: the Wizard of Oz works for demos and discovery. It doesn’t work if you’re actively misleading paying customers about a product that doesn’t function. When you close a customer with a hardcoded UI, be honest about where the product is. “This is what it’ll look like” is fine. “This is what it does today” is not.
Use it to earn the signal. Then build what you’ve proven.
The founders I see doing this aren’t lazy. If anything, they’re more disciplined than most. They’re choosing not to build until they’ve earned the right.
What experience are you waiting to validate?
Whatever the idea is, the one you’ve been turning over in your head, the one you think would take a month to build “properly,” the curtain takes 30 minutes. Build that first.
You might be surprised what’s behind it.
I write about building products and making better technology decisions every week at MacroStack. If this resonated, subscribe.