Multi-Country Marketplace Platform Development
Marketplaces that expand into a second country usually fork. It works once and becomes unmanageable at the third. We build the alternative: one codebase where the country is a configuration boundary.
Why forking fails
The obvious way to launch in a new country is to copy the deployment and change the settings. It ships quickly, and for a while it is fine. The problem arrives with the third market, when every new feature has to be built, tested and released three times, and the three databases have quietly drifted apart.
By then the cost of consolidating is high enough that most teams keep forking, and expansion slows to whatever the engineering team can carry.
The country as a tenant boundary
The alternative is to treat the country as the top-level tenant from day one. Currency, tax rules, categories, document requirements, and available payment, delivery and SMS providers all become per-market configuration rather than per-market code.
A new country is then an administrative task: an admin creates it, selects the providers available there, sets the tax rules and publishes. No deployment, no fork, no second database.
What that involves
- Per-country currency, tax and pricing rules
- Payment and delivery providers selected per market
- Localised categories and document requirements
- A permission model spanning global, country and business scope
- One customer identity usable across every storefront
- White-label storefronts on merchants’ own domains
- Search that stays affordable as catalogue size grows
What we have built
Kolloh is a marketplace platform structured exactly this way: nine applications in one monorepo, with a six-role permission model spanning super admin, country admin, moderator, business owner, business staff and customer. A country admin’s authority stops at their own market; moderators receive a scoped subset of it.
Merchants get white-labelled storefronts on their own domains — a themed, filtered view of the same data rather than a forked copy, so a platform-wide feature reaches every storefront at once. Search runs on self-hosted Meilisearch, chosen after comparing the cost of metered search services at the volumes the platform expects.
A separate Python service handles demand forecasting, anomaly detection and customer lifetime-value prediction, so operators can see what is happening across markets rather than only within one.
Decisions worth making early
Two choices are expensive to reverse. The first is whether customer identity is shared across markets or siloed — shared is almost always right, but it has to be designed in. The second is transactional email: sending it from the platform’s own infrastructure rather than each merchant’s domain looks pedantic until the first merchant misconfigures SPF and their order confirmations stop arriving.
Common questions
Can you build a marketplace that operates in several countries?
Yes. Kolloh treats the country as the tenant boundary, with currency, tax rules, categories and payment providers configured per market from a single codebase rather than a fork per country.
How do you handle different payment providers per country?
Providers are registered globally and enabled per country by an administrator, so a market can use whichever gateway its customers already trust. Adding a country is configuration, not a release.
Can merchants have their own branded storefront?
Yes — white-labelled, on their own domain, as a themed and filtered view of the same platform data. That means a platform-wide improvement reaches every storefront at once instead of needing to be ported.
Does multi-country mean multi-language too?
Almost always. Every platform we ship supports English, French and Arabic including full right-to-left layout, which matters for any marketplace operating across Europe, the Gulf and North Africa.
Tell us what you are building
Most projects start with a one-week discovery sprint. You get a scope, a technical plan and a costed roadmap — yours to keep, whoever builds it.