WBSO CASE · PROGRAMMATUUR

SaaS-platform met eigen matching-algoritme

Van 2 naar 20 miljoen combinaties binnen 200 ms. Deze case laat zien waar beschikbare technologie tekortschoot, wat er in eigen programmatuur is ontwikkeld en waar de S&O-afbakening lag.

INHOUDELIJK BEORDEELD DOOR PETER KLAREN · LAATST GECONTROLEERD SEPTEMBER 2026 · GEBASEERD OP HANDLEIDING WBSO 2026

Representatieve case: dit dossier is samengesteld op basis van veelvoorkomende WBSO-situaties en geanonimiseerd; het is geen letterlijke weergave van één klantdossier.

Case in elf fases

De onderneming en uitgangssituatieEen SaaS-bedrijf exploiteert een matchingplatform dat kandidaten en opdrachten in realtime koppelt. Door groei van het platform stijgt het aantal te beoordelen combinaties van 2 naar 20 miljoen per opdracht.

Het technische doelMatching behouden binnen maximaal 200 ms latency (P95) en een geheugenbudget van 4 GB per node, bij een vertienvoudiging van het datavolume.

Het programmeertechnische knelpuntDe bestaande indexerings- en querystructuur beoordeelt elke nieuwe invoer tegen een te groot deel van de dataset. Bij 20 miljoen combinaties overschrijdt de scoringstijd de latencylimiet en deelt de cache-hitratio fors in.

Waarom bekende techniek tekortschootBestaande libraries, read-replica's, caching en regionale sharding zijn beproefd. De benchmarksuite toonde aan dat het kernprobleem computationeel bleef: de vergelijkingsmethode zelf schaalt niet. Configuratie lost een rekenprobleem niet op.

Onderzochte oplossingsrichtingen(a) Eigen partitioneringsstructuur die de dataset in voorberekende buckets verdeelt. (b) Incrementele scoring die alleen delta's herberekent. (c) Approximerende voorfase met exacte naberekening voor de top-kandidaten.

Programmeerwerk en experimentenDe nieuwe structuur en scoring is ontworpen, in een formele programmeertaal gerealiseerd (Rust) en iteratief getest. De benchmarksuite draaide op productrepresentatieve datasets; profileresultaten stuurden de optimalisatierondes.

Technisch resultaatP95-latency van 180 ms bij 20 miljoen combinaties en 3,2 GB geheugen per node, met behoud van matchkwaliteit. Het nieuwe informatietechnologische werkingsprincipe was daarmee aangetoond.

Wat kwalificeerde als S&OHet ontwerpen én in programmatuur realiseren en iteratief testen van de eigen heuristiek en datastructuur. Benchmarks dienden om vast te stellen of het nieuwe werkingsprincipe daadwerkelijk functioneerde. Een algoritme of architectuur alleen was niet voldoende geweest.

Wat kwalificeerde nietUX- en front-endwerk, standaard API-koppelingen, cloudconfiguratie, databasemigraties en documentatie voor gebruikers.

Waar eindigde het WBSO-projectToen de benchmarks aantoonden dat het nieuwe werkingsprincipe de latency- en geheugeneisen haalde, eindigde het ontwikkeltraject. Productisering, hardening en uitrol vielen daarbuiten.

Welke projectadministratie paste hierbijGit-historie met technische commitbeschrijvingen, issue tracker, benchmarkrapportages, profileresultaten en ontwerpnotities (architecture decision records).

Zo vertaalt dit zich naar een WBSO-aanvraag

Element	Invulling
Technisch doel	realtime matching bij 10× datavolume, P95 ≤ 200 ms, ≤ 4 GB per node
Programmeertechnisch knelpunt	bestaande index- en querystructuren overschrijden latency- en geheugenlimieten
Oplossingsrichting	eigen partitionering plus incrementele en approximerende scoring
Technische onzekerheid	onzeker of responstijd haalbaar is zonder substantieel kwaliteitsverlies

Verdieping: WBSO software en programmatuur · projectadministratie bij software (Git, issues, benchmarks)

Lijkt uw project op deze case?

Leg uw technische knelpunt of onderzoeksvraag voor. We vergelijken uw situatie met de WBSO-criteria en geven een eerste inhoudelijke inschatting.

Bespreek mijn project Meer voorbeelden

BRONNEN EN INHOUDELIJKE CONTROLE

RVO — Handleiding WBSO 2026

Gecontroleerd door Peter Klaren, WBSO-specialist sinds 2004. Laatst inhoudelijk bijgewerkt: 21 september 2026. Deze case is samengesteld en geanonimiseerd.