· 7 min read
MVP development that still looks like a product
How startups can ship a first version that is small enough to finish and solid enough to show customers, without painting themselves into a rewrite.
An MVP is not an ugly prototype you apologize for. It is the smallest product that can teach you something expensive: whether a specific user will pay, return, or complete a job.
The failure mode is familiar. A founder wants the marketplace, the AI, the admin, the mobile app, and the referral engine because a competitor has them. That is a second-year product. Year one needs one loop that works.
Cut horizontally, not vertically. 'We will skip tests, accessibility, and login' is how you get a demo that cannot be used. 'We will support one role, one happy path, and one integration' is how you get a product.
Pick a stack your next hire can live with. Obscure frameworks feel fast in week two and expensive in month six. TypeScript, a boring database, and a well-known web framework are not unoriginal. They are how you keep options.
Instrument the thing. If you cannot see sign-up, activation, and the one action that means the product worked, you did not ship an MVP. You shipped a brochure with a database.
Design the empty states. Early products look abandoned because nobody put copy, first-run flows, or example data in them. Users will not imagine your vision. They will bounce.
Leave seams for the obvious next features, and do not build those features. Feature flags, a clean API, and a data model that can grow beat a speculative microservice map.
Budget for the week after launch. Support, crash reports, and the first five customer requests are part of MVP cost. Teams that vanish at deploy waste the learning the MVP was for.
If you are evaluating a studio, ask them to argue for a smaller first release than the one in your deck. The right partner is trying to get you to revenue and evidence, not to a large statement of work.