Every few months an owner sits across from me with a detailed spec for a system that will take six months and several hundred million rupiah to build. Member accounts, admin dashboard, reporting module, mobile app, loyalty points, the works. My first question is always the same: which single part of this, if it fails, kills the whole idea? Build that part first. Skip the rest.
That is the entire philosophy behind a minimum viable product, and it is widely misunderstood. Most people hear MVP and think "a smaller, cheaper version of my product." That framing quietly ruins projects. A minimum viable product is not a small product. It is an experiment dressed up as a product, and its job is to answer one question: will anyone actually use this?
If you are about to commission a serious software build, this distinction is worth more than any technology decision you will make. Here is how to apply it.
An MVP Is a Question, Not a Product
A product tries to serve customers. An experiment tries to produce an answer. Confuse the two and you end up "trimming" a six-month build into a four-month build, which tests nothing and just delivers less.
Start by writing down your riskiest assumption as a plain sentence:
- "Restaurant owners will pay monthly for automated stock alerts."
- "Our wholesale customers will place orders through an app instead of WhatsApp."
- "Parents will book tutors online without talking to a human first."
Your MVP is whatever the cheapest, fastest thing is that gets a real yes or no on that sentence. Everything that does not serve the answer gets cut, no matter how obviously the "full product" will need it. Login systems, admin panels, settings pages, reporting: almost never needed for the answer. They feel like progress because they are familiar, but they are the most expensive way ever invented to avoid finding out whether anyone cares.
The Six-Month Build That Became a Six-Week Test
A concrete example, anonymized. A distribution company wanted a B2B ordering portal for their roughly 300 retail customers. The initial spec: customer accounts, full catalog with live stock, credit limit checks, promo engine, delivery scheduling, and an admin back office. Honest estimate: six months, around Rp 400 million.
The riskiest assumption was buried under all of that: would their retail customers, who had ordered by phone and WhatsApp for fifteen years, change their behavior at all?
So the MVP became this. A simple mobile-friendly catalog page, no login, showing the 50 best-selling SKUs with prices per customer tier. An order form that submitted to a Google Sheet. An admin who manually confirmed each order by WhatsApp, checked credit limits by eye, and keyed the order into the existing system. We invited 25 of their friendliest customers.
Six weeks and a fraction of the budget later, we had our answer, and it was more interesting than yes or no. Customers happily browsed the catalog and checked prices, but two thirds still finalized the order over WhatsApp. The behavior we needed to build for was "catalog online, transaction in chat," not a full self-service portal. The eventual real build looked very different from the original spec, cost less than half, and got used. The six-month version would have shipped beautifully into silence.
Sometimes the MVP Has No Code at All
The version of this that surprises owners most is the concierge MVP: you deliver the service manually, by hand, behind a thin front.
Want to test a meal-plan subscription service? Do not build the subscription platform. Make an Instagram page and a Google Form, take payments by transfer, and cook for your first ten customers yourself. Want to test an automated invoice-reminder tool? Offer to run it manually for five businesses using their data and a spreadsheet. If they will not accept it free with a human doing the work, they will never pay for the software version.
Concierge MVPs feel like cheating. They are the opposite. They put you in direct contact with real customer behavior weeks before a developer writes a line of code, and every hour of manual work teaches you what the software must actually do. Several features in the "obvious" spec usually die quietly during this phase because no customer ever asks for them.
Scoping Rules That Keep an MVP Honest
When you do build software for the test, a few rules keep it minimal:
- One user type. Build for the customer or the staff, not both. The other side works manually for now.
- One core flow, end to end. A user can complete the single action that matters. Nothing else needs to work.
- Manual behind the curtain is fine. Notifications sent by a human, orders processed by hand, reports assembled in Excel. Automate only what breaks at your test volume.
- Six weeks or less of build time. If the MVP needs more, your question is too big. Split it.
- Decide the pass mark before launch. "At least 10 of 25 invited customers place a second order within a month." Without a number written down in advance, every result gets rationalized as encouraging.
And yes, version one should embarrass you a little. If you are completely proud of your MVP, you polished things the experiment did not need and paid for that polish with time and money. Ugly but honest beats beautiful but unread.
What to Do With the Answer
Three outcomes, three moves.
Clear yes. Usage hits your pass mark, people complain when the manual parts are slow. Now, and only now, does the bigger build make sense, and you will scope it far better because real behavior has replaced guesses. This is the point where a proper written spec earns its keep; see How to Write a Software Brief Developers Won't Misread.
Clear no. Nobody used it despite genuine invitations. Painful, but you just bought that lesson for 10 or 15 percent of the full-build price. Kill it or pivot the question. Do not "add features and try again" without a new hypothesis about why behavior will change.
Messy middle. Some usage, wrong shape, like my distribution client. This is actually the most common and most valuable outcome. The MVP did its job: it redirected the real investment toward what customers demonstrably do.
Whatever the result, resist the sunk-cost pull. The MVP was the cost of the answer. Treat the code as disposable, because it often is.
The Practical Takeaway
Before you sign off on any large software build, run this checklist. Write your riskiest assumption as one sentence. Design the cheapest test that gets a real yes or no, and check whether a concierge version needs code at all. Cap the build at six weeks and one core flow. Set a numeric pass mark before launch. Then let the result, not the original spec, decide what gets built next.
The empire might still get built. But it gets built on evidence, and it usually looks different, and cheaper, than the spec you started with. If you want a second pair of eyes on whether your project is at the test stage or the build stage, that is exactly the kind of conversation I have with partners before any large engagement, and it fits inside a broader plan rather than a one-off build; more on that in Why Your Business Needs a Technology Strategy, Not Just a Website.