MVP: How to build the Minimum Viable Product without waste — Operational guide for startups and SMEs

You have a brilliant idea. You're ready to develop. Maybe you've already contacted a team of developers to build the full version of your product. Stop. 90% of startups fail, and the main reason is not competition or funding: it's building something nobody wants. We see it every day in projects that land on our table: an e-commerce with a thousand features before even getting the first order, an app with authentication, notifications, chat and payments integrated before a single user opens it. This is not development: this is waste.

At Meteora Web, we started like many: passion, code, but also plenty of mistakes. From there we learned that a product is not valuable for its features, but for the problems it solves. And to find out if it really solves a problem, you need the Minimum Viable Product, the MVP. It's not a beta, not a rough prototype: it's the smallest version of your product that can generate validated learning.

This guide is for those who want to build an MVP without wasting time, money and developer goodwill. Let's start with a fact: a well-done MVP costs on average 80% less than a full version, and allows you to collect real data in weeks instead of months. If you are a startup or an SME thinking of launching a new digital service, this is your map to avoid mistakes.

What an MVP really is (and what it is not)

The most cited definition comes from Eric Ries: "that version of the product that enables the Build-Measure-Learn cycle with the least effort and the maximum learning". But in practice, we confuse MVP with other concepts.

MVP ≠ prototype

A prototype is a visual representation, a mockup. It does not produce real learning about product usage. The MVP is working, even if rudimentary.

MVP ≠ beta version

A beta is a nearly finished product tested for bugs. The MVP is tested to validate business hypotheses. Missing features are not bugs: they are deliberate choices not to build uselessness.

MVP ≠ minimal product

Attention: "minimum" does not mean "small". It means essential to test the core hypothesis. If your idea is a food ordering app, the MVP could be a WhatsApp number where users order manually. Sounds ridiculous? It works. And costs zero development.

At Meteora Web, we built a platform for managing client social media starting from an MVP: a shared Google Sheet where clients wrote their posts and we published them manually. It allowed us to validate demand, understand real needs (invoicing, calendar, multi-account) and only then develop a proprietary platform. If we had spent 6 months building the full app, we would have failed because the real need was different from what we imagined.

The Build-Measure-Learn cycle applied to MVP

Every MVP is an experiment. The cycle is simple:

1. Build: build the minimum version that lets you test the hypothesis.
2. Measure: collect real data (not opinions) on how users interact.
3. Learn: decide whether to persevere (pivot) or change direction.

The trick is to make the cycle as short as possible. Every day spent building unvalidated features is a day lost. A good MVP should be ready in 2-4 weeks for a simple digital product, max 8 for a complex SaaS.

Practical example: landing page as MVP

The classic case: you have the idea of an online course. Instead of creating the entire platform, create a landing page with:

• Title, description, price
• Button "Sign up now" leading to a payment page (or a pre-order form)
• Google Analytics and Facebook Pixel to track conversions

If 100 people visit and 0 buy, you have learned something without writing a line of e-learning code. Then you can interview those who didn't buy to understand why. This is the MVP: an HTML page and an email form may be enough.

How to identify the essential features of the MVP

The right question is not "what can we cut?" but "what is the riskiest hypothesis we need to validate?". To answer, we use the Value Proposition Canvas and the Priority Matrix.

Step 1: Define the core hypothesis

Example: "Professionals need an app to book video consultations quickly." Core hypothesis: speed and simplicity of booking are the real value. The MVP must test exactly that: no chat, no automatic invoicing, no history of sessions. Just a shared calendar and a Google Meet link.

Step 2: Interview potential users (but beware of lies)

Don't ask "Would you buy this product?" because the answer will almost always be yes. Ask: "What is your biggest problem right now? How do you solve it?". Observe behavior. If they say they use an Excel sheet to keep track of consultations, you have a strong signal.

Step 3: Use the MoSCoW technique

• Must have: indispensable to test the hypothesis
• Should have: important but not essential
• Could have: nice to have
• Won't have: explicitly exclude

For the MVP, focus only on Must have. Everything else is waste.

Tools to build an MVP without writing code

Today there are hundreds of no-code/low-code tools that allow you to assemble an MVP in days. We use them often to validate ideas before investing in custom development.

Category	Tool	Why use it
Landing page	Webflow / Carrd / Unbounce	Create pages without a developer, integrated with email marketing and payments.
Backend / CRM	Airtable + N8N	Simulate a backend: manage leads, orders, bookings with connected sheets.
Interactive prototype	Figma + Prototyping / Bubble	For complex products, Bubble allows you to create full web apps without code.
Automation	Zapier / Make	Connect tools together (e.g. new lead → Slack notification → confirmation email).
Bookings	Calendly / YouCanBook.me	MVP for consulting services, meetings, events.
Payments	Stripe / PayPal / Paddle	Accept payments immediately without developing a custom checkout.

Practical example: you want to launch a subscription service for local product boxes. Instead of developing a custom e-commerce platform, create a landing page with Carrd, integrate Stripe for payments, and manage orders with a shared Airtable with the supplier. All in one week. If the market responds, then invest in a real e-commerce. This is building without waste.

