Guide · Marketplaces & consumer apps

Marketplace MVP: the 4 apps you think you need vs the 1.5 you actually need

A two-sided marketplace MVP needs one real app and half an admin panel, not four apps. What to keep, fake and cut, from someone who built all four.

By Akash Bansal, founding engineerUpdated 4 November 20267 min read

A marketplace founder's first spec usually lists four apps: one for customers, one for suppliers, an admin console and a website. I have built all four for a real marketplace. At Urban Culture, an at-home salon marketplace where I was head of technology from 2020 to 2025, we ran a customer app, a partner app, an admin console and a web app, and grew to 500K registered users across six cities.

Every one of those apps earned its place eventually. My argument here is about order, not about whether they should exist. A marketplace MVP needs about 1.5 apps. The rest is paid for three times if you build it early: once to build, once to test, and then forever as something that breaks.

What does a marketplace MVP actually need?

A marketplace MVP needs one transaction loop that works end to end: a buyer finds something, pays, a supplier delivers it, the supplier gets paid, and you can see and fix every step. Anything that does not sit on that loop is a candidate for cutting.

That loop is the product. Search filters, reviews, chat, wallets and recommendation engines make a working loop better. They cannot make a broken one work, and you cannot tell which kind you have until real people run real transactions through it.

The 4 apps vs the 1.5

The one full app goes to the side whose experience is the product and who is hardest to win and keep. The half app is an admin panel built for exactly one user, you, with no polish: a table of transactions, buttons for the five things you do every day, and a log of who did what. The other side is served by whatever already exists: SMS, email, a web form, a payment link, a phone call.

In a home-services marketplace that often means a proper partner app (they use it all day, on the move) while customers book through a simple mobile web page. In a B2B services marketplace it can be the reverse. The home-services build story and the local-delivery build story show two different splits.

"But Flutter makes the extra apps nearly free"

Cross-platform tools like Flutter, which we used at Urban Culture, do make a second or third app cheaper to build from the same codebase. They do not make it cheaper to own. Every extra surface is another set of screens to test after each change, another store review, another login flow to support, and another place for the state of a booking to disagree with the admin panel. Building is the smallest of those three costs. Testing and operating are the ones that recur.

Which side should get the real app?

Usually supply. In Lenny Rachitsky's interviews with operators of 17 successful marketplaces, 14 focused almost all early resources on growing supply (Lenny's Newsletter). Supply is usually the constraint, so supply's experience is what you can least afford to fake.

Three questions settle it for a specific business:

1. Who uses it daily? A partner who works five jobs a day needs an app. A customer who books once a month can live with a web page.
2. Who has alternatives? Good suppliers often have plenty of other places to get work. The side with more options gets the better tool.
3. Where does the workflow live? If the hard part is on the job (check-in, photos, completion, payout), it belongs in the supplier's app. If the hard part is choosing (comparing, configuring, quoting), it belongs on the buyer's side.

Marketplace MVP features: keep, fake or cut

Most features fall into one of three buckets. Keep the ones on the transaction loop. Fake the ones a human can do for now. Cut the rest.

There are names for the "fake" column. Delivering the service by hand is a concierge MVP. Showing users an automated-looking front while humans run it behind the scenes is a Wizard of Oz MVP. Both are standard, respectable ways to learn the real workflow before you pay to code it.

What you can't cut

Some things look like polish but are actually load-bearing:

• The money flow. Who is charged when, what happens on a cancellation, when the supplier is paid and what your cut is. Write it down before coding. Your commission has to cover card fees (2.9% + 30¢ per US charge on Stripe) plus payout fees, or every transaction loses money.
• A written state list. Requested, paid, assigned, in progress, done, cancelled, refunded, and who may move between them. Most marketplace bugs I have seen live in a state nobody wrote down.
• An audit trail. When a customer disputes a charge, you need to know exactly what happened.
• Ownership. Your company should own the repository, the payment account, the cloud project and the developer accounts from day one, whoever builds it. See my code ownership checklist.

Can I use no-code for a marketplace MVP?

Yes, if your marketplace is a standard shape: listings, booking or purchase, payment, review. Sharetribe costs $39 a month to build and test, and $199 a month live on yearly billing, with Stripe fees on top. For a lot of founders that is the right first step, and I would tell them so.

Best for: rentals, simple service bookings, and listings marketplaces where the flow is browse, book, pay. Not for: marketplaces where the core workflow is unusual, such as time slots that depend on travel between jobs, one basket split across several vendors, or custom vetting and payout rules. Those are the cases where you end up writing custom code around the builder anyway.

How much does a marketplace MVP cost?

With the 1.5-app scope, one senior engineer and a fixed quote, my rough estimate is $15,000–$28,000 over 6–10 weeks, depending mostly on payment and payout rules. My MVP builds start at $15,000. Four full apps with chat, wallets, reviews and automated dispatch is where agency quotes of $80,000 and up come from. You can compare the two scopes yourself in the app cost calculator: add the second app and the extras, and watch the range move. For a line-by-line breakdown, see the 2026 MVP cost guide.

Running costs at MVP volume are small: hosting, a few SMS, and maps calls that usually stay inside Google's 10,000 free calls per SKU each month (Google Maps Platform). Card fees are the big line, and they scale with revenue.

When is it time to build the next app?

Build the next surface when manual work on that side becomes the bottleneck you can measure. Some signals:

• You spend more than an hour a day messaging the side that has no app.
• The assignment log shows a pattern simple enough to write as rules.
• Customers ask for the same missing feature more than once a week.
• A cost line (maps, SMS, support time) has grown enough that removing it pays for the build.

That last one is the rule I followed at Urban Culture with the geolocation service that cut our Google Maps cost 80%, and the coupon engine that lifted average cart size 16%. Both were worth it because they solved a measured problem in a business that already had volume.

If your spec still lists four apps, the most useful hour you can spend is a scoping session that deletes two and a half of them. That is the first thing I do on a marketplace build; here is how I work and what it costs. If you are still deciding who should build it, start with technical cofounder vs founding engineer vs agency.