MVP development
MVP development for two-sided products
An MVP is not a cheaper version of the full product. It is the smallest thing that answers the question you are actually unsure about – and for two-sided products, that question is almost never the feature list.
- products shipped
- 20+products shipped
- industry niches
- 4industry niches
- years building
- 4years building
Most MVPs test the wrong thing.
Teams build a thin version of every feature and launch it. What comes back is a vague signal: some signups, little usage, no clarity on why. The scope was decided by what was easy to cut rather than by what was genuinely uncertain.
For a two-sided product the uncertainty is nearly always on one side. Can we get supply without demand. Will anyone verify themselves before there is anything to transact. Will the second side come back a week later. A good MVP is shaped around that question and ruthless about everything else.
We also take the opposite position often enough to mention it: sometimes the first version should not be software. A spreadsheet, a group chat and a person doing the matching by hand will answer the question faster and cheaper, and we will tell you when that is the case.
What we mean by an MVP
Narrow in scope, not sloppy in construction.
One question, defined up front
We write down what this version is supposed to prove and what result would count as a no. Scope arguments later resolve against that sentence.
One side done properly
Usually the harder side gets a real experience and the other gets the minimum that makes a transaction possible. Splitting effort evenly is how both sides end up unusable.
Real trust mechanics, minimal version
The weakest verification your category tolerates, and a manual process behind it where automation is not worth building yet.
Manual where manual is cheaper
Matching, approvals and payouts can run through an admin panel and a human for the first months. We build the panel, not the automation.
Instrumentation from day one
Events that answer the question, not a dashboard of vanity metrics. If the MVP cannot tell you why it failed, it has failed twice.
Architecture you can keep
Clean, tested, documented code in your repositories. Narrow scope is a product decision, not an excuse for a codebase the next developer has to delete.
How the build runs
Eight to twelve weeks from first call to real users, when the scope holds.
- 01
Define the question
Ninety minutes to agree what this version has to prove and which side carries the risk. Half of what was in the brief usually leaves at this point.
Week 0 - 02
Flows before pixels
Only the paths that serve the question, drawn end to end, including the empty states that dominate the first weeks.
1-2 weeks - 03
Build in one-week sprints
Working software from sprint one, demo every week, and scope traded openly against the deadline rather than quietly against quality.
6-10 weeks - 04
Launch and read the answer
Instrumented launch, then a session on what the data says: continue, change shape, or stop. Stopping is a legitimate outcome and we will say it out loud.
Ongoing
First versions that turned into products
Each started narrow and kept its codebase.
What we build it with
The same stack as our full builds – an MVP is not a reason to pick throwaway tools.
Product
- Next.js
- React
- TypeScript
- React Native
Services
- Node.js
- NestJS
- PostgreSQL
- MongoDB
Operations
- AWS
- CI/CD
- Analytics
- Error tracking
Questions we get before an MVP build
Eight to twelve weeks for a two-sided product where the scope holds. The variable is not our speed, it is how quickly the question gets defined and how firmly the scope stays closed once it is.
Scope discipline, mostly. After that: how much verification and money movement the first version genuinely needs, whether one or both sides need a real experience, and whether a native app is required at launch. We write out what is in and what is not before you sign.
For prototypes and internal tools, often yes. For a product that handles other people's money and identity, the audits we run on AI-assisted builds usually find the same gaps: no permission model, no admin tooling, and data models that cannot support the second feature. We wrote up what the rebuild actually costs.
Not if it is built properly. Narrow scope is a product decision, not a licence to write code nobody can extend. Several of our MVPs are still the same codebase two years on.
Then it did its job for a fraction of the cost of finding out later. We would rather be the studio that told you on week ten than the one that kept billing until month twenty.
Sometimes, as part of a partnership rather than a standard contract. There is a separate page on how that works.
Tell us what you are unsure about. Thirty minutes, no pitch. If the fastest way to answer it is not software, we will say that first.
Book a callWorth reading before you brief anyone
On scope, quotes and what a first version should actually cost.
The real cost of vibe-coded platforms
We audit vibe-coded marketplaces. Here's what the rebuild actually costs. A founder came to us last year with a working marketplace. Two sides, listings, search, sign-up, a functioning checkout. Buil…
8 minWhy your website quote ranges from €2.5k to €25k
You wrote to three studios with the same idea. One came back at €2,500, one at €10,000, one at €25,000. The natural conclusion is that someone is overcharging. Usually nobody is. The three studios ha…
6 minThe Day-One Question That Kills Most Marketplaces
Most product decisions can be reversed. You can change the pricing, redesign the onboarding, rewrite the backend if you have to. There's one decision that can't be fixed later, and almost nobody make…
7 min