Marketplace Platform Development: Cold Start, Commission Models, and Designing for Trust

The business story behind a marketplace always sounds attractive: bring the people who need something together with the people who can provide it, take a fee from the middle, and the larger the transaction volume the easier it gets.

Building one runs into a wall almost immediately: the demand side arrives and finds nothing to choose from, the supply side joins and finds nobody ordering, and each waits for the other to show up first. That is the central difficulty of a multi-sided market, and no amount of feature completeness gets around it.

What follows covers how a multi-sided platform differs from an ordinary website, which side to solve first, how the main revenue models behave, how trust gets built, and what version one should and should not do.

How a multi-sided platform differs from an ordinary website

A conventional e-commerce site sells its own goods, so you control inventory, pricing, and quality. A multi-sided platform is different: you do not own the supply, you provide the venue and the rules for a transaction. Several layers of complexity follow from that.

You have two or more sets of users whose interests point in opposite directions. Suppliers want more exposure, lower commission, and looser rules; buyers want more choice, lower prices, and protection. Every decision the platform makes trades one against the other, and pleasing both at once is not possible.

Your product quality is not entirely yours to determine. A user who has one bad experience with a provider blames the platform. Vetting, reviews, and dispute handling are therefore not add-ons; they are part of the product itself.

Value grows with density, not with totals. A large supplier base spread across the whole country and every category still feels empty; the same number concentrated in one city and one category may already be enough.

Growth has a threshold. Past a certain density, supply and demand begin attracting each other. Below it, more marketing spend just pours water into a leaky funnel.

Which side to solve first: supply or demand

The first cold-start decision is where to concentrate resources.

In most cases, start with supply. Suppliers are usually easier to persuade: another exposure channel costs them little and they are more patient about waiting for orders. Demand behaves the opposite way — a first visit that turns up nothing means there will be no second visit.

There are exceptions. If your supply consists of scarce, highly specialized roles — consultants, technicians, or creators in a particular field — an invitation with nothing behind it rarely lands. Reverse the order: accumulate visible demand and then approach suppliers with it in hand.

The way to decide is to ask yourself: which side is harder to obtain? Whichever it is, use the other side as the currency to acquire it.

There is also an option that gets overlooked: do not build the platform yet, and match people manually. Picture an early matching service where a staff member pairs the two sides by hand in the back office and arranges the deal over messages. It looks insufficiently automated, but it validates whether both sides genuinely exist and how the matching logic should work before serious development money is committed. That is precisely the spirit of building an MVP — test the assumption before discussing scale.

Common cold-start tactics

Beyond choosing a side, a few strategies come up repeatedly:

Shrink to the smallest workable scope. One city, one district, one category. The narrower the scope, the easier density is to achieve, and the closer the experience comes to “things really can be found here.” Replicate into the next scope only once that one works.

Let the platform be a supplier itself at first. Operating part of the supply directly guarantees that arriving demand has something to choose from, with a gradual withdrawal as third-party supply fills in. Handle this carefully for fairness: avoid a situation where your own listings compete against third parties inside the same ranking logic without that being visible.

Start from an existing community or list. If the founding team already holds relationships on one side, starting there is far easier than a cold start.

Design rules that make transactions easier to complete. With both sides thin at the beginning, matching criteria should not be strict. Better to let a handful of transactions happen and generate reviews and examples than to filter so finely that nothing matches at all.

Designing commission and pricing models

The revenue model directly shapes how both sides behave, so decide what you want to encourage. The common structures are described here as mechanisms only; what you actually charge has to be assessed against your own cost structure and market conditions.

Commission on completed transactions. A fee is taken only when a match succeeds, charged to the supplier, the buyer, or both. The advantage is that it is tied directly to value delivered and is easy for users to accept; the challenge is that you must be able to observe that a transaction happened, or both sides will route around the platform.

Subscription. Suppliers pay periodically for exposure or the right to bid. Revenue is stable and individual transactions do not need tracking, but it is hard to push before suppliers have earned anything, so it usually does not suit the cold-start phase.

Value-added services. Basic matching is free, while promoted placement, verification badges, or analytics reports are charged separately. This is friendly to early platforms because it does not raise the barrier to entry.

Hybrid. The most common arrangement in practice: free basics, commission on completion, and optional extras.

Whichever you choose, two questions have to be answered before development starts.

First, how do you stop people bypassing the platform? Once the two sides exchange contact details, there is an incentive to deal privately. What reduces this is generally not restriction but the value the platform itself provides — escrow, dispute handling, record keeping, and the convenience of repeat business. Merely masking contact details usually just degrades the experience.

Second, does the timing of the charge match the delivery of value? Charging before users have received a benefit keeps growth exactly where it is.

Trust mechanisms: reviews, verification, and escrow

Because the platform does not own the supply, it has to make two strangers willing to transact through its rules. This is where a marketplace most needs design effort.

Identity and credential verification. Basic identity or business registration checks, professional license uploads, and contact confirmation. The depth of verification should match the risk of the transaction: the higher the risk in a category, the stricter the vetting, while avoiding a bar so high that nobody joins.

Reviews and ratings. A few practical rules: only people who genuinely completed a transaction can review, both sides review each other, reviews can be replied to but not deleted, and the display shows the volume and distribution rather than an average alone. Early on, with few transactions, the damage from one negative review is amplified, so plan for how to handle that. For the underlying logic of running a review system, see On-Site Customer Reviews and Review Structured Data.

