You can spend months hacking on a feature nobody asked for, and look busy the entire time.
I'm just as guilty as the next guy, I've shipped many products that nobody explicitly asked for. Insert the overused quote from Henry Ford about faster horses here... You find that building a solution to a problem that doesn't exist is way easier than talking to customers and facing rejection.
The MVP is supposed to be the smallest thing that gets you evidence. Not the smallest thing that looks good on a demo call.
If your MVP doesn't answer a specific question about your customers, you built a demo to impress yourself.
The MVP is a learning machine, not a codebase
Lean Startup got popular for totally valid reasons. Build-Measure-Learn is a great loop if you don't ignore the customer.
The trap is that "Build" feels like progress. "Measure" feels like math homework. "Learn" feels like admitting you were wrong. So we skip the scary parts and go back to build another feature.
I worked at a hardware startup, a wearable company, and I walked in with Python and NLP experience and exactly zero experience in firmware, neural networks, electrical engineering, or building anything you could hold in your hand. My job title said machine learning. My actual first few months looked like sitting next to the lead data scientist, the lead mechanical engineer, and the CTO - who also happened to be the lead electrical engineer, because that's how early-stage hardware works, everyone wears at least three hats. Within about a year I'd gone from "I can write a script" to hand-rolling RNNs in Python and C, designing my own parts in CAD and 3D printing them, and wiring my own small PCBs. Nobody handed me a training plan. There wasn't one. The company needed a working sensor loop that could tell the difference between a real signal and noise, and the fastest way to find out if that was even possible was to build the ugliest version of it and see what broke.
An MVP isn't proof you already know what you're doing. It's proof you can find out fast enough to matter, across however many disciplines the problem happens to touch. Physical products cost money in ways software founders don't budget for. Customer feedback isn't a process step - it's the entire job. "Let's pivot to SaaS" means "I don't want to deal with my bill of materials anymore." And contract manufacturing will age you a year in six months.
An MVP that looks finished before you've validated anything is expensive. In hardware, it means you pre-bought inventory that you may never use. In software, it means you're defending features that paying customers never asked for.
The fastest MVP is often not software
Founders keep building because building feels safer than learning. Airbnb, Zappos, and Buffer didn’t start with complex products. They started with proof. They built manual services, landing pages, and hacked-together tests that validated demand before they wrote serious code.
AI makes this easier, and also more tempting. One person with AI can generate more artifacts in a day than a small team used to in a month. The problem is most of it isn't evidence.
Where AI actually helps and where it wastes your time
Here's how I'd use AI for MVP work, based on the stuff that has burned me before.
Explainer scripts and demo flows
Video MVPs work because they compress uncertainty. You can show the workflow without building it.
Use AI to help you draft a 90-second script. Have it write three versions for three buyer types, and add a 'what happens next' section to keep you (and by "you" I definitely mean me) from rambling. Then record it yourself - people can tell when you're reading something you don't believe.
Landing pages that convert
Segment-specific pages are boring to write, so we skip them. Then conversions tank and we act confused.
Use AI to generate variations, but keep the structure tight:
- Problem: one sentence, specific
- Outcome: one sentence, measurable
- Proof: what you can credibly claim today
- Ask: waitlist, demo request, or pay
Then track signups. If you don't measure, you're just guessing.
Concierge operations, with a paper trail
I built an AI system for a services company to improve accuracy. The idea was simple. The hard part was figuring out what happens when the AI screws up, who sees it, and how we measure whether it's getting better.
Concierge MVPs die when you don't log the work. You need a queue. You need timestamps. You need to know what the customer actually received.
If you don't log the work, you can't replay what happened. You just have vibes and a pile of support emails.
AI can draft emails, summaries, and reports. Fine. But the workflow needs boring infrastructure:
- a spreadsheet
- a lightweight database
- a ticket queue
- a form that writes to a table
If you can't replay what happened for a single customer, you can't learn.
Mock product surfaces (fake doors are fine)
Fake-door flows are honest if they're honest.
"Click here to enable X" then "Join the waitlist" is fine. It measures intent.
Faking traction is different. I've watched companies inflate numbers to impress a VC, then spend six months pretending the numbers were real.
I once got hired into a company that was on VC life support. The VC agreed to re-cap with $1MM if they could get spend below $250k/year. The company had one employee, a shared office, and no bills. We went back and forth for about 15 minutes, couldn't get "spend" low enough, and the company went from alive to dead on the spot.
That wasn't a product problem. The founder needed to win the negotiation more than he needed to save the company.
Your MVP should reduce the surface area for that kind of nonsense. Evidence helps.
Use traditional software for the parts that need to be correct
Don't get creative with:
- Analytics: clicks, signups, waitlist joins, demo requests
- Payments: Stripe, invoicing, accounting systems
- Experiment state: feature flags, release records, test variants
- Operational tracking: queues, tickets, logs
If money is involved, don't get creative. If measurement is involved, use real tools.
Keep the important parts human
AI can help you move faster. It can't decide what you need to prove.
Humans still have to do:
- Learning design: what belief are we testing?
- Customer exposure: talking to buyers, not "users"
- Honest limits: faking workflow is fine; faking demand is self-harm
I've watched teams spend months polishing onboarding while ignoring the fact that nobody with a budget asked for the product.
Send me your MVP idea and what you think it needs to prove. I'll tell you what I'd measure first and what I'd skip.
You might also like: Vibe Coding Hangover: What Happens After the MVP Ships.
-Sethers
