Case study

Pure Artisan

A multi-vendor marketplace for regional artisan producers in Belgium and the Netherlands — vendor onboarding, payment splits, Belgian VAT, and shipping zones that handle real postal codes, in four languages.

StatusIn progress

MVP delivered in under six months. Later phases are still being built and the platform has not launched, so there are no operating results to report yet.

Discipline
Build
Stack
NestJS · Next.js · PostgreSQL · Redis · Mollie Connect · Meilisearch
Timeline
MVP delivered in under six months
Languages
NL · FR · EN · DE

The problem

Regional artisan producers — cheese makers, bakers, small-batch coffee roasters — had no platform built for how they actually sell. The generic marketplaces did not handle Belgian VAT, multi-language product listings, or local payment methods, and a custom agency build priced most of them out before the first conversation. They needed a multi-vendor system they could operate without technical knowledge.

What it was costing

Every producer was solving the same problems alone: a hand-maintained spreadsheet of stock, invoices assembled by hand at month end, and shipping quoted by guesswork. The cost was not a licence fee, it was the hours that came out of production time — and a ceiling on how far any one of them could sell beyond their own region.

What we found

The brief arrived as "build us a marketplace", but the failure mode in this category is never the storefront. It is the operational layer underneath — who gets paid what, when, and what happens when an order goes wrong across a border. We scoped the payment splits, the commission logic and the shipping rules first, and treated the customer-facing catalogue as the easier half. That ordering shaped everything after it.

What it looks like

What we built

A multi-vendor platform where producers manage their own catalogue, orders and payouts, and buyers shop across all of them in their own language.

  • Vendor onboarding, product management, order handling and an analytics view, built for operators who are not technical
  • Payment processing through Mollie Connect with automatic splits, per-vendor commission and scheduled payouts
  • Four-language support with a per-product translation workflow and explicit fallback rules
  • Shipping zones with postal-code matching, exclusion lists and regional presets for Belgium and the Netherlands
  • Invoice generation with Belgian VAT compliance and PDF export
  • Bulk product import and export via CSV and Excel, because the catalogue usually already exists in a spreadsheet

How it is put together

A NestJS API over PostgreSQL, with Redis for caching and Meilisearch for the catalogue search. The storefront and vendor dashboard are Next.js. Payments run through Mollie Connect, which handles the split at the point of capture rather than reconciling afterwards.

The parts worth naming are not the framework choices. They are the payout scheduler, the commission resolver and the shipping-zone matcher — three small services carrying most of the rules that make the platform specific to this market rather than generic.

The decisions

  1. Match shipping zones on postal codes with an exclusion list, not on regions

    The reasoning
    Alternative considered
    Region- or province-based zones, which is what most marketplace platforms ship with
    Why we chose this
    Belgium has municipalities that contain more than one postal code, and producers care about exactly those edges — the neighbouring commune they can deliver to cheaply and the one they cannot. Region matching is simpler and gets those cases wrong, which is where a local seller notices first.
    What it cost us
    A more complex zone editor, and a validation service to keep entered codes sane. Setting up a zone takes a vendor longer than picking a province.
  2. Hold vendor payouts for seven days after delivery

    The reasoning
    Alternative considered
    Instant or next-day settlement, which several vendors asked for directly
    Why we chose this
    A chargeback that lands after payout comes out of the platform, not the vendor. A marketplace that quietly absorbs those stops being a marketplace and becomes an unsecured lender. The hold window is the difference between a commission model and a credit risk.
    What it cost us
    A harder sell during vendor onboarding, and a scheduled payout job with its own failure modes to monitor rather than a simple per-order transfer.
  3. Per-product translation with fallback to the vendor's primary language

    The reasoning
    Alternative considered
    Machine-translating every listing into all four languages on publish
    Why we chose this
    A producer describing a raw-milk cheese uses vocabulary that machine translation flattens, and the description is the product. Falling back to the original language is honest — a Dutch buyer reading a French listing knows what they are looking at. A bad automatic translation reads as carelessness and it is attributed to the seller, not to us.
    What it cost us
    Incomplete catalogues in secondary languages until vendors fill them in, and translation status to track per product rather than a single flag.
  4. Build commission as a per-vendor rate with a hard floor

    The reasoning
    Alternative considered
    One platform-wide rate, changed by configuration when needed
    Why we chose this
    The referral programme reduces a vendor's rate as they bring others in, so the rate had to be per-vendor from the first migration rather than retrofitted. The floor exists so that no combination of promotions can drive a vendor's rate below the platform's own cost to serve them.
    What it cost us
    Commission becomes a per-vendor value to reconcile at invoice time instead of a constant, and the floor needs enforcing in more than one place.

How the work changes

Before
  • Stock tracked in a spreadsheet, updated by hand after each market day
  • Invoices assembled manually at month end, VAT calculated per line
  • Shipping quoted by guesswork, often under-charged on distant orders
  • Selling limited to buyers within driving distance
After
  • Stock updates from the same dashboard that takes the order
  • Invoices generated with Belgian VAT applied per line, exported as PDF
  • Shipping calculated from the vendor's own zones and exclusions
  • Listings reachable in four languages across two countries

What we would do differently

  • Scoping the payment and shipping rules before the catalogue was the decision that saved the most rework. Every later question resolved against rules that already existed.
  • Asking vendors what they wanted produced "instant payouts". Asking what had gone wrong before produced the chargeback story that set the hold window. The second question is the useful one.
  • Four languages is not four times the content problem, it is four times the empty-state problem. The fallback behaviour mattered more than the translation tooling.

You dream it. We create it.

Discovery call, project brief, or just a question. Get in touch.

Get in touch