MVP thinking: saved me and hurt me
'Ship fast, iterate' is good advice. I've been applying it in the wrong places.
"MVP" is one of those words that gets repeated so much it stops meaning anything. But I've been thinking about it again lately, and I think the advice is right — I've just been applying it to the wrong layer.
The part where it helps
When I'm building something new, the biggest risk isn't poor execution. It's building the wrong thing. Shipping a rough version fast and using real feedback to figure out what actually matters — that works. It saves you from spending weeks on features nobody uses.
The minimal version of something forces you to find out what the core actually is. You think you know before you build it. You often don't.
The part where it hurts
Where I've gone wrong is treating architecture as something you iterate on later.
Move fast on features, figure out the structure later — this works until it stops working. At some point you have enough iteration that the codebase has become dense in a way that makes every new thing harder than the last. Features couple to each other in non-obvious ways. What felt like speed in the first month has become drag.
The mistake is thinking MVP means "don't think about foundations." It doesn't. It means "ship the smallest useful thing." Those foundations — the structural decisions that everything will be built on — are not features. You can cut features. You can't easily un-couple a codebase that grew without a plan.
What I try to do now
Separate the decisions. For features: be minimal, stay close to the user's actual need, resist the temptation to build ahead. For foundations: slow down, decide what the invariants are, don't compromise them in the name of speed.
MVP is a feature strategy, not an architecture strategy. I needed to experience the consequences before I really believed that.