Solution
Launch an MVP that tells you something real
Last reviewed , published by Gjethe
A minimum viable product (MVP) is the smallest version of a product that lets real users test your riskiest assumption. Gjethe helps founders choose what to test, scope the fewest features that test it, design and build it as a web or mobile app, launch it with analytics in place, and decide what to build next from real usage.
- 1Find the riskiest assumption
- 2Cut the scope
- 3Choose the format
- 4Design the core flow
- 5Build on a foundation that can grow
- 6Launch with measurement
How do we take an MVP from idea to launch?
- 1
Find the riskiest assumption
Will people pay? Will they use it weekly? Can the core feature be built at all? We decide which question the MVP must answer.
- 2
Cut the scope
We list every feature you imagine, then keep only those needed to test that question. The rest goes on a later list, not in the bin.
- 3
Choose the format
A web app reaches users fastest and is easiest to change; a mobile app makes sense when the experience depends on the phone, camera, location, notifications.
- 4
Design the core flow
We design the few screens users need to reach the value, and test the prototype before building.
- 5
Build on a foundation that can grow
Small, but not throwaway: authentication, database and payments built properly so the MVP can become version one.
- 6
Launch with measurement
Analytics for activation and retention are in place on day one, so the decision afterwards is based on data.
Most MVPs fail by being too big, not too small. Every extra feature delays the moment you learn whether people want the product. This page describes how we approach an MVP from the first conversation to the decision after launch. The sections below walk through each step, from the first idea to real users.
What does the MVP loop look like?
Assumption
The riskiest thing that must be true
Smallest test
The minimum feature set that tests it
Launch
Real users, real data
Measure
Activation, retention, feedback
Decide
Build on it, change it or stop
Web app, mobile app or no-code prototype?
| Option | Best when | Watch out for |
|---|---|---|
| Clickable prototype | You need investor or user feedback before writing code | It can't prove people will actually use it |
| Web app | Users are at a desk, or you need to iterate fast | Less natural for on-the-go, notification-led products |
| Mobile app (React Native) | The value depends on the phone | Store review adds a step to every release |
| No-code tools | Workflows are simple and standard | Limits arrive quickly with custom logic or scale |
How do you decide what goes into the MVP?
Write down every feature you imagine, then ask one question about each: would leaving this out make the test meaningless? If not, it moves to the later list. What remains is usually one core workflow, the account and permission basics around it, and a way to measure whether people use it.
It helps to separate what users must do from what they might like to do. A booking product must let someone book; it doesn't yet need reminders, reviews, loyalty points and a referral scheme. Those features matter once you know people book at all.
Finally, decide what manual work you're willing to do behind the scenes. Many successful MVPs handle edge cases by hand (approving accounts, sending invoices, onboarding by video call) so the code can stay focused on the core value.
Which metrics tell you whether the MVP works?
Pick a small number before launch and agree what result means “continue”.
| Metric | What it tells you |
|---|---|
| Sign-ups from your target audience | Whether the promise attracts the people you built it for |
| Activation | Whether new users reach the core value, the first booking, report or upload |
| Return usage | Whether the product is useful enough to come back to |
| Willingness to pay | Whether people will pay, or pre-order, at your intended price |
| Qualitative feedback | Why users behave as they do, the context numbers can't show |
What should every MVP include?
- One clear core flow from sign-up to the main value
- Authentication that won't need replacing later
- Analytics for sign-up, activation and return visits
- A simple way for users to give feedback
- Error monitoring, so bugs are seen before users report them
- Payments, if willingness to pay is the question being tested
What happens after the MVP launches?
The first weeks after launch are for watching, not building. We look at where new users drop off, which features are used and which are ignored, and what people say when you talk to them directly.
From there the decision is usually one of three: double down on what works and improve it, change the approach because the core assumption was wrong, or stop and save the budget for a better idea. All three are useful results, the only bad outcome is spending another year building without knowing which applies.
Common MVP mistakes
Building for every user type
Pick the one customer you most need to convince. Serving everyone at once doubles the scope and blurs the result.
Polishing before learning
Animations and edge-case settings can wait. Users forgive rough edges in a product that solves their problem.
No success criteria
Decide before launch what result means “continue”. Otherwise every outcome looks like a reason to keep building.
A throwaway codebase
An MVP built to be discarded often isn't. Build the foundations properly and keep the features few.
Frequently asked questions
What is the difference between an MVP and a prototype?
A prototype shows how a product could work; an MVP is a working product real users can use, so it can prove behaviour rather than opinions.
Should my MVP be a web app or a mobile app?
Usually a web app, because it is faster to change and share. Choose mobile when the core value depends on the phone itself.
How much does an MVP cost?
It depends on the number of user types, screens, integrations and whether payments are included. Our MVP cost guide explains the factors; you get a fixed quote after a free consultation.
What do you need from me to start an MVP?
A clear description of the problem, the people who have it, and how you believe the product solves it. Notes from conversations with potential users are the most valuable input of all. They tell us which features matter before a line of code is written.
Do I need a technical co-founder to launch an MVP?
Not necessarily. Many founders launch with an external team and hire technical leadership once the product shows traction. What matters is owning the code and having it documented, so a future team can take over.
Can the MVP grow into the full product?
Yes. We build the foundations (authentication, data model, payments) properly, so version two builds on the MVP instead of replacing it.
Services that make it happen
MVP Development
The smallest product that proves your idea.
Web Applications & SaaS
Portals, dashboards and subscription products.
Mobile App Development
iOS and Android apps, from design to store launch.
UI/UX Design
Research, wireframes, prototypes and interfaces.
Pitch Deck Design
Investor decks with a clear story and clean data.
Analytics & Reporting
GA4, Tag Manager and dashboards you can trust.
Keep reading
Talk it through with us.
Tell us what you need. You get an honest assessment, a clear plan and a written quote. The first consultation is always free.
- What happens next
- 1You tell us what you need
- 2We aim to reply within 24 hours with questions
- 3You get a written quote for your project