Ship less.
Make it real.

The real sin isn’t building too little or too much. Building without aim though, is another story.

Underbuilding sounds lean, but if you don’t deliver the keys, the thing that proves or disproves your bet, you have just wasted resources.

The best MVPs are ruthlessly scoped and sharply designed. You strip to the bone, then add back only what’s essential to test your core hypothesis with clarity and restraint.

That means:

Your MVP is your first amplifier. You need a circuit that works to get a signal.

Craft still matters

You don’t need motion or a dozen iterations on branding. Weeks spent on finding the right name only to land on a thing that still bothers. No need. Call it a thing, the shit or blob, doesn't matter much. What matters are working buttons and flawless interactions.

That slightly misaligned input field, that button that doesn’t respond to the first tap, the slider that clunks. It all adds up as signals of carelessness.

Users, particularly early ones, are not responsible for writing bug reports. They just close the tab and fade. Trust is a fragile thing.

So yes, keep it small. Keep it fast. But make it work. Make it so that every interaction leads somewhere meaningful. Every choice is respected. Every expectation is either met or clearly deferred.

Fakes are better than lies

A lot of seasoned builders use fake features in their MVPs. That “AI matchmaker”? Actually someone on the team reading profiles by hand. That “smart shopping assistant”? Just a Google Sheet and a few Zapier rules.

Wizard-of-Oz MVPs and concierge flows are legit tools as long as you’re honest about the experiment. When used with care, they help you validate demand, test UX, and stay fast.

Better a fake feature that works than a real one that doesn’t. But never let fakes become lies. Don’t pretend your product can do what it can’t, unless you’re ready to take the fallout when users catch on.

You don’t need the most recent library from FAANG or it's rebellious alternative. You don't need to slap the shiniest AI services slapped onto to the first spot that barely makes sense. You don’t need microservices scattered around. You probably don’t need containers.

Old fashioned, conventional options like REST, a monolith, a good linter etc, are more likely to take you farther than a bleeding-edge stack your team barely understands. MVPs are not obliged to provide solutions for problems that are not related to your core value.

Tech debt is real, but so is speed. And the best MVPs are built by people who know exactly which corners they’re cutting, and when they’ll need to fix them. Build knowing it might need reinforcement is a valid engineering practice.

If your MVP takes off with all the shiniest bells and whistles and you built it like a joke, the joke’s on you. Because now you’re scaling pain. Bad tech debt is a compound interest. And the repo doesn’t forget.

Let's admit, most MVPs go nowhere. Some get a few curious clicks. A few get praise but no retention. That’s fine.

The goal is to learn. The worst outcome is building something that looks like success just long enough to trick you into wasting the next 18 months scaling the wrong thing.

Real failure is when you get no feedback, no signal, and no new insight. That’s what happens when your MVP is too safe, too vague, or too broken to care about.

Make something people can react to. Even if they really hate it. Hate is actionable. Indifference is death.

MVPs are launched to probe the wilderness. You’re sending it out to gather signal. That means it has to work. The guidance systems, the telemetry and the structure needs to hold up long enough to tell you something useful.

But not every probe comes back.They might crash and burn, drift aimlessly or perhaps vanish into a cheeky black hole. That’s the nature of exploring unknown territory.

So fund it like a smart bet. Don’t pour in more than you can afford to lose. But also don’t cut so many corners that the signal gets garbled or never comes through.

A well-built MVP can fail and still move you forward. You can scrap it for parts. Reuse the systems. Redirect the learnings. All reducing the loss.

The craft is in the balancing act.

Build like failure is possible, even likely.

And make sure the mission still matters.

We’re in an age where any maker can push out a “working app” in a weekend with AI tools and no-code scaffolding. That’s powerful. It also means the noise and the bar for meaningful products has quietly gone up.

Speed on it's own is no longer impressive. The new differentiators are:

Clarity, curation and care.

Because users can smell mass-produced apps now. They look the same, feel the same with vague value promises. The magic’s gone.

That little moment where a button reacts just right, where the design breathes, where the experience makes someone smile. AI can’t imitate or learn that genuine delight. You still need a human behind the curtain who gives a shit.

So use the tools but don’t let them use you. Be faster, not lazier. The best builders won’t ignore AI and will out craft it.

Because the moment you get someone’s attention… it’s real.

You might only get one.