Escrow and completion guarantees. Having the platform hold funds and release them to the supplier once the service is confirmed complete is the most effective way to reduce risk on both sides, but it also increases the complexity of payments and reconciliation considerably. One point here is routinely mistaken for a purely technical decision: a platform that collects money from the buyer and then pays it on to the seller is, in regulatory terms, collecting and disbursing payments for real transactions on others’ behalf. In Taiwan that touches at least two layers of rules:

• Whether you must become an electronic payment institution. Under Article 5 of the Act Governing Electronic Payment Institutions, a business that only collects and disburses payments for real transactions, and whose total balance of funds held stays below an amount set by the regulator, is not an electronic payment institution; above that amount it must apply to the Financial Supervisory Commission (FSC) for a license. The amount is measured as the average daily balance over a year, and when the FSC amended the implementing rules in 2021 it raised the figure from NT$1 billion to NT$2 billion (FSC press release, in Chinese). A new platform is usually far below that line, but the figure can change, so check the FSC’s current announcement when planning.
• Anti-money-laundering registration. Article 6 of the Money Laundering Control Act, as amended in 2024, requires anyone providing third-party payment services to first complete an AML and service-capacity registration with the Ministry of Digital Affairs; unregistered providers may not offer the service. Once registered, all funds collected must be placed in a dedicated trust account or covered by a full bank performance guarantee (Articles 8 and 9 of the registration regulations, in Chinese).

In other words, even far below the licensing threshold, “the platform takes the money and pays it out” is not something you can do just by connecting a payment gateway. The pragmatic approach for version one is to leave collection and payout to a payment provider that is already registered or licensed, with the platform recording the state of each transaction and its funds. Confirm this before the specification is designed, treat the regulator’s current rules as governing, and bring in a lawyer where needed. Whether escrow belongs in version one therefore depends not only on transaction value and the size of the trust gap, but also on leaving time for that confirmation.

A dispute process. This is a policy question rather than a technical one, yet it needs matching functionality in the system: a channel to raise a complaint, the ability to suspend a payout, retained records, and notification of outcomes.

Transparent ranking rules. Sooner or later a user will ask why someone else appears above them. The ranking logic does not have to be published in full, but it must be defensible, and paid factors must not entirely override quality.

The complexity of payments and payouts

Once the regulatory question above is settled, the implementation is still considerably more than “connecting a payment gateway.” It also includes:

• Separating collection from payout: the buyer pays into the platform and the seller is paid after confirmation, with the status of the funds recorded clearly in between.
• Payout scheduling: how often payouts run, what triggers them, and what happens below the threshold.
• Commission calculation and reconciliation: platform fees, processing fees, and tax-related fields need to be traceable per transaction.
• Refunds and partial refunds: how a dispute raised after a payout is handled.
• Invoices and documents: who issues what to whom, which is frequently counterintuitive in a multi-sided structure.

For payment methods in Taiwan and how integration runs, see Payment Gateway Integration in Taiwan; for issuing, voiding, and allowances on the invoice side, see Integrating the Taiwan E-Invoice System. These two areas are where marketplaces most often underestimate the work, so leave real time for them in the plan.

MVP scope: what version one should not do

Version one has a single objective: find out whether the two sides will match successfully here. Anything unrelated to that can wait.

Version one usually needs: supplier onboarding and listing, search and browsing for the demand side, a way for the two to make contact or place an order, basic reviews, and a back office capable of vetting and manual intervention.

Version one usually does not need: live chat (existing messaging tools will do at first), a sophisticated recommendation algorithm (there is not enough data for it to be accurate), a mobile app (validate on the web first), multiple languages, advanced supplier analytics dashboards, or automated dispute arbitration.

Leave room for manual work in the back office. Situations the system never anticipated will certainly arise early on, and operations staff must be able to amend records, match manually, and issue refunds by hand. This back office matters as much as the public site, yet it is routinely treated as secondary during planning.

For how to cut the scope and how far version one should converge, compare against A Guide to MVP Development; for what to build after launch, see Where a Product Goes After Launch.

Operating metrics to watch after launch

The health of a marketplace cannot be read from registration counts, which are the easiest figure to make look good and the least meaningful. The directions worth tracking include:

• Match rate: how much demand actually converts into a completed transaction. This is the core signal of whether the platform works.
• Supply and demand density: within a given scope, how many usable suppliers exist per unit of demand.
• Return visits and repeat business: whether either side comes back for a second time. One-off transactions cannot sustain a platform.
• Supplier churn: people who list and never receive an order will leave, which is an early warning that density is insufficient.
• Dispute rate: a direct reflection of transaction quality.

For how to define the metrics and collect the data, plan alongside A Practical Guide to GA4 so that tracking is instrumented during development rather than retrofitted after launch.

The real barrier for a marketplace has never been technical. It is whether you can survive the phase where both sides are still thin until density forms. So the design principle for version one should be: shrink the scope to its minimum, keep manual intervention at its maximum, and concentrate resources on making the first few dozen transactions genuinely happen.

How far version one should go, and whether you should be holding the money yourself, are usually questions you can only answer with the business model laid out. Talk to NETVANA about your project and we will work through the roles on each side, how you intend to charge, and the minimum scope that validates the idea, before turning to a feature list and a schedule. Software services carry no fixed packages and are quoted on inquiry; what each service includes and delivers is set out in the software services overview.

Further reading: for what belongs in version one and what does not, see A Guide to MVP Development. For the technical side of connecting payments, read Payment Gateway Integration in Taiwan. For issuing documents against transactions, see Integrating the Taiwan E-Invoice System. For making a review system hold up on your own site, see On-Site Customer Reviews and Review Structured Data. And for sequencing features after launch, see Where a Product Goes After Launch.