An MVP that proves something, not one that impresses
You get one workflow shipped properly, with real accounts and real payments, so what you learn from it is worth acting on and the code is worth keeping.
An MVP has one job: answer the question that decides whether the company is real. Not whether people like the idea, but whether they will sign up, do the work, and pay. That means the smallest product that can produce a genuine yes or no, built well enough that a yes does not force a rewrite. Most MVPs fail the second half. They demo beautifully, get funded, and then the team spends its first two quarters replacing everything.
The prototype that becomes the product by accident
Nobody plans to keep the prototype. It ships to five friendly users, then to fifty, then a customer pays, and suddenly it is production. The shortcuts that were fine at five users are now load-bearing.
The usual ones: everyone shares a database with no separation, and passwords were never hashed properly. Nobody can see what a user did last Tuesday. Each is cheap to do at the start and expensive to retrofit after real customers exist.
The other failure is the opposite. Six months building features nobody asked for, because scoping an MVP means deciding what to leave out, and leaving things out feels like losing.
What is running now
Counted, not estimated
22
systems in production
38
countries where Broollie is used
10
players Elevent runs from, scaling past 1,000
4
user roles TrialTriage separated from day one
What goes in the first version
Short list on purpose. Everything here exists to make the answer trustworthy.
The one workflow that makes someone want to pay you.
Real accounts, with the permission model decided now rather than retrofitted.
Real payments, because intent to pay and actually paying are different data.
Enough tracking to tell activity apart from curiosity.
A stack your next engineer can read, so hiring does not restart the build.
What waits
- Admin tooling you can do by hand for the first fifty customers.
- Every settings screen. Nobody churned over a settings screen.
- The second customer type. Prove the first one first.
- ScopeFree call. What must be true?
- CutThe one workflow. Everything else waits.
- BuildAccounts, payments, the core loop.
- ShipReal users, real money, real data.
- DecideKeep going, change it, or stop.
Decide is a real node, not a formality. An MVP that cannot produce a no was never a test, and the honest version of this work includes helping you read a no.
Which shortcuts you are allowed to take
Speed comes from cutting scope, not from cutting quality in the places that are expensive to fix. Those are different decisions and founders often make the wrong trade.
Skip the admin dashboard and do it by hand. Skip the second user type. Do not skip how accounts are separated, how money is recorded, or whether you can see what happened. Golancer was built on Bubble so the founder could change the product directly, and that was the right call for that business. It was a scope decision, made in the open.
- Cut features freely. Cut auth, tenancy or payment records, and you pay for it with real customers watching.
- No-code is a legitimate choice when the founder needs to iterate without an engineer.
- Money never gets stored as a floating-point number, even in version one.
- The data model gets ten minutes of care now, because it is the hardest thing to change later.
What we build MVPs on
Product
Backend and data
No-code, where it fits
Ship and run
First versions that turned into businesses
“Their attention to detail, quality of employees, and work ethic were outstanding.”
Nicolas de Quesada · CEO, Lexpair
The usual MVP against ours
Both put something in front of users. They differ in what happens if it works.
| Criterion | The usual approach | How we build |
|---|---|---|
| What gets cut | Quality, because features are what the deck promised. | Features. Auth, tenancy and payment records stay correct. |
| If it succeeds | The first two quarters go on a rewrite. | You keep building on the same codebase. |
| Payments | A waiting list, treated as demand. | Real charges, because paying and intending to pay differ. |
| Who builds it | Juniors, because it is only an MVP. | The same senior engineers who ship our production work. |
| Ownership | The agency's accounts and repositories. | Yours from day one, so a due diligence review finds nothing odd. |
01What belongs in an MVP and what does not?
One workflow that makes someone want to pay, plus accounts and payments that work for real. Everything else waits, including the admin dashboard, which you can run by hand for the first fifty customers. The test for any feature is simple: if it is missing, does the experiment still produce a trustworthy yes or no?
02Will we have to rebuild the MVP if it works?
Not if the expensive things were done correctly the first time. Rewrites are usually forced by three decisions: how accounts are separated, how money is recorded, and the shape of the data model. We get those right in version one and cut features instead, because features are cheap to add later.
03Is no-code a reasonable choice for a first version?
Yes, when the founder needs to change the product without booking an engineer. Golancer runs on Bubble for exactly that reason, and PremiumAudit.io went to production on Bubble with Claude behind it. No-code costs you at high volume and at unusual integrations, so we say up front which limit you are likely to meet.
04Should we charge users during the MVP?
Charge them, unless a legal or regulatory reason stops you. A signup is an opinion and a payment is a decision, and only one of them predicts a business. Stripe is in most of our builds for this reason, and turning it on early changes what your data means.
05Do we own the code, or does the agency?
You own all of it, in your repositories and your cloud accounts, from the first commit. This matters more than founders expect. An investor's technical reviewer will ask, and an answer involving the agency's accounts costs you weeks.
06How do we know when to stop building and change direction?
Decide the number before you launch, not after you see the result. Pick the behaviour that means it works, such as users returning in week two. Then agree in advance what result would make you stop. Founders who set that line afterwards almost always move it.
07How much does MVP development cost?
Cost is driven by how many user types the first version needs, whether money moves through it, and how many outside systems it touches. A single-role product with Stripe is straightforward work. A marketplace with held payments and dispute handling, like WorkMateAI, is not, and the drivers get named on the free scoping call.
08Can an enterprise team use this for a new product line?
Yes, and it is a common shape. An internal product has to pass security review and connect to systems that already exist. So the permission model matters from the first sprint. The scoping discipline is identical, and so is the rule that features get cut before quality does.
Related
- Web app development →What the MVP grows into.
- Custom software development →The full build, once the answer is yes.
- Build vs buy software →Whether you need to build anything at all.
- Supabase vs Firebase →The backend choice most first versions face.
- Why you never use floats for money →The version-one mistake that surfaces in year two.
