Building a Marketplace or Community Platform in Switzerland: What You Need to Know

You have an idea for a platform that connects people. Producers and food lovers, therapists and patients, coaches and athletes, whatever it is. On paper it looks simple: a directory, a "book" button, a payment. In reality, building a Swiss marketplace means building two products at once, for two audiences that do not want the same thing.

I am going to show you what that really involves, with a concrete case I ran from start to finish at AsuOs: Broco. I will also tell you about the false start, because that is often where the real cost of a project plays out.

A marketplace is never a single product

Trap number one is thinking of your project as a classic app. With a classic app, you have one type of user, one journey, one goal. With a matchmaking platform, you have at least two camps.

On one side, the supply. The professionals, the producers, the service providers. They want to create their profile, publish their activities or products, manage their calendar, get paid, track their stats. For them, your platform is a work tool. If it is painful, they leave.

On the other side, the demand. The visitors, the customers, the members of your community. They want to find things fast, understand, book and pay without friction. For them, your platform is a service. If it is slow or confusing, they do not come back.

These two audiences have opposite needs, and your product has to satisfy both on the same day. That is what makes a marketplace far more demanding to design than a showcase site, or even a single-user SaaS. Every feature exists twice: a rich back office for the pros, a smooth and reassuring interface for the public.

The Broco case: from local Swiss produce to a real platform

Broco is the project of Jérémie Cordier, head chef at the Racine restaurant in La Tour-de-Peilz. His idea: a web app (a Progressive Web App) that shines a light on the produce of French-speaking Switzerland by connecting producers, artisans and food lovers around activities close to home. A market, a farm visit, a workshop, a tasting. The kind of project that makes sense here, in French-speaking Switzerland, where the connection to local really matters.

The problem was that development had started offshore, and was going nowhere. Too much distance, little visibility on progress, back-and-forth exchanges that led nowhere. Jérémie was left with a project that was costing money without producing anything usable. A situation I see far too often.

He made the right call: start again on a healthy foundation, locally, with a technical partner within reach of a conversation. We worked together, in French-speaking Switzerland, with regular check-ins and real transparency about what was being built.

You can see the result on the Broco project. What matters here is the pace: in three months of part-time development, we shipped a first version online with everything a community platform truly requires.

What we had to build (and what you are probably underestimating)

When I list what we put into Broco, you understand why a marketplace is never "just a directory".

The activities marketplace

The heart of it: producers and artisans publish their activities, visitors browse them. That means a solid data structure, categories, filters, a search that holds up as the catalog grows.

The interactive map

Broco is a project about proximity, "close to home". Without mapping, the idea falls apart. We integrated an interactive map with MapLibre so everyone can find the activities around them. Geolocation is not a gimmick on this kind of platform, it is the discovery mechanism.

Booking

Finding is good. Booking is the moment of truth. You have to manage availability, time slots, confirmation, the link between the pro and the visitor. Every bit of friction here costs you a transaction.

Payments and subscriptions via Stripe

This is the crux of it all. On Broco, professionals subscribe and pay via Stripe. Handling a platform's payments is not about plugging in a button. You have to think through subscriptions, recurring billing, account statuses, payment failure cases. This is the most sensitive part technically, and the one where improvising costs the most.

Messaging

A community platform is about relationships. We integrated a messaging system so producers and visitors can talk directly, without leaving the app.

Push notifications

Via OneSignal, to bring people back at the right moment: a new activity, a booking reminder, a message received. That is what turns a one-off visit into regular use.

The back office, the CRM and the analytics

And everything the public never sees: an admin back office to run the platform, a CRM to track the professionals, analytics to understand what works. Without that, you are flying blind.

On the technical side, the stack sat on Next.js and React for the front, AdonisJS and PostgreSQL for the back, Cloudinary for media. Robust choices, suited to a product that has to grow.

The real traps when you build a matchmaking platform

Now that you see the scale, let's talk about the mistakes that derail this kind of project.

The distance trap. That is the story of how Broco started. A platform evolves through fast iterations, with decisions made almost every week. When your team is far away, without visibility and without a shared language or time zone, every decision takes three times longer. The proximity of a local partner is not a comfort, it is speed.

The chicken-and-egg trap. An empty marketplace attracts nobody. No producers, no visitors. No visitors, no producers. You have to think from the start about how to kickstart one side before the other, and the product has to support that strategy.

The trap of sloppy payments. Everyone wants to move fast on payments. That is precisely where you should not. A badly handled subscription, billing that glitches, and you lose the trust of your pros overnight.

The trap of forgotten moderation. As soon as humans publish and interact, you have to be able to moderate, suspend, correct. Plan for it early, not when the problem shows up. A platform that grows without safeguards is a platform that turns against you.

The trap of hidden technical debt. A rushed foundation to "go fast" slows you down by the second feature. That is often the real cost of development run without follow-up: the delivered code exists, but it cannot be used. Starting again on healthy foundations, as Jérémie did, costs less than dragging a wobbly project along for months.

The trap of infinite scope. Everything looks essential. The truth is that a first version has to prove the essentials: do people publish, find, book and pay? Broco did it in three months part-time because we were rigorous about what mattered first.

Where to begin, concretely

If you are carrying a project like this, here is the order that works.

First, clarify your two audiences and the first exchange of value between them. Then, scope a first version that proves that exchange, without piling everything on. Next, choose a healthy technical foundation, built to last. Finally, move forward through short iterations, with regular check-ins and real visibility on what is being built.

That is exactly the logic of my custom SaaS in Switzerland offer: building a solid product, step by step, with a technical partner you can call and who speaks your language.

Building a marketplace or a community platform is a real product project, not one more website. Two audiences, payments, booking, mapping, messaging, moderation. Done well, it becomes a tool your community actually uses, like Broco today. If you have a platform idea and want to build it properly from the start, take a look at custom SaaS in Switzerland and let's talk.