The Difference Between an MVP and an Unfinished Product
One is a small, complete thing. The other is a large, broken one.
Every client who has ever said "let's keep it simple for v1" has, at some point, also asked why the simple version doesn't feel finished. The two ideas sound compatible. They are not. Simplicity and incompleteness are different things wearing the same clothes, and most of the pain in early-stage software comes from confusing one for the other.
An MVP is a smaller product, not a partial one. Every feature that exists in it should work end to end, with no dangling edges, no silent failure states, no "we'll fix that later" tucked behind a button. It does less than the final vision, but everything it does, it does completely. That is the whole discipline of scoping: deciding what to leave out, not deciding what to leave broken.
An unfinished product, by contrast, usually tries to do everything the final vision requires, just badly. It has the login flow and the payments and the admin dashboard, all half-built, all technically present, none of it reliable. It looks more impressive in a demo and performs worse in real use. Ambition without completion is just a longer list of things that will eventually embarrass you.
The tell is almost always in the edges: what happens when a user does the thing you didn't expect. A real MVP handles the unhappy path for its narrow feature set, even if that handling is just a clear error message. An unfinished product has no unhappy path handling anywhere, because nobody got around to it yet, because there was too much surface area and not enough time.
We tell clients the same thing every time: build less, but build it so it doesn't need an apology. A small product that works earns trust and buys you the next round of funding, users, or patience. A large product that half-works spends trust you don't have yet. Complexity is manageable. Incompleteness dressed up as ambition is the thing that actually sinks projects, and it's almost always avoidable with an honest conversation about scope before the first line of code gets written.