How to measure the success of your MVP

It's not enough to launch. You must know exactly what to measure to decide whether the hypothesis is valid. We define learning metrics vs vanity metrics.

Vanity metrics to avoid

• Number of downloads/app install (if no one opens the app after)
• Page views (if they don't generate action)
• Likes or followers
• Registered users (if they don't return or pay)

Learning metrics to monitor

• Conversion rate: percentage of visitors who complete the key action (signup, purchase, booking)
• Retention rate: how many users return after the first interaction
• Revenue per user: even if small, it's a validation signal
• Net Promoter Score (NPS): ask users if they would recommend the product
• Time to complete a task: if users take longer than expected, there's a usability issue

Practical tools: Google Analytics 4 for events, Hotjar for session recording, Typeform for surveys. At Meteora Web, we always set up tracking before launch: without pixels and tag managers, you have no data, just assumptions.

Code example: tracking a signup with GA4 via PHP

Suppose your MVP is a landing page with a newsletter signup form. You want to track the signup event in GA4 to measure conversions. Here's a simple PHP snippet that sends an event via the Measurement Protocol (server-side, useful if the form is static and you don't want to expose JavaScript).

<?php
// Configuration
$measurement_id = 'G-XXXXXXXXXX'; // Replace with your GA4 ID
$api_secret = 'XXXXXXXXXXXXXXXX'; // Generate from GA4 admin: Admin > Data Streams > Measurement Protocol API secret

$client_id = uniqid('', true); // Or use a cookie to associate sessions

$data = [
    'client_id' => $client_id,
    'events' => [
        [
            'name' => 'signup',
            'params' => [
                'method' => 'landing_page',
                'source' => $_SERVER['HTTP_REFERER'] ?? 'direct'
            ]
        ]
    ]
];

$url = "https://www.google-analytics.com/mp/collect?measurement_id=$measurement_id&api_secret=$api_secret";

$ch = curl_init($url);
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, json_encode($data));
curl_setopt($ch, CURLOPT_HTTPHEADER, ['Content-Type: application/json']);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
curl_close($ch);

// Redirect or show a message
header('Location: thanks.html');
exit;
?>

This script sends a signup event to GA4 every time someone signs up. You can see conversions in real-time in the GA4 report. No plugins, no complexity.

Common mistakes in building the MVP (and how to avoid them)

In our 8 years working with startups and SMEs, we've seen the same mistakes over and over. Here they are, with the solutions we adopt.

1. Adding too many features "just in case"

Fear that the product won't be enough for users. Solution: apply the 48-hour rule: if a feature is not essential to test the hypothesis, don't write a single line of code.

2. Developing for imaginary users instead of real ones

Build for your first paying customer, not for the millions to come. Solution: find 5-10 potential customers before starting development. Get a pre-order (even symbolic). If you can't find anyone willing to pay, the MVP will save you months.

3. Not defining success metrics before launch

You launch without knowing what "success" means. Solution: set a minimum threshold: e.g., if after 4 weeks you don't have at least 20 signups with a 2% conversion rate, pivot.

4. Ignoring the distribution part

An MVP is useless if no one sees it. Solution: plan an acquisition channel (ads, organic social, referral, partnerships) from day one. Never launch a product without knowing how to reach your users.

5. Not iterating quickly on feedback

You launch the MVP, collect feedback, but take months to make changes. Solution: dedicate the first weeks post-launch only to responding to the most critical feedback. At Meteora Web, in the early months of a new product, we reserve at least 2 days a week for quick interventions.

From MVP to real product: when to move to the full version

The MVP is not the final destination. It's the vehicle to understand whether to proceed. The transition to the full product happens when:

• You have validated the core hypothesis (e.g., people pay for your service)
• You have collected enough feedback to prioritize the next features
• The business model is sustainable (acquisition costs lower than LTV)
• The current MVP is becoming a bottleneck for growth (too many errors, impossible to scale)

Caution: moving to a "full" product does not mean adding everything you have in mind. You move from an MVP to an MVP+, a product that continues to evolve step by step, always testing each new feature. We call it "perpetual iteration".

In summary — what to do now

Here are the concrete actions you can take immediately, without waiting:

1. Write down the core hypothesis of your product on a sheet. One sentence: "I believe that [target] needs [solution] because [problem]".
2. Identify the 3 MUST HAVE features to test that hypothesis. Everything else is waste.
3. Build the MVP in 2 weeks using no-code tools or a landing page. If you need code, use lightweight frameworks (Laravel for backend, Vue for frontend) but only for the bare minimum.
4. Set up tracking before launch: GA4, pixel, hotjar. Without data, you don't learn.
5. Launch and measure for 4 weeks. If the key metric does not reach the minimum threshold, prepare to pivot. If it exceeds, start iterating.

We at Meteora Web have helped dozens of clients avoid the classic "big bang" failure. If you have an idea and want to validate it without wasting budget, let's build your MVP together — starting from cost accounting, because we come from that background. A website or an app is measured in revenue, not compliments.

For the complete framework, read our Pillar Guide to Product Management.

External reference: The Lean Startup – Eric Ries