How to Build an MVP for a Startup

Most founders already know the phrase "minimum viable product." Fewer actually build one that way. What usually happens instead is a "minimum viable product" that quietly grows into a full first release, complete with a settings page, three user roles, and a design system nobody asked for yet.

An MVP isn't a smaller version of your final product. It's a tool for answering one question: will people actually use this? Everything you build should serve that question, and nothing else.

Start with the assumption, not the feature list

Before writing a single line of code, write down the riskiest assumption your business depends on. Not "will people like the design," but something closer to "will busy salon owners actually respond to automated booking reminders" or "will people pay for a curated version of something they can get for free elsewhere."

That assumption becomes your filter. Every feature gets tested against one question: does this help me find out if the assumption is true? If the answer is no, it doesn't belong in version one, no matter how good the idea is.

Map the smallest path to an answer

Once you know what you're testing, work backward to the smallest thing that could test it. Sometimes that's not even software. A landing page describing the product with a "join the waitlist" button tells you a lot about demand before you write any real functionality. Other times you need something people can actually use, like a working Telegram bot that handles the one task you're testing.

The mistake founders make here is assuming "smallest" means "cheap and ugly." It doesn't. A one-screen bot or landing page can be well made and still be minimal in scope. The goal is narrow, not sloppy.

Pick the platform that gets you there fastest

This is where a lot of MVPs lose months before they even start. Founders default to "we need an app" when a Telegram Mini App, a bot, or even a simple web page would answer the same question in a fraction of the time. Telegram alone has hundreds of millions of active users, and building inside it means you skip app store approval, native onboarding friction, and a chunk of the usual build time.

If your idea involves any kind of ongoing interaction with users, a Telegram bot or Mini App is often the fastest legitimate way to get a working product in front of real people.

Build, then get it in front of real users fast

Set a deadline that feels slightly too tight. MVPs stretch to fill whatever time you give them. Once it's working, get it to actual potential users, not friends who'll tell you it's great. Watch what they do, not just what they say. Someone saying "I'd definitely use this" means very little. Someone actually coming back a second time means a lot.

This is also where working with one person instead of a team pays off in practice, not just in price. When the same person who understood your original idea is the one writing the code, there's no game of telephone between a project manager, a designer, and a developer, and no meaning lost translating your assumption into someone else's spec. Changes based on early user feedback get made directly, without a change request going through three people first.

Resist the urge to add "just one more thing"

Every founder feels the pull to add a feature mid-build because a friend suggested it or a competitor has it. Write it down for later and keep going. The entire point of an MVP is that you're not sure yet what belongs in the final product. Adding features before you've validated the core idea just delays the answer you're actually looking for.

Treat the MVP as a question, not a launch

When the MVP is live, the work isn't done. Now you're watching, adjusting, and deciding whether to keep going, pivot, or stop. Some of the best-known products today started as something much simpler than what they are now, built specifically to test one assumption before anyone committed to building the whole thing.

If you have an idea and want a straight opinion on the smallest version worth building, describe what you're trying to test and what a working version needs to do, then get a plan back for what that actually takes to build.

See SolaLab's services: what I build and what it costs