Marketplace development

Marketplace development for platforms that start empty

Matching, payments and disputes are easy to put in a spec and hard to get right. We have taken five platforms through a launch day where neither side existed yet.

Book a cold-start audit See the platforms

products shipped: 20+products shipped
industry niches: 4industry niches
years building: 4years building

A marketplace is not a catalogue with a checkout.

The part everyone quotes for is listings, search and payment. That part is well understood, and it is not where marketplaces die. They die in month two, when one side has signed up, the other has not, and nothing in the product gives either a reason to come back.

The mechanics that fix that – who gets verified, what a profile has to prove before a stranger transacts with it, what happens when a booking goes wrong at 9pm on a Saturday – get scoped as phase two. By phase two the platform is already empty and the team is arguing about ads.

We design for the empty state first. The opening question is not what you want built. It is who shows up on day one, and why they stay while the other side is still thin.

What a marketplace build actually includes

Not a feature list. The parts that decide whether the platform survives its first year.

Two-sided onboarding

Separate flows for supply and demand, each of which has to be usable while the other side is still empty. This is the part that gets designed last and matters most.

Verification and trust states

Identity checks, reputation, reviews, and the states in between – pending, limited, trusted, suspended. In a marketplace this is not compliance work, it is the product.

Payments, payouts and refunds

Escrow or direct, split payments, partial refunds, payout schedules, and VAT handling for sellers across EU borders. Refunds are where most integrations turn out to be half-built.

Matching and search

Ranking that works with fifty listings, not just fifty thousand. Geography, availability and relevance, tuned for a thin catalogue rather than a mature one.

Disputes and moderation

Moderation queues, dispute flows, evidence handling, and a manual override on every automated decision. Your ops team will need all four in the first month.

Admin tooling

User impersonation, refunds, roles and permissions, audit log. It never appears in a portfolio and it is the difference between a platform you can run and one you can only demo.

How the build runs

Weekly demos against working software. No status decks.

01
Cold-start audit
Ninety minutes on who joins first and why they stay. Sometimes the honest answer is that you do not need a platform yet, and we will say so.
Week 0
02
Flows before pixels
User flows, edge cases and trust states mapped end to end, including what every screen looks like with no data in it. Most projects are won or lost here.
2-3 weeks
03
Build in one-week sprints
Working staging environment from the first sprint, demo every week. Admin tooling ships with each feature rather than being promised for later.
8-16 weeks
04
Launch and the first ninety days
Instrumentation, a moderation playbook your team can actually operate, and the changes the first real users force. We stay through that part.
Ongoing

Platforms we took through day one

Each of these launched with nothing on either side.

Pachaca

An on-demand cleaning service needed a complete digital ecosystem across mobile, web, and internal operations.

SharingGround

Peer-to-peer item sharing required trust system and logistics

Ski&Sail Club

Build a digital platform for a yacht club that makes trip booking and community management seamless for both newcomers and experienced sailors.

All case studies

What we build it with

Boring, well-documented technology your next developer will recognise.

Product

Next.js
React
TypeScript
React Native

Services

Node.js
NestJS
PostgreSQL
MongoDB
Redis

Operations

AWS
Docker
CI/CD
Monitoring
Payment providers

Questions we get before a marketplace build

A two-sided MVP with verification, payments and working admin tooling runs three to four months with our team. Anything quoted at six weeks is either a catalogue with a checkout bolted on, or it is missing the trust layer – which you will pay for in month two instead.

Four things, in order: how many verification and trust states the product needs, how complex the money flow is (escrow, splits, cross-border VAT), how much moderation and dispute handling your category requires, and how much admin tooling your ops team needs on day one. We write out what is in scope and what is not before you sign, which is usually where quotes diverge.

Often, yes. We audit what is there, say plainly which parts are structurally fine and which have to be replaced, and tell you when patching is genuinely cheaper than a rebuild. We have done both, and we have talked clients out of rebuilds.

Not with features. We work out which side is harder to acquire, design the product so that side gets value while the other is still empty, and make the launch plan match that. If the right answer is a concierge phase with a spreadsheet instead of a platform, we will tell you that on the first call.

Yes. Most marketplaces eventually need at least one native app, usually for the supply side. We will also tell you when a responsive web app buys you another six months and the app can wait.

You do, from the first commit. Clean architecture, tested code, documented systems, in your repositories. We work with EU contracts from our entity in Poznań, so data and IP stay inside the EU.

Tell us who shows up on day one. Thirty minutes, no pitch. If a marketplace is the wrong shape for what you are doing, that is a useful answer too.

Book a call

Worth reading before you brief anyone

What we have learned shipping platforms that start empty.