AI-gestuurde B2B-sourcing marketplace voor de Europese mid-market

De Klant

Twee operators in de Europese procurement-wereld, die een AI-first B2B-sourcing platform lanceren rondom één conversational AI-persona die elke chat-interactie aanstuurt. Het ontstaansverhaal is concreet: de oprichters waren maanden bezig om via web search en ChatGPT een co-packer voor frisdrank te vinden, voordat ze concludeerden dat de discovery-en-kwalificatie laag in mid-market procurement gewoon kapot is. Geen engineeringsteam in huis. Mape werd ingeschakeld als de build-partner over de hele stack, niet voor één laag.

Het Probleem

Mid-market B2B-procurement in Europa zat klem tussen twee productcategorieën, allebei verkeerd voor de klus. Aan de ene kant directories zoals Thomasnet en Kompass: veel listings, geen kwalificatie, de koper doet alsnog al het werk. Aan de andere kant volledige transactie-rails zoals Faire of JOOR: zware onboarding, smalle vertical-fit, geoptimaliseerd voor retail-bijbestelling in plaats van discovery sourcing. Niets daartussenin handelde de daadwerkelijke workflow af: een koper met een niet-triviale spec (volume, certificeringen, geografie, dealbreakers) die drie tot vijf gekwalificeerde leveranciers zoekt, snel wil screenen, en een echt gesprek wil starten.

Voor de leverancierskant was de pijn symmetrisch. Inkomende aanvragen via een website-contactformulier kwamen binnen als eenregelige e-mails zonder elke informatie die nodig is om te besluiten of het de moeite waard is om te reageren. Sales-teams verbrandden uren aan het kwalificeren van leads die bij eerste contact al hadden moeten afvallen. Er bestond geen gestructureerde weergave van wat de leverancier daadwerkelijk doet (sectoren, certificeringen, capaciteit, MOQ, lead times, dealbreakers) waar een koper op kon zoeken.

Bestaande AI-tooling, inclusief generieke chatbots, schoot op twee fronten tekort. Ten eerste: geen procurement-specifieke gestructureerde output. Een vrije chat produceert narratieve antwoorden, geen veld-data die een matching engine kan gebruiken. Ten tweede: geen data wall. Een koper die binnenkomt via een leverancier-branded URL mag nooit in de marketplace-zoekpool terechtkomen. Dat is een contractuele belofte aan leveranciers, en die moest op database-niveau worden afgedwongen, niet op applicatie-niveau.

De opdracht: bouw het hele ding. Marketing site, auth, leverancier-intake, leverancier-branded screening-URLs, koper-marketplace-intake, matching engine, lead inbox, workspace voor onderhandeling, admin tooling. Productie-rijp, gehost op de eigen infrastructuur van de klant, volledig EU-resident.

Onze Aanpak

Fase 1: Fundament

Stack vastgelegd (Next.js 15 App Router op Vercel EU, PostgreSQL op Supabase EU met RLS op elke tabel met persoonsgegevens, pgvector geactiveerd maar uitgesteld), Postgres-schema geschreven met de data wall ingebakken: elke discovery_orders rij draagt een source enum (SUPPLIER_WIDGET of MARKETPLACE) die na insert onveranderbaar is, afgedwongen door een trigger. De auth-flow gebouwd (e-mailbevestiging, signed redirects, server-component session helper) en de marketing-landingspagina met wachtlijst-capture. CI gates op type-check, lint en format bij elke push.

Fase 2: AI Intake Engine

De leverancier-intake gebouwd als eerste AI-oppervlak: een conversational interview met de AI-persona, gestructureerde extractie die parallel met de stream loopt via Gemini 2.5 Flash, server-side completeness scoring (de LLM rapporteert consequent te veel over zijn eigen dekking, dus een deterministische counter zit erbovenop), merge-on-write semantiek zodat een mislukte late extractie geen goede eerdere niet kan overschrijven, en document upload met een tweede extractie-pass voor PDF's. Diezelfde engine drijft de leverancier-branded screening URL op /s/<slug>/screen, waar een koper namens een specifieke leverancier wordt gescreend wiens profiel als context in de system prompt wordt geïnjecteerd.

Fase 3: Marketplace Matching

De koper-intake op /onboarding/buyer is het derde AI-oppervlak: open, geen single-supplier context, gekoppeld aan de homepage-hero-zoekbalk zodat een getypte query door de signup heen wordt meegenomen en in beurt één van de chat landt. De matching pipeline zelf draait in drie lagen: een gestructureerde SQL-filter op canonical taxonomy-velden (sector, certificeringen, capaciteit, MOQ, land), Postgres tsvector plus GIN full-text retrieval (BM25-style) op leverancier free_text_about en productbeschrijvingen, en een Claude Sonnet re-ranker met prompt caching op de leveranciers-corpus-prefix. Streaming UI levert de shortlist progressief, end-to-end binnen vijf seconden.

Fase 4: Workspace en Launch

De strategische feature waar het platform omheen gebouwd is: een gedeelde workspace waarin koper en leverancier onderhandelen bovenop een AI-gegenereerde order-draft. Elk chatbericht wordt geparsed op term-wijzigingen; zodra een voorwaarde verschuift, maakt het systeem een nieuwe versie-rij aan met per-veld accept/reject state. Beide partijen zien dezelfde single source of truth in real time. Versiebeheer, PDF-export en de per-veld state machine vormen de laatste laag van de build.

