100K+ Downloads, Two Sides, One Platform: How We Built a Marketplace App That Scaled

A home services startup needed more than a booking app. It needed a two-sided marketplace app that could bring households and verified professionals together, match them in minutes, move money fairly between them and keep both sides coming back. iSkylar handled the marketplace app development: three apps on one cloud backend, a matching engine, in-app payments with commission and payouts, and ratings in both directions. The marketplace matched requests across 300+ services, ran in multiple cities and passed 100K+ downloads.

Two customers, one platform

Most apps have one user to please. A marketplace has two, and they want different things. Households wanted a reliable professional at a fair price, quickly. Professionals wanted steady work, clear pay and as little admin as possible. If either side lost interest, the other had no reason to stay.

The founders had already built the service and recruited the professionals. What they needed was the marketplace layer: the system that lets thousands of strangers find, trust and pay each other again and again without the operations team standing in the middle of every job. That is what makes marketplace app development different from building a normal booking app, and it is the part of the business iSkylar built.

Starting with supply: the cold start problem

Every new marketplace faces the cold start problem. Customers will not come without providers, and providers will not come without customers. Marketplaces that get past it usually pick one side, often the harder one to win, and build it first .

The founders chose supply. Professionals were recruited and verified in each area before customers were invited to book, which meant the platform had to support provider onboarding from the very first release, long before demand was flowing. It paid off: the first customers in each area found real availability, and a first booking that works is what turns into a second one. Supply and demand grew together from there.

What we built

The marketplace app architecture rests on one idea: separate apps for each side, one backend for everything.

One backend for every app

Running the customer and provider app on one backend matters more than it sounds. All three apps call a single REST API that reads and writes one database. When a provider accepts a job, the customer sees it at that moment because both apps are reading the same record. When a payment completes, the provider's earnings, the platform's commission and the admin reports update from the same transaction. Nothing has to be synced, so nothing falls out of step.

For founders, this is the cheapest marketplace platform development decision to make early and the most expensive one to reverse later.

A matching engine the operations team could tune

The marketplace matching engine decides which providers see which requests. When a customer books, it filters providers by the skill the job needs, whether the address falls inside their service area, their availability for the chosen slot and their account status, so only verified, active providers are included. Location checks use Google Maps Platform, and eligible providers receive a job alert through Firebase Cloud Messaging. The first suitable acceptance wins.

Matching rules live in the backend, not in the apps, so the operations team can adjust them without an app release, for example by widening a service area where supply is thin. That flexibility protects marketplace liquidity: the share of requests that become completed jobs.

Commission and payouts

Customers pay the platform in the app through Razorpay, the payment gateway, using cards, UPI, net banking or wallets. Each completed job records three amounts: what the customer paid, the platform's take rate and the provider's earnings. Providers see their earnings per job in the provider app, and payouts are settled on a set cycle from the admin dashboard. Getting marketplace commission and payouts right is where many marketplaces lose either money or trust; here, both sides could always see where every payment went.

The same design leaves room for the two common payment models. Split payments divide each transaction between platform and provider at the moment of payment, which suits many providers and simple prices. Escrow holds funds until the work is confirmed, which suits higher-value jobs, product sales and freelance work.

Keeping transactions on the platform

Platform leakage, where customers and providers meet through the app and then deal directly, is one of the most common reasons marketplaces struggle to make money . We reduced it by making the app the easiest way to rebook: upfront prices left nothing to negotiate offline, in-app payments removed the need to share bank details, ratings only built up for jobs booked through the app, and service guarantees only covered platform bookings.

Trust on both sides

Customers rated providers after every job, and providers rated customers too. Two-way ratings let the operations team spot problems on either side early, from a provider whose scores were slipping to a customer who regularly cancelled at the door. Together with verified provider onboarding, clear job histories and admin tools to pause accounts and settle disputes, they formed the platform's marketplace trust and safety layer. In a service marketplace, where a stranger enters someone's home, that layer is essential.

Launching city by city

Scaling a marketplace app is not only about servers. Each city is its own small marketplace with its own balance of supply and demand. The platform made cities, service areas, prices and provider pools configurable from the admin dashboard, so each launch could repeat the supply-first approach without new code. One marketplace app for multiple cities ran from a single cloud backend on AWS.

Tech stack

Results

• 100K+ downloads across Android and iOS

• 3 apps on one backend: customer app, provider app and admin dashboard

• 300+ services matched to verified providers through one matching engine

• Multiple cities run from one platform, each launched from the admin dashboard

• Featured by Apple as a trending Lifestyle app in 2015, 2016 and 2017

The same architecture, other marketplaces

This was a service marketplace app, but the pattern of separate apps for each side, one backend, matching, payments and two-way ratings powers most marketplace types. What changes is what is being exchanged.

That is why we treat a multi-vendor marketplace app and an on-demand marketplace app as variations of one architecture rather than separate products.

What we would build differently today

The architecture would stay. Around it, we would add real-time services in Node.js for live job status and chat, ranking that weighs distance, rating and response time, automated identity checks to speed up provider onboarding, split payments and escrow built in from the start, and fake-review detection to protect two-way ratings.

Takeaways for founders

1. Win one side first. Supply first, in one small area, is the fastest way past the cold start problem.

2. One backend, many apps. Each side gets its own app; everything shares one source of truth.

3. Keep matching rules in the backend. You will tune them constantly, so keep them out of app releases.

4. Design payments around leakage. Upfront prices, in-app payments and guarantees keep transactions on the platform.

5. Rate both sides. Two-way ratings are the cheapest trust tool you have.

About this project

The platform behind this marketplace app case study is Mr. Right, an on-demand home services marketplace based in India. For the business side of the story, read our home services app development case study. If you want to build a two-sided marketplace app, iSkylar is a marketplace app development company that delivers through our marketplace development and custom software development practices, including B2B and B2C portals. You can also extend your team with our full-stack developers or Node.js developers.

Planning a marketplace of your own?

Bring the market. We will build the platform that connects both sides.

Book a demo