WBSO · CORE CONCEPT

Technically new for WBSO

“Technically new” is the concept on which almost every WBSO assessment turns. RVO assesses per project whether you solve a technical bottleneck that is new for your company and whose solution was not established in advance. This page sets out exactly what that means — with examples that do and do not qualify.

What does “technically new” mean?

Technically new means that the development is new for your company on a technical level: you do not know in advance how you will solve the technical problem, and existing technology does not solve that bottleneck. It is about the path to the result, not the result itself — an end product can be completely new to the market and still not be technically new for WBSO, for example if it can be assembled from existing components.

Important: “new for your company” is not the same as “new to the world”. The fact that a competitor built something similar does not preclude your WBSO — as long as you yourself had no access to that solution and had to bridge the technical risks yourself.

Technically new versus functionally new

This is the most common confusion. Functionally new means: the user gets new capabilities. Technically new means: programming or construction-technical problems have to be solved for which no ready-made approach exists.

• A dashboard with new reports is functionally new; if you build it with standard components, it is not technically new.
• A dashboard that has to match millions of combinations in real time within 200 ms, for which you have to develop your own algorithm, is also technically new.

The technical bottleneck

A bottleneck is technical when it touches the limits of what known techniques can do: performance, accuracy, thermal behaviour, stability, scalability, deep integration. Characteristic is that you have several solution directions in advance, each carrying risks — and that you have to find out through development which one works.

Typical characteristics of a real bottleneck

• The requirement lies outside what standard technology offers (latency, tolerance, temperature range, accuracy).
• There are several possible solution directions, each with technical uncertainties.
• You have to experiment, prototype or measure to know whether it succeeds.
• A failure is technically explicable, not a matter of working harder.

Technical uncertainty in advance

The uncertainty must exist voórdat u begint. If the solution afterwards turned out to be “actually simple”, that is fine — the question is whether the result was not established in advance. Therefore record: which requirements you set, why the bottleneck seemed difficult, which alternatives you considered and why standard technology fell short. Precisely that recording makes an application and a later audit assessable.

Examples: does this situation qualify?

• Yes: a matching algorithm that has to stay within 200 ms with 10× as many combinations — existing database indexes fall short.
• No: a webshop connecting Shopify to an existing API.
• Yes: positioning to ±0.05 mm where thermal deformation has so far prevented that.
• No: building the same machine in a larger version.
• Yes (research): systematic research into unexplained crystallisation behaviour under new process conditions.
• No: an app with new features that can be built entirely with existing frameworks.

More examples per project type: WBSO examples.

Per project type

• Software — algorithms, performance, data processing, embedded software.
• Product development — prototypes, new operation, integration of new technology.
• Process development — capacity, tolerances, new materials.
• Technical scientific research — explanatory research without a direct application purpose.

SOURCES AND SUBSTANTIVE REVIEW

RVO — WBSO Guide 2026

Reviewed by Peter Klaren, WBSO specialist since 2004. Last substantively updated: 21 September 2026.