How to build a marketplace from scratch

Most marketplaces don't die because of bad code. They die because buyers and sellers never meet on the platform. So the answer to how to build a marketplace starts not with a tech stack but with the model: who you connect, what you charge for, and where you'll find the first hundred participants on each side.

This article walks the path from idea to a working MVP: stages, first-version features, architecture, payments, timelines and a reference budget. It's all based on our experience launching two-sided platforms.

Marketplace model and economics

Before you build a marketplace, answer four questions. If even one has no answer, it's too early to start development.

1. What type of market is it? Goods (B2C or B2B), services with providers, rentals, classifieds, hiring. This determines the catalog, logistics and payments.
2. What problem do you solve for each side? For buyers: choice, price, guarantees. For sellers: a stream of customers they can't get on their own.
3. How do you make money? Transaction commission, seller subscriptions, paid promotion, lead generation. Models can be combined, but an MVP is better off with one.
4. Why will the deal go through the platform rather than around it? Secure payment, guarantees, ratings, convenient paperwork: without this value, the parties will deal directly after the first contact.

Work out the unit economics before development: average order value, commission, cost to acquire a buyer and a seller, repeat purchase frequency. If a deal earns a 500 ₽ commission, acquiring a customer costs 2,000 ₽ and there are no repeat purchases, the model doesn't work no matter how good the product is.

The chicken-and-egg problem

Buyers go where there's supply, and sellers go where there's demand. This is the main risk for any new marketplace, and technology alone won't solve it. Tactics that work:

• Start with a narrow niche and a single location. A marketplace for plumbers in one city district is easier to fill than “every service across the whole country”.
• Build the supply side first. Sellers are fewer, easier to find and easier to win over by hand: calls, meetings, free listings.
• Give one side value even without the other: a convenient dashboard, a CRM for providers, online booking. Then sellers stay while you bring in buyers.
• Fill supply manually at launch: the team can handle some orders itself so buyers never see an empty catalog.
• Measure liquidity: the share of orders that find a provider or seller within a reasonable time. This is the key metric for an early-stage marketplace.

The good news: the first few hundred participants don't need a complex product. Many successful platforms started with manual order handling, spreadsheets and chats, and automated processes only once they understood what actually repeats. Development should follow proven demand, not run ahead of it.

Stages of building a marketplace

In total, a platform MVP takes 8–12 weeks. Some stages run in parallel: while developers build the catalog, the product team signs up the first sellers. It's best to pin down requirements in advance; we cover how in our article on how to write a technical specification.

MVP features: what to build now and what can wait

The biggest temptation is to build “something like Avito” right away. Large platforms took years to build. An MVP should cover one complete deal cycle and nothing more.

Must-haves in the first version

• Sign-up and profiles for each role: buyer, seller or provider, administrator.
• A catalog or feed of listings with search and basic filters.
• Checkout and deal statuses.
• Payment through the platform; otherwise you don't control the deal and don't get your commission.
• Notifications: email, push or Telegram.
• Reviews and ratings, the foundation of trust.
• Admin panel: moderation, user management, dispute resolution.

What can wait

• Native mobile apps: a responsive website or PWA is enough at launch.
• Advanced recommendations and personalization: they don't work while data is scarce.
• Loyalty program, promo codes, referral system.
• Built-in chat: early on, notifications and phone calls will do.
• Paid seller promotion: it makes sense once sellers start competing for buyers' attention.

Payments, escrow and payouts

The payment flow is the most underestimated part of a marketplace. You can't simply take buyers' money into the company account and then distribute it to sellers: that creates tax and legal risks. The usual options are an agency model or dedicated marketplace solutions from payment providers, with split payments, funds held until the order is fulfilled (escrow, or “safe deal”) and automatic payouts to sellers, including self-employed individuals.

• Decide who the seller is in the buyer's eyes: the platform or the participant. Contracts, fiscal receipts under 54-FZ (Russia's online cash register law) and taxes all depend on this.
• Choose a provider with marketplace support before development starts: its API shapes the architecture of the payment module.
• Plan for refunds, partial refunds and disputes from day one.
• Bring in a lawyer and an accountant at the design stage; it's cheaper than reworking the flow after launch.

Architecture that can handle growth

How do you build a marketplace you won't have to rewrite in a year? Split the product into domains with clear boundaries: catalog, search, orders, payments, users, moderation, notifications, geolocation. At launch this can be a single service with cleanly separated modules, a modular monolith. As load grows, the busiest modules are moved into separate services without rewriting the rest.

• A single API for web, mobile apps and Telegram, so new clients plug in without backend changes.
• A relational database for orders and money, and a separate search index for the catalog.
• Queues for notifications, payouts and background jobs.
• Audit log, anti-fraud rules and backups from the first release.
• Monitoring and alerts: you should find out that payments are down before your users do.

Web, mobile apps or Telegram

For the first version, a responsive web app is usually enough: search engines index it, it opens from a link and it doesn't need app store review. Mobile apps become necessary when providers need reliable geolocation and dependable new-order notifications, and buyers come back often. If your audience is active on Telegram, the seller or provider dashboard can be built as a bot with a Telegram Mini App, which is faster and cheaper than a separate app. Thanks to the single API, these channels are added as you grow rather than all at once.

That's how our home services marketplace is built: geosearch for providers, ratings, escrow, a web version and apps for iOS and Android. The MVP was ready in 9 weeks, and the platform now has more than 12,000 providers. A similar architecture with customer, driver and dispatcher roles powers our transfer booking service.

Common launch mistakes

1. Launching straight into a broad market. An empty platform across many categories looks worse than a full one in a single category.
2. A year of development before the first user. By then the hypotheses are outdated, and the budget runs out before any data appears.
3. Payments that bypass the platform. If the platform isn't part of the settlement, it can't see deals, doesn't earn a commission and can't protect participants.
4. No moderation. A handful of dishonest sellers at launch can undermine trust in the platform for a long time.
5. Vanity metrics instead of liquidity. Sign-up counts say nothing; what matters is the share of successful deals and repeat purchases.
6. A weak admin panel. If the team can't quickly find an order, issue a refund or block a participant, support will be overwhelmed within the first hundred deals.

Most of these mistakes are fixed not with money but with discipline: a narrow focus, short iterations, weekly metric reviews and direct contact with the first participants on both sides.

How much it costs to build a marketplace

For reference, developing a marketplace platform starts at 1,200,000 ₽ for an MVP with an 8–12 week timeline. The final amount depends on the number of roles, the complexity of the payment flow, geolocation and maps, integrations with sellers' accounting systems, and whether you need mobile apps from day one. The exact cost is set once the technical specification is worked out; benchmarks for all products are on our development pricing page.

Budget for more than development. Acquiring the first participants, legal support, payment provider fees, infrastructure and post-launch development often cost as much as the MVP itself. Learn more about how we build platforms on our marketplace and platform development page.