Building a Two-Sided Marketplace: The Architecture Decisions That Actually Matter

A marketplace is three products, not one

The mistake we see most often in early marketplace planning is treating it as a single app with a database behind it. In practice, a working two-sided marketplace is at minimum three separate products that have to work together: a customer-facing app, a provider-facing app, and an admin system that runs the business behind both of them. Get the boundaries between those three wrong, and you end up with a system where everyone's stepping on functionality meant for someone else.

We built exactly this shape for a cleaning marketplace: a customer app to book and pay, a cleaner app to accept jobs and log proof of work, and an admin CRM to approve providers, assign jobs and track payouts. Here's what actually matters when you're making those architecture decisions.

Decision one: when does money move?

This is the single decision that shapes the most downstream complexity. Charge upfront, and you remove the collections problem entirely — the business is never chasing a customer for money after a job is done — but you take on the responsibility of holding funds and releasing them correctly. Charge on completion, and you avoid holding customer funds, but you're now trusting that payment actually happens after the fact, with all the disputes and chasing that implies.

For the cleaning marketplace, upfront payment was the right call — the operational cost of chasing payment after every job was worse than the complexity of collecting it before. That's not universal advice; a marketplace for higher-trust, repeat B2B transactions might reasonably choose the opposite. But it's a decision to make deliberately in week one, not something to default into, because it touches your payment provider integration, your refund policy, and how disputes get resolved.

Decision two: what counts as proof

Two-sided marketplaces run on trust between people who've often never met, and disputes are inevitable. The question is whether you have anything concrete to resolve them with. Timestamped before-and-after photos, GPS-confirmed check-ins, digital signatures — whatever's appropriate to your specific service — turn a "he said, she said" dispute into a two-minute look at the record.

This has to be designed into the provider-side app from day one, because retrofitting proof-of-work capture after a business has already scaled to dozens of providers is a much harder rollout than building it in before anyone's onboarded.

Decision three: how much does the admin side actually need to see

It's tempting to build the admin panel as an afterthought once the customer and provider apps are working. That's backwards. The admin system is what actually runs the business day to day — approving new providers, assigning jobs, tracking commission, spotting a provider who's underperforming before a pattern of bad reviews forms.

Commission calculation in particular deserves real design attention. Doing it by hand in a spreadsheet works at five providers and becomes a liability at fifty, because every manual calculation is a chance for an error that either costs the business money or, worse, underpays a provider and damages trust in the platform.

Decision four: what happens when supply and demand don't match

Every marketplace eventually hits a moment where demand outstrips available providers in a given area, or a provider cancels last minute. Deciding how the system handles that — waitlisting, automatic reassignment, surge pricing, or simply an honest "not available right now" — before it happens in production is much easier than improvising it under pressure with a frustrated customer on the phone.

The architecture that actually holds up

None of this requires exotic technology. The cleaning marketplace runs on mobile apps for customer and provider, a REST API connecting them to the admin system, Stripe for payment, and cloud storage for the photo evidence — all standard, well-documented tools. What made it work wasn't unusual technology; it was making the four decisions above deliberately, early, instead of discovering the right answer the hard way after launch.

Where most marketplace projects actually go wrong

It's rarely the technology. It's scope: trying to build all three sides fully-featured before launching anything, instead of shipping a real but narrower version of all three and expanding from there. A marketplace with a slightly manual admin process but a smooth customer and provider experience will teach you more about what to build next than a fully-automated system that took eighteen months to ship and launched into a market that had moved on.

Planning a marketplace and want a second opinion on the architecture before you commit to a build? [Book a 30-minute call](/contact) — we'll talk through the actual decisions above for your specific business.