Startups Azərbaycanca oxu →

MVP: how to build a first version that fits into 6 weeks

An MVP isn't a cheap version of the product. It's the first step built to test the most important assumption at the lowest cost. What to build, what to cut, and how to split the 6 weeks?

Nail Seyidov
Founder of NS Studio · 4 min read
MVP: how to build a first version that fits into 6 weeks

Photo: Kaleidico / Unsplash

A startup founder's first plan often looks like this: sign-up, profile, chat, payments, ratings, notifications, an admin panel, three languages, iOS, Android and a web version too. All of it “must be in the first version”.

A plan like that drags on for months, eats the budget and, worst of all, in the end it turns out the users didn't need half of it. An MVP exists precisely to prevent that.

What an MVP is, and what it isn't

MVP stands for Minimum Viable Product: the smallest product that works. Its goal isn't to ship an app but to answer one question: will people use our way of solving this problem?

An MVP isn't a half-finished product either. If you want to build a car, the first version can be a skateboard rather than a single wheel: it's small and simple, but it gets a person from A to B. A half-finished product does no job at all; an MVP does one job all the way.

One user, one problem, one action

You should be able to write your MVP in one sentence:

For whom do we solve which problem with which core action?

For example: “we turn booking a vet appointment into a one-minute action for pet owners”. That sentence has no chat, no ratings and no three languages. Anything that doesn't fit into it is the second version's job.

The 6-week plan

Week 1 — the problem and the user. Don't write code. Talk to 15–20 potential users: do they really have this problem, how do they solve it now, how much time and money do they spend on it? Your mind may change after these conversations, and that's the cheapest change there is.

Week 2 — the scenario and the prototype. Sketch the user's main path on paper or in Figma: they come in, what they see, what they tap, what they get. Show the prototype to 5 people. Wherever they get stuck, that's where the problem is.

Weeks 3–5 — building. Build only the main path. For parts like sign-up, payments and notifications, use ready-made solutions; this isn't the time to write them from scratch. At the end of every week there should be a working version, not “almost there”.

Week 6 — the first users. Find your first 10 users by hand, without ads. Watch them, talk to them, write down where they struggle. This week is for learning, not for new features.

What to cut

The first version usually doesn't need:

  • A beautiful admin panel. In the first month a simple spreadsheet is enough.
  • Several languages. Prove it works in one market first.
  • Complex roles and permissions. Two roles — user and admin — are often enough.
  • Your own payment or chat system. There are ready-made services for that.
  • A separate app for each platform. Maybe the web or a PWA is enough. See “Flutter or native” and “Website or mobile app?”.

Cutting isn't losing. Everything you cut stays on the list; it's just waiting for its turn.

Sometimes an MVP has no code

The fastest MVP is sometimes not software at all:

  • A landing page and a form. Describe the product, add a “pre-order” button and see how many people press it.
  • A Telegram bot. For taking orders or enquiries it's much faster to set up than an app.
  • A manual service. You do the work behind the scenes, and the user gets the result. If the process works, you automate it later.

The rule is this: before you automate the product, prove that it works by hand.

What to watch after launch

  • Do people complete the core action all the way through?
  • Do they come back, not just once?
  • Are they ready to pay, or at least to spend their time?
  • What do they ask about, what do they complain about?

Look at the numbers, but in the early stage the most valuable information is in conversations. A deep conversation with ten users teaches you more than a big survey.

The bottom line

The goal of an MVP isn't shipping an app; it's learning — at the lowest cost, as fast as possible. At the end of the six weeks, either your assumption is confirmed and you take the next step with confidence, or you stop without losing months and a big budget on the wrong road. Both outcomes are a win.

If you're still at the “let's build it and see” stage, first read “Let's build an IT startup, bro”. If you want to cut your MVP list together, send a mentorship request.

On this topic

Keep reading

All posts →
Startups 5 min read

Let's build an IT startup, bro

I've got a great mobile app idea, bro, it's totally going to blow up. We just need a bit of money… Every line of this dialogue hides a mistake that sinks startups.