Wat We Hebben Gebouwd

• Drie-oppervlak AI intake engine, draaiend op één gedeelde conversational primitive: leverancier-profielintake, leverancier-branded koper-screening op /s/<slug>/screen, en marketplace koper-intake op /onboarding/buyer
• Drie-lagen matching pipeline (gestructureerde filter, Postgres BM25 retrieval, Claude Sonnet re-ranker met prompt caching), streaming een gerangschikte shortlist in de UI binnen vijf seconden
• Echte-Europa kaart-component met 42 landomtreklijnen geprojecteerd via equirectangular vanuit publiek-domein GeoJSON op build time, met city pins voor Amsterdam, Berlijn, Parijs, Londen, Madrid, Rome en 17 andere hubs op hun werkelijke geografische coördinaten
• Data wall afgedwongen op database-niveau: discovery_orders.source enum vergrendeld door een Postgres trigger, RLS-policies scoped op target_supplier_org_id en source, met extra-veilige filters op elke applicatie-leespad
• Gestructureerde extractie-laag die Gemini 2.5 Flash parallel met de streaming response draait, met merge-on-write semantiek en server-side completeness scoring zodat de voortgangsbalk eerlijk blijft
• Determinisme-log op elke AI-call (prompt hash, model-versie, temperature, token counts, latency) zodat een output van vorige maand reproduceerbaar blijft na een model-upgrade
• Signed-cookie guest session laag voor de leverancier-branded screening flow, HMAC-afgeleid van de Supabase service-role secret, zodat een koper zonder account een screening kan doen maar niet tussen leverancierstranscripten kan springen
• Workspace met AI-opgestelde order: chatberichten geparsed op term-wijzigingen, versie-rijen order_drafts met per-veld {proposed_by, accepted_by_buyer, accepted_by_supplier} state, PDF-export
• Leverancier-dashboard met lead inbox, lead detail-view met accept/reject server actions, en een sticky-sidebar layout die hoog lead-volume overleeft
• Merk-neutrale codebase: de platformnaam en AI-persona leven in één config-bestand, zodat een toekomstige rebrand één pull request is

Het Resultaat

Het platform is live in productie op de eigen Supabase- en Vercel-projecten van de klant. Een leverancier kan zich aanmelden, de intake afronden en dezelfde dag een branded screening-URL uitsturen. Een guest-koper kan op die URL landen, een vijfminuten-screening met de AI-persona doen en een gestructureerd rapport indienen dat in de lead inbox van de leverancier landt met volledige contact- en kwalificatie-detail. Een marketplace-koper kan inloggen, beschrijven wat hij wil sourcen en een gerangschikte shortlist krijgen met een one-tap "Verder met deze leverancier"-flow die de discovery order aanmaakt met source = MARKETPLACE en beide partijen in de workspace routeert.

Latency op de AI-oppervlakken is afgestemd op gemeten Gemini-extractietijden (gemiddeld 10,4 seconden, max 19 seconden op een lang transcript). Extractie loopt parallel aan de assistant-stream in plaats van erna, en de voortgangsbalk polt op een cascade tot dertig seconden zodat een trage extractie alsnog zichtbaar landt.

Brand identity, inclusief een 3D-karakter gegenereerd via image-to-image met Gemini 2.5 Flash Image vanuit het referentieblad van de oprichters, verschijnt consistent over de marketing-landing, in-product avatars, de screening-chat, de marketplace-intake en de workspace.

Operationele metrics (leveranciersaantal, marketplace-ordervolume, landendekking) worden bijgehouden in de analytics-laag van de klant en worden aan deze case study toegevoegd zodra de early-access cohort sluit.

Technologie

• Next.js 15 (App Router, server components, server actions): full-stack framework voor de marketing site, dashboard en API routes
• TypeScript (strict mode): gebruikt over elk bestand, inclusief AI prompts en projection math
• Tailwind CSS v4 met Base UI primitives (shadcn base-nova preset): design system fundament
• Motion 12 en Sonner: animaties en toast notifications gebruikt over chat, dashboard en lead-acties
• Supabase (EU Frankfurt, PostgreSQL, Auth, Storage, RLS, pgvector gereserveerd): het system of record. Migraties in de repo gecheckt en toegepast via de Supabase CLI
• Vercel AI SDK v6 met @ai-sdk/google en @ai-sdk/anthropic: streaming plus structured-output abstractielaag. Alle calls geroute via één interne client die voor elke invocation een determinism-log rij wegschrijft
• Gemini 2.5 Flash: leverancier- en koper-intake-gesprekken, gestructureerde extractie (generateObject met een Zod-schema), en document-extractie
• Gemini 2.5 Flash Image: mascotte- en referentie-asset-generatie via image-to-image met het karakterblad van de oprichters als input
• Claude Sonnet 4.7: re-ranking laag voor matching, met prompt caching op de leveranciers-corpus-prefix zodat de per-query kosten begrensd blijven naarmate het corpus groeit
• Postgres tsvector + GIN indexes: BM25-stijl retrieval-laag voor de matching pipeline, geen externe search service nodig
• Zod 4: schema-validatie voor AI-extractie, met .default() per veld voor backward compatibility over schema-revisies
• Infisical: secret management over dev en productie
• GitHub Actions: type-check, lint en format gates bij elke push