What does “technically new” mean?
Technically new means that the development is new to your company from a technical perspective: 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 route to the result, not the result itself — an end product can be completely new to the market yet not technically new for WBSO, for example if it can be assembled using existing components.
Important: “new to your company” is not the same as “new to the world”. The fact that a competitor built something similar does not in itself exclude your WBSO — provided you did not have access to that solution and had to overcome the technical risks yourself.
Technically new versus functionally new
This is the most common source of confusion. Functionally new means the user gains new capabilities. Technically new means that programming or engineering problems must be solved for which no ready-made approach exists.
- A dashboard with new reports is functionally new; if you build it using standard components, it is not technically new.
- A dashboard that must match millions of combinations in real time within 200 ms, requiring you to develop your own algorithm, is also technically new.
The technical bottleneck
A bottleneck is technical when it reaches the limits of what known techniques can do: performance, accuracy, thermal behaviour, stability, scalability or deep integration. A typical characteristic is that several possible solution approaches exist, each carrying technical risk — and that you must develop and test to find out which one works.
Typical characteristics of a genuine bottleneck
- The requirement goes beyond what standard technology provides (latency, tolerance, temperature range, accuracy).
- There are several possible solution approaches, each with technical uncertainties.
- You need to experiment, prototype or measure to determine whether it will work.
- A failure can be explained technically; it is not simply a matter of working harder.
Technical uncertainty in advance
The uncertainty must exist before you start. If the solution afterwards turns out to have been “actually quite simple”, that can still be compatible — the question is whether the outcome was uncertain beforehand. Therefore record: what requirements you set, why the bottleneck appeared difficult, which alternatives you considered and why standard technology was insufficient. That documentation is precisely what makes both an application and a later audit assessable.
Examples: does this situation qualify?
- Yes: a matching algorithm that must remain within 200 ms with 10× as many combinations — existing database indexes are insufficient.
- No: an online shop connecting Shopify to an existing API.
- Yes: positioning to ±0.05 mm where thermal deformation has so far prevented this.
- No: building the same machine in a larger version.
- Yes (technical-scientific 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 by project type: WBSO examples.
By project type
- Software & programming — 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 an immediate application objective.
Unsure whether your project is technically new?
A short conversation with Peter Klaren quickly provides direction — without obligation.
Have your project assessed without obligation →
SOURCES AND SUBSTANTIVE REVIEW
RVO — WBSO Guide 2026
Reviewed by Peter Klaren, WBSO specialist since 2004. Last substantively updated: 21 September 2026.