WBSO CASE · SOFTWARE

SaaS platform with own matching algorithm

From 2 to 20 million combinations within 200 ms. This case shows where available technology fell short, what was developed in own software and where the R&D delineation lay.

SaaS-platform met eigen matching-algoritme

SUBSTANTIVELY ASSESSED BY PETER KLAREN · LAST CHECKED SEPTEMBER 2026 · BASED ON WBSO GUIDE 2026

Representatieve case: this file has been compiled on the basis of common WBSO situations and anonymised; it is not a literal representation of one client file.

Case in eleven phases

The company and starting situationA SaaS company operates a matching platform that links candidates and assignments in real time. Due to growth of the platform, the number of combinations to be assessed rises from 2 to 20 million per assignment.

The technical goalMaintaining matching within a maximum of 200 ms latency (P95) and a memory budget of 4 GB per node, with a tenfold increase of the data volume.

The programming-technical bottleneckThe existing indexing and query structure assesses each new input against too large a part of the dataset. With 20 million combinations, the scoring time exceeds the latency limit and the cache hit ratio drops sharply.

Why known technology fell shortExisting libraries, read replicas, caching and regional sharding have been tried. The benchmark suite showed that the core problem remained computational: the comparison method itself does not scale. Configuration does not solve a computational problem.

Investigated solution directions(a) Own partitioning structure that divides the dataset into precalculated buckets. (b) Incremental scoring that only recalculates deltas. (c) Approximating preliminary phase with exact recalculation for the top candidates.

Programming work and experimentsThe new structure and scoring was designed, realised in a formal programming language (Rust) and iteratively tested. The benchmark suite ran on production-representative datasets; profiling results guided the optimisation rounds.

Technical resultP95 latency of 180 ms with 20 million combinations and 3.2 GB memory per node, with retention of match quality. The new information-technology operating principle was thereby demonstrated.

What qualified as R&DDesigning and realising in software and iteratively testing the own heuristic and data structure. Benchmarks served to establish whether the new operating principle actually functioned. An algorithm or architecture alone would not have been sufficient.

What did not qualifyUX and front-end work, standard API integrations, cloud configuration, database migrations and documentation for users.

Where the WBSO project endedWhen the benchmarks demonstrated that the new operating principle met the latency and memory requirements, the development process ended. Productisation, hardening and rollout fell outside it.

Which project records belonged to itGit history with technical commit descriptions, issue tracker, benchmark reports, profiling results and design notes (architecture decision records).

How this translates to a WBSO application

Element	Content
Technical goal	real-time matching at 10× data volume, P95 ≤ 200 ms, ≤ 4 GB per node
Programming-technical bottleneck	existing index and query structures exceed latency and memory limits
Oplossingsrichting	own partitioning plus incremental and approximating scoring
Technische onzekerheid	uncertain whether response time is achievable without substantial quality loss

Verdieping: WBSO software and computer programs · project records for software (Git, issues, benchmarks)

Does your project resemble this case?

Present your technical bottleneck or research question. We compare your situation with the WBSO criteria and give a first substantive assessment.

Discuss my project More examples

SOURCES AND SUBSTANTIVE REVIEW

RVO — WBSO Guide 2026

Reviewed by Peter Klaren, WBSO specialist since 2004. Last substantively updated: 21 September 2026. This case has been compiled and anonymised.