At ten in the evening, a food business owner in Bandar Lampung closed his laptop with mixed feelings. Six months and Rp 180 million had gone into what he called a "complete" delivery app: digital menu, payment system, loyalty points, promo notifications, even a chat feature with couriers. Reality hit when the app finally launched and only 40 people signed up in the first week. Of those 40, only 5 ordered more than once. He had built the perfect app for a problem that may not have existed.
This story is not about a failed investment. It is about the order of operations being backwards. He built the final version of the product before proving that anyone wanted to use it — the most expensive mistake in product development, and the easiest to avoid with one simple discipline: the minimum viable product, or MVP.
This article is an MVP guide written for everyone: what an MVP actually is, which features belong in the first version, what it realistically costs in Indonesia, and how to measure it so your business decisions run on facts instead of assumptions.
What an MVP Actually Is
The minimum viable product is often misunderstood as "a half-finished product" or "a cheap app as long as it works." Both are wrong.
An MVP is the simplest version of your product that can still test your business assumptions with real users. Three words in that definition matter.
Minimum means as few features as possible. Viable means still viable: good enough to use and delivering real value. Product means something people actually use — not a proposal, not a mockup, not a pitch deck.
The goal of an MVP is not to make lots of money on day one. Its single goal is to learn as fast and as cheaply as possible: whether people actually have the problem you suspect, whether they understand your solution, and whether they are willing to pay for it or invest their time in it.
Eric Ries, author of The Lean Startup, who popularized the concept, calls the cycle build-measure-learn: build as little as possible, measure the market's reaction, then learn and decide direction. An MVP is not the finish line; it is a measuring instrument.
Why Indonesian Businesses Need to Know About MVPs
Indonesia's market has characteristics that make the MVP even more relevant, not less.
First, development costs here are indeed cheaper than in developed countries, but they are still not small numbers. A mid-range mobile app in Indonesia typically costs tens to hundreds of millions of rupiah, and enterprise apps go far higher. We break down the ranges in our article on app development costs. When costs run this high, building features nobody asked for is waste that cannot be excused with "at least it's complete."
Second, Indonesian user behavior changes fast. Digital payment patterns, online shopping habits, and app preferences shift within years. An assumption that made sense last year may not hold this year. An MVP lets you test assumptions against fresh data, not old beliefs.
Third, competition in many sectors is already dense. In a crowded market, learning speed often beats product perfection. Players who test quickly and pivot quickly usually overtake players who spend months building a perfect version nobody was looking for. For SMEs just starting to go digital, an MVP can also be a healthy entry point: testing one new service without overhauling the whole operation at once. The step-by-step digitization roadmap for small businesses is in our article on digital transformation for Indonesian SMEs.
Which Features Go into an MVP: How to Choose Without Getting Lost
The most common question: "How do I know which features go into the first version?" The answer starts with one thing: identify your business's riskiest assumption.
The riskiest assumption is not "do customers like the button color." It is the question that makes or breaks your business:
- Will people order food through an app instead of by phone?
- Will small shops pay a subscription for a cashier app?
- Will technicians report their work daily through their phones?
Every product has one or two assumptions that truly decide its fate. Identify those, then design an MVP that only tests those assumptions. Features that do not support the test — however attractive — get postponed.
Once the assumption is clear, filter features through three screens:
1. Is this feature required for the user's core job to get done? If users get zero value without it, it stays. If it is merely a nice-to-have, it goes.
2. Does this feature help measure your assumption? Features that generate test data rank first. Features that are merely "good to have" wait.
3. Can this feature be skipped with manual work? Many wise MVPs deliberately run part of the process manually behind the scenes. An online store can accept orders through a simple form and process them by hand in a spreadsheet, while testing whether people will order at all. Automation can come later, once demand is proven.
A Practical Exercise: The Four Quadrants
A simple way to evaluate your feature list: draw a table with two columns. Left: "needed for core value." Right: "supplementary." Top row: "supports assumption testing." Bottom row: "does not support."
- Top-left box: goes into the MVP without debate.
- Bottom-left and top-right boxes: consider them, usually for the next version.
- Bottom-right box: do not build until there is evidence someone wants it.
This exercise takes under an hour, and the result saves months of work.
Three Kinds of MVPs: Pick the One That Fits
Many people imagine an MVP must be an app. In reality, an app is just one form of MVP — and often not the fastest or cheapest.
1. The Concierge MVP
You run the service manually for your first users, pretending a system exists behind the scenes. Example: before building a home-cleaning service app, you accept orders over WhatsApp, schedule cleaners by hand, and collect payments via bank transfer. Users experience a complete service; you learn whether they will use and pay for it.
Pros: near-zero cost, maximum learning. Cons: it does not test whether automating the service is economically viable. For testing demand and willingness to pay, a concierge MVP is an outstanding starting point.
2. The Wizard of Oz MVP
Similar to concierge, but users believe they are interacting with a system. You provide an interface, then humans behind the curtain run it. A classic example: an app that appears to automatically calculate delivery routes, while in reality a person finds routes on Google Maps and sends the results by message.
Pros: tests the real interface and process without system development costs. Cons: manual work that cannot last forever, and an ethical boundary — make sure you are not deceiving customers in ways that harm them.
3. The Simple Product MVP
The most common form: a simple app or system built with core features only. This is the right choice when the product's value genuinely depends on the system existing — for example, a cashier app, a marketplace platform, or an inventory management system.
Pros: tests the real product with the real flow. Cons: the highest cost and longest time of the three. So before choosing this path, ask: is there a manual way to test the same assumption?
Many teams start with concierge and move to a product after demand is proven. This sequence cuts risk dramatically: you only build the system once you know people want it.
Realistic MVP Budgets in Indonesia
What does an MVP cost in the Indonesian market? The honest answer: it depends on complexity, but there are benchmark ranges.
| MVP type | Estimated cost | Timeline |
|---|---|---|
| Concierge (manual) | Rp 0-1 million (operational costs only) | 2-6 weeks |
| Landing page + form | Rp 2-8 million | 1-3 weeks |
| Simple web MVP (1-3 core features) | Rp 15-50 million | 1-3 months |
| Mobile app MVP | Rp 40-120 million | 2-4 months |
| Internal/enterprise system MVP | Rp 50-150 million | 2-5 months |
These figures are Indonesian market estimates, not fixed prices. The pattern to read: a wise MVP does not have to be expensive. If your assumption can be tested with a landing page and a form, spending Rp 100 million on an app is pure waste.
One budgeting principle: decide first how much risk you are willing to absorb if the assumption turns out wrong. A good MVP is designed so failure does not consume your capital — a cheap failure is a hidden success, because you learned before it was too late.
How to Measure an MVP: Metrics That Matter and Metrics That Lie
An MVP without measurement is just a regular project. But the wrong metrics are more dangerous than no measurement at all, because they create false confidence.
Misleading Metrics
Download or signup counts. The most boasted-about and most deceptive number. A thousand downloads that never return is zero learning. Downloads measure marketing, not product value.
Total active users. Hard to read without context. What matters is not how many tried, but how many came back and how often.
Metrics That Mean Something
Activation. The percentage of users who reach the product's core value moment — placing their first order, generating their first report, or completing their first transaction. This is the first metric that must rise.
Retention. The percentage of users who return within a week, two weeks, a month. Retention is the most honest signal that the product delivers ongoing value. A product used twice and then forgotten has failed, whatever its signup count.
Willingness to pay. The percentage of users who actually pay, or at least state they would pay at a given price. This is the hardest test of your business assumption, and the most often avoided because the answer can be uncomfortable.
Referrals. How many users recommend the product to others. Organic referrals are proof of value that cannot be bought.
Set one primary metric before the MVP launches, and agree on the threshold up front: what activation rate counts as success, what retention is enough. Without a threshold, any result can be interpreted however you like.
Mistakes That Kill MVPs
Failed MVPs rarely fail because of technology. They fail because of one of four mistakes.
1. An MVP that is not actually minimum. The team adds "one more small feature" repeatedly until what launches is not an MVP but a full product a year late. Every added feature delays the most important lesson: whether the core assumption is true.
2. Measuring the wrong thing. Launching with a target of "10,000 downloads" when the business assumption is "people will pay a subscription." Downloads soar, the team celebrates, then payments are zero and the project dies in confusion.
3. Over-engineering. Building an app to test an assumption that could have been tested with a landing page and WhatsApp. Triple the cost, double the time, and the same learning.
4. Not ready to pivot. Already in love with the solution, so contradicting data gets ignored and the MVP is forced forward on belief instead of evidence. A good MVP demands the courage to hear "no" and change direction.
Famous MVPs: Lessons from Well-Known Products
Some of the world's most successful products were born from humble beginnings, and the pattern is worth studying.
Airbnb started by renting out three air mattresses in the founders' apartment to conference attendees in San Francisco — a pure concierge MVP. No platform, no payment system, just a simple page and manual communication. What was tested: would people stay in a stranger's home, and would hosts accept guests? The answer was yes, and from there a giant platform was built.
Dropbox tested market interest with a three-minute video demonstrating how the product would work — before the product itself fully functioned. The video went viral and added massive numbers to the waiting list overnight. The test cost: time to record a video, not months of development.
The lesson from both is identical: they tested their riskiest assumption in the cheapest way imaginable, and measured market response — not internal enthusiasm — before building at scale.
When to Scale Up After the MVP Works
A successful MVP is marked by one thing: your primary metric crosses the agreed threshold. Now the next question appears: what should be built after?
Post-MVP development priorities follow data, not feelings. The order:
- Fix leaks in the core flow. If users drop off mid-order, that is problem number one, whatever new features you daydream about.
- Automate the parts that have proven viable but are still manual. If the concierge approach showed demand, it is time for the system to replace manual work.
- Build the features real users request most.
- Only then, build differentiators to compete. When the MVP-built system is genuinely in use and needs grow more complex, you face the next decision: building custom or adopting packaged software. We compare both paths in detail in our article on custom vs packaged software.
Along the way, keep the same discipline as the MVP: measure, learn, decide. A product that keeps moving without measurement reverts to the old pattern: building lots, proving little.
MVP Myths That Need Correcting
"MVP means low quality"
Wrong. MVP means small scope, not sloppiness. A simple product that works reliably beats a complete product that crashes often. Your first users are your most valuable learning asset; disappointing them with avoidable bugs is waste.
"MVPs are only for startups"
The concept applies just as much to established companies. Adding a new service, entering a new market, or replacing an internal system? Test the small version first. Large companies need MVPs even more, because their failures scale bigger.
"If the MVP works, the product will automatically sell"
An MVP proves assumptions, not guaranteed success. After evidence of demand exists, you still need marketing, operations, and competition. An MVP is only a correct beginning, not a promise of a bright ending.
"Better late but complete"
If you are late and your assumption was wrong, what you own is a complete product nobody wants. The correct order: prove first, complete later.
Frequently Asked Questions
How long does it take to build an MVP?
It depends on the type: a landing page and form can be done in 1-3 weeks, a simple web MVP in 1-3 months, and a mobile app MVP in 2-4 months. What to remember: MVP time is not time spent waiting for perfection; it is time spent waiting for the market's answer. If the answer can be obtained faster with a simpler method, use that method.
Is an MVP suitable for existing businesses, not just startups?
Very much so, and it is actually safer. Established companies have more at stake, so testing a new service or feature on a small scale before a large investment is wiser than launching at full scale immediately.
What if my MVP fails?
That is not failure; it is data. A well-designed MVP makes failure cheap: you learn which assumption was wrong before spending big capital. The next question is not "why did it fail," but "what can be fixed, and are the remaining assumptions still worth testing."
Who should build the MVP — an internal team or a vendor?
Both can, but for an MVP, speed and cost usually matter more than long-term ownership. Many businesses choose a vendor for the MVP because they can start quickly and stop anytime, then move development in-house once the product is proven. We compare both paths in full in our article on outsourcing vs in-house development.
Your First Steps This Week
You do not need to wait until your business plan is perfect to start an MVP. Three steps are enough:
- Write down your riskiest assumption in one clear sentence. "People will order car wash services through an app at a premium price" — one sentence, testable, falsifiable.
- Choose the cheapest test method that can test it: conversations with potential users, a landing page, or a manual service over WhatsApp.
- Set the success threshold and deadline. For example: 50 orders within a month, or 20 percent of landing page visitors signing up.
Once the threshold is reached or missed, you have data for the next decision — worth far more than belief without evidence.
If you want to test a product idea the right way without burning your budget, the Kartech team in Bandar Lampung can help design a fitting MVP: mapping your business assumptions, selecting core features, and building the simplest version that genuinely tests the market — following our Frame, Shape, Build, Operate process. See our services, or reach us through the contact page to start from your business problem.
