Freelancer, no-code or agency: who should build your app?
10 min read
Key takeaways
- A marketplace lives on its liquidity, not its features: the first job is to get transactions, not to have a beautiful catalogue.
- As soon as you collect money on behalf of sellers, use a licensed provider such as Stripe Connect or Mangopay rather than routing the money through your own account.
- Seller KYC is both a regulatory requirement and a brake on sign-ups: build it into the journey, at the moment of the first payout rather than at sign-up.
- The chicken-and-egg problem is solved by choosing one side, a narrow sector and a geographic area, then doing a lot of manual work at the start.
- A serious marketplace MVP costs considerably less than a full platform: start small, then expand — free quote within 24 hours.
“We want to build the Airbnb of…” is one of the phrases we hear most often in meetings. The idea is often a good one. The problem is that most project owners think they are building a website with listings, when they are about to handle other people’s money, trust between strangers and a market that does not yet exist.
A marketplace is not an e-commerce site with several sellers. It is a trusted intermediary, and almost all of its difficulty lies off-screen: the flow of funds, compliance, liquidity. This guide covers these topics in the order in which they should be tackled. If you are already at the project stage, our dedicated page on marketplace development (in French) explains how we work.
Choose the business model before the architecture
The revenue model is not a box to tick in a business plan: it directly determines the flow of money, therefore the payment provider, therefore a good part of the development. It has to be settled before the first mock-up.
| Model | Principle | Suited to | Technical consequence |
|---|---|---|---|
| Commission | A percentage taken on each transaction | Services, rentals, products with a high average basket | Integrated payment is mandatory, automatic split |
| Seller subscription | Sellers pay to be listed | B2B, high-recurrence professionals | Recurring billing, transaction payment sometimes handled off-platform |
| Buyer fee | Service fees added to the basket | Markets where it is hard to make the seller pay | Transparent display of fees, calculation at basket level |
| Promotion | Sellers pay for visibility | Large, competitive catalogues | Ranking engine, placement management |
| Lead / introduction | Payment per contact passed on | Tradespeople, property, local services | No third-party payment, but qualification of requests |
Commission is the most natural model, but also the most exposed to disintermediation: once buyer and seller are in touch, why would they keep paying you? The answer must be in the product, not in the terms and conditions. Secure payment, dispute protection, reviews, insurance, automatic invoicing or a scheduling tool are all reasons to stay. If your platform adds nothing after the first introduction, it will be bypassed, whatever the quality of the code.
A practical tip: do not combine more than two revenue sources at launch. Each model adds a flow to develop, test and explain. Commission plus promotion, or subscription plus buyer fee, are plenty for an MVP.
Third-party payments: never touch other people’s money
As soon as your platform collects a payment intended for a seller in order to pay it out afterwards, you enter the realm of payment services. In Europe, this is a regulated activity that requires a licence. Routing buyers’ money through your company’s bank account before paying it out “by hand” is the classic wrong solution: regulatory risk, mixed cash, unmanageable accounting.
The normal route is to rely on a licensed payment or e-money institution, which holds the funds, verifies sellers’ identities and carries out the payouts. Your platform drives the flow through an API, without ever holding the money. In 2026, two players dominate the projects we see in France.
| Criterion | Stripe Connect | Mangopay |
|---|---|---|
| Philosophy | Connected accounts attached to your Stripe account | Electronic wallets for each user |
| Integration | Very quick, reference documentation, hosted onboarding | More integration work, but more control over flows |
| Strength | Simple payment split, wide choice of payment methods, ecosystem | Escrow, wallets, complex flows between several parties |
| Pricing | Public grid: percentage plus fixed fee per transaction, plus connected-account fees depending on the mode chosen | On quote, depending on volumes |
| Typical case | Bookings, services, SaaS with payouts | Peer-to-peer rental, escrow until delivery, pooled funds |
Neither is “better”. The right question is: when should the money be released to the seller? If it is immediately or on a fixed date, Stripe Connect does the job quickly. If the money has to stay locked until delivery is confirmed, move between several users or top up a reusable balance, Mangopay is often more natural. Draw your flow of funds on a sheet of paper, with every step where money moves, before choosing.
The most underestimated item is not the payment, it is what happens when it fails. Partial refund, late cancellation, dispute, card declined at the time of payout, seller whose account is suspended: these cases often represent more development than the nominal payment. List them during scoping, with the associated business rule, otherwise they will be decided in a rush after launch.
Finally, think about invoicing. The commission you take is your revenue and must be invoiced to the seller. The sale itself is invoiced by the seller to the buyer. Many platforms automate the issuing of these documents on behalf of their sellers: it is a real retention argument, and a workstream to plan explicitly.
KYC: an obligation, and a brake to manage
The payment provider is required to verify the identity of the people it pays out to: this is KYC (Know Your Customer), and for businesses KYB (Know Your Business). In practice, the seller has to provide an identity document, sometimes proof of address, and for a company its registration documents and the identity of its beneficial owners. The exact thresholds and requirements depend on the provider and the profile; it sets them, not you.
For your product, KYC mainly creates a problem of drop-off. Asking for an identity document from someone who is just discovering the platform drives some sellers away. Three principles limit the damage:
- Push verification back to the moment it is useful. Let the seller create an account and publish their offer; ask for the documents when they are about to receive their first payment. They then have a concrete reason to provide them.
- Use the provider’s hosted onboarding when it exists. It is kept up to date with regulatory changes, and saves you from storing identity documents yourself.
- Track statuses in real time. A seller whose file is rejected or incomplete must know immediately, with the reason and the action to take. A payout blocked without explanation generates tickets and mistrust.
Other obligations apply on the platform side, independently of payment. Since 2023, the European DAC7 directive requires platforms to collect certain information about their sellers and to report the income they earn there to the tax authorities. The European Digital Services Act (DSA) requires marketplaces to ensure the traceability of professional sellers. And the so-called “P2B” regulation governs the transparency of your terms towards business users, in particular on the ranking of offers. Have your specific situation validated by a lawyer: these texts have thresholds and exceptions, but none of them is optional. On personal data, our article on GDPR compliance for a mobile app covers the basics.
The chicken-and-egg problem
Buyers only come if there is supply; sellers only come if there are buyers. This is the problem that kills the most marketplaces, and no amount of development solves it. It is solved by strategy and by a great deal of manual work at the start.
Choose a side. Almost always, you start with supply. An empty catalogue converts nobody, whereas a seller can be convinced by an argument that does not yet depend on buyers.
Give sellers a reason to come before demand exists. This is the strategy known as “come for the tool, stay for the network”: a calendar, a quoting tool, a showcase page, availability management. If your platform is useful to the seller even with zero buyers, you no longer need to promise them hypothetical revenue.
Narrow the market until it is dense. A home-services marketplace “everywhere in France” is empty everywhere. The same one, limited to one type of service in a single city, can reach sufficient density within a few months. Liquidity is measured locally: a buyer who finds three relevant offers near home comes back; a buyer who finds two hundred at the other end of the country does not.
Do by hand what does not yet scale. Recruit the first sellers one by one, write their listings with them, take the photos, call the first buyers to understand what they were looking for. This work will never be in the specification, and it is worth more than any feature.
Measure liquidity, not traffic. The right indicators are the proportion of searches that return at least one relevant result, the proportion of listings that receive a request, and the time between an offer going live and its first transaction. The number of visitors or sign-ups says almost nothing.
Turnkey solution or custom development?
There are SaaS solutions for launching a marketplace without developing anything. They have a real benefit: testing a market in a few weeks on a limited budget. They become a brake as soon as your model moves away from the standard, which happens quickly.
| Situation | Recommendation |
|---|---|
| You want to test demand, very classic model (listings + commission) | Turnkey solution for a few months |
| Specific payment flow (escrow, deposit, split payment) | Custom |
| Strong business logic (availability, dynamic pricing, quotes) | Custom |
| Mobile-dominant usage, notifications, geolocation | Custom, with an app |
| Integrations with sellers’ existing tools | Custom |
Custom development is not a luxury: it is what lets you build the advantage that prevents disintermediation. But it must be started on a strict scope, like any MVP. Our article on how to cut the scope of an MVP applies here without reservation.
The budget for a marketplace MVP
A marketplace has at least three interfaces: the buyer journey, the seller area and the operator’s back office. That is what makes it more expensive than a standard app, even on a reduced scope.
MVPThe most economical starting point, with third-party payments and KYC
3–4 monthsTimeline for an MVP, scoping and go-live included
5–8 monthsTimeline for a full web and mobile platform
Here is how the budget for an MVP is typically split.
| Item | Share of budget | Contents |
|---|---|---|
| Scoping and design | 12 to 18% | Flow-of-funds diagram, business rules, journeys, mock-ups |
| Buyer journey | 20 to 25% | Search, offer page, booking or order, account |
| Seller area | 15 to 20% | Offer creation, availability, orders, payouts |
| Payment, KYC, failure cases | 15 to 20% | Provider integration, split, refunds, KYC statuses |
| Operator back office | 10 to 15% | Moderation, disputes, transaction tracking, support |
| Testing, acceptance, go-live | 10 to 12% | Money-flow tests, production environment, monitoring |
What pushes a project towards the top of the range: a native mobile app in addition to the web, escrow with conditional release, booking with fine-grained availability management, messaging between buyers and sellers, or several countries and currencies from launch. What keeps it at the bottom: a responsive web app first, a single revenue model, immediate payment and moderation done by hand in a simple back office.
To place this budget within our overall services, the pricing page presents our packages, and our article on the cost of a mobile app in 2026 details the factors that make a quote vary. Also plan for after launch: application maintenance is a modest monthly budget compared with development, and the payment provider’s fees are charged on each transaction.
What goes into the MVP, and what waits
The recurring trade-offs in the marketplace projects we scope:
- In the MVP: sign-up on both sides, publishing an offer, search with two or three filters, a transaction paid online, payout to the seller, KYC, transactional emails, reviews after a transaction, a moderation back office.
- In version 2: real-time messaging (an email exchange is enough at the start), a referral programme, analytics dashboards for sellers, paid promotion, a mobile app if usage is still to be proven, multi-currency.
- Never cut: handling of refunds and disputes, traceability of every movement of money, and the measurement of liquidity.
In short
Building a marketplace in 2026 means dealing, in the right order, with four questions that most projects approach the wrong way round: how do you make money without being bypassed, who holds the money in transit, how do you verify your sellers without driving them away, and how do you get transactions before you have an audience. The code comes afterwards, and it costs less when these answers are clear.
That is precisely the scoping work we carry out before writing a line of code on a marketplace (in French) project: flow diagram, choice of payment provider, MVP scope and a firm estimate.
Do you have a marketplace project and want a frank opinion on its model and budget? Let’s talk: a first thirty-minute conversation is usually enough to know where to start.
Sources
- Transfert d’informations en application des dispositifs DPI-DAC7 (in French) — impots.gouv.fr (DGFiP)
- Règlement (UE) 2022/2065 sur les services numériques (DSA) (in French) — EUR-Lex (European Union)
- Règlement (UE) 2019/1150 (P2B) sur l’équité envers les entreprises (in French) — EUR-Lex (European Union)
- Embedded finance — Stripe
