Matching algorithm
Existing algorithms do not suffice at the required dataset size and latency. The company develops a new partitioning and scoring method.
BOTTLENECK → OWN DIRECTION → TECHNICAL PROOF
SOFTWARE · SAAS · ALGORITHMS · AI
WBSO software: when is software technically new?
With software, the line between building and developing is the hardest to draw. RVO does not look at the system, but at the technical problem and the new operating principle you realise in code. Software development can qualify for WBSO when you develop technically new software yourself, solve concrete programming bottlenecks in doing so, and record the new information-technology operating principle in a formal programming language. A new functionality, application or user experience alone is not sufficient.
BY PETER KLAREN · UPDATED 19 SEPTEMBER 2026 · SOURCE: RVO WBSO GUIDE 2026
ON THIS PAGE
When does software development qualify for WBSO?
There must be technical risks or uncertainties, and the solution must not be easily achievable with existing technology. For software, RVO explicitly assesses whether you develop technically new software in a formal programming language yourself, identify programming problems and solve them yourself.
01
Technical goal
What must be made technically possible?
02
Programming bottleneck
What is technically not possible with existing technology?
03
Own solution direction
Which technically new software do you develop yourself?
04
Realising the operating principle
In which programming language is the principle realised and tested?
Software must be developed in a formal programming language
A model, architecture, algorithm or technical description can be highly innovative intellectually, but that alone does not automatically fall under WBSO software development. The qualifying development work must be realised in software in a formal programming language. The same applies to an algorithm: merely formulating it is not sufficient; it must actually be realised in software.
| Situation | Sufficient for WBSO? |
|---|---|
| Working out a new optimisation algorithm mathematically | Not sufficient on its own |
| Actually developing the algorithm in, for example, Python, C++ or Rust, solving programming bottlenecks to achieve the desired performance | Possibly WBSO |
Technically new versus functionally new
This is the most important distinction in software WBSO. RVO makes this distinction explicit: building a new functionality based on available technology is not technically new software.
| Software development | Probably WBSO? | Why |
|---|---|---|
| Building a new user interface | Usually not | Functionally new, no technical development. |
| New SaaS feature with existing framework components | Usually not | Known technology is being applied. |
| New matching algorithm because existing methods do not meet performance requirements | Possible | Programming bottleneck with uncertain feasibility. |
| Configuring a new database environment | Usually not | Application of existing technology. |
| Own data structure/indexing method due to latency or memory limits | Possible | Technically new operating principle. |
| Connecting two existing systems via an API | Usually not | Implementation/integration of existing technology. |
| Own real-time protocol because available protocols do not meet latency | Possible | Concrete technical bottleneck. |
| Training a new AI model with an existing framework | Not on its own | Application of existing technology. |
Your software product is not the WBSO project problem
RVO itself gives the example: the project is a system that plans routes; the information-technology problem is that the existing algorithm does not meet the required specifications.
Not sufficient: “We are developing a new SaaS platform.”
Concretely better: “The current search structure requires linear comparison of 15 million records, pushing response time above 800 ms; available indexing methods do not fit within our memory limit.”
When can algorithm development be WBSO?
What is decisive is not thinking up an algorithm, but the software development with which a technical bottleneck is solved. Relevant categories include:
route planningmatchingschedulingconstraint solvingsearch/indexingcompressionimage processingreal-time optimisationanomaly detectionresource allocation
Matching platform
Goal: Compare 250,000 candidates in real time. Bottleneck: the existing matching approach does not scale beyond 50,000 records within the required latency. Solution direction: a new partitioning and scoring method. Uncertainty: it is not known in advance whether the desired recall and latency are simultaneously achievable.
Performance and scalability
Does a proven approach demonstrably break down at your volumes? Concrete measurable bottlenecks make an application stronger:
| Category | Example |
|---|---|
| Latency | From 800 ms to <50 ms. |
| Throughput | 100 transactions/sec → required 10,000/sec. |
| Memory | Dataset no longer fits within available memory. |
| Concurrency | Deadlocks/race conditions at high parallelisation. |
| Storage | Existing indexing becomes exponentially too heavy. |
| Real time | Event processing must take place within 5 ms. |
Important nuance: a heavy performance requirement is not in itself WBSO. The point is that existing techniques demonstrably fall short and you must develop a technically new software solution yourself. Also relevant for developers working independently: WBSO for self-employed professionals.
Distributed systems and real-time processing
WBSO can become relevant for new solutions for:
distributed consensusconcurrencydata consistencyfault tolerancestate replicationreal-time synchronisationdistributed schedulingmessaging under hard latency requirements
Please note: applying Kafka, Kubernetes, Redis, PostgreSQL replication or an existing consensus protocol is not in itself technically new software. The technical uncertainty must lie in what you newly develop yourself, not in the fact that the architecture is complex.
Embedded software
Embedded software can align well with the WBSO criteria when hard constraints in timing, memory, energy consumption or hardware interaction lead to concrete programming bottlenecks for which no known solution is available.
real-time motor controlsensor fusionmemory-constrained deviceslow-power schedulingreal-time machine communicationFPGA/MCU interaction
RVO itself cites real-time synchronisation and adjustment of machines with own software in C as possible R&D.
AI, machine learning and computer vision
In the 2026 Guide, RVO gives the example of a company using TensorFlow to train a model: because no own software development takes place, that is not technically new software. At the same time, RVO cites self-developed bots/AI technology in Python and R as possible R&D.
| AI activity | WBSO software? |
|---|---|
| Integrating the OpenAI, Anthropic or Gemini API | Usually not |
| Prompt engineering | Not on its own |
| Fine-tuning an existing model | Not automatically |
| Using TensorFlow/PyTorch and training a standard model | Not automatically |
| Own technically new inference pipeline due to latency/memory problems | Possible |
| Own algorithmics for model compression or scheduling | Possible |
| Self-developed technically new software for multimodal processing | Possible |
| Building a RAG app with a standard vector database and framework | Usually not for that reason alone |
| Own indexing/retrieval method due to a demonstrable technical problem | Possible |
APIs, databases and integration
Technically new integration or collaboration of existing software components can possibly be R&D, but those components must mainly have been developed in-house and already be applied within the company.
Usually no WBSO
- Using a REST/GraphQL API
- connecting existing SaaS systems
- transforming data
- webhook integrations
- configuring middleware
Possibly yes
If the technical challenge lies in a self-developed new communication or collaboration principle and the other conditions are met.
RVO contrast: real-time synchronisation of machines via own C software can possibly be R&D, whereas connecting machines via available APIs is not technically new software.
What usually does and does not fall under WBSO software?
Possibly WBSO
- own technically new algorithmics
- new real-time processing
- new data indexing method
- technically new synchronisation
- embedded software with hard constraints
- new compression, scheduling or processing method
- own AI infrastructure with a programming bottleneck
Usually no WBSO
- standard CRUD applications
- front-end
- dashboards
- CMS configuration
- standard API connections
- implementation of libraries
- cloud migration
- standard database configuration
- functional design
- architecture documentation
- prompt engineering
- model training alone
- first use of a new technology
RVO explicitly states that learning to use a development environment that is new to the company is not R&D: “first use” is seen as a learning phase.
Examples of WBSO software development
The following situations illustrate where software development can become technically uncertain. They are anonymised example situations, not claims about specific clients.
Real-time machine control
Available protocols produce too much jitter. The company develops its own real-time synchronisation software.
BOTTLENECK → OWN DIRECTION → TECHNICAL PROOF
Embedded sensor
Memory and energy constraints prevent the existing approach. The company develops a new low-power processing routine.
BOTTLENECK → OWN DIRECTION → TECHNICAL PROOF
Distributed database
Existing replication strategies provide an insufficient consistency-latency combination. The company develops its own consistency mechanism.
BOTTLENECK → OWN DIRECTION → TECHNICAL PROOF
Computer vision
The existing inference pipeline does not achieve the required frame rate on edge hardware. The company develops a new processing routine.
BOTTLENECK → OWN DIRECTION → TECHNICAL PROOF
AI/RAG retrieval
Standard retrieval provides insufficient precision within the latency and memory budget. The company develops its own indexing and ranking technique.
BOTTLENECK → OWN DIRECTION → TECHNICAL PROOF
See also WBSO examples and the compiled WBSO cases.
How do you describe software in a WBSO application?
In the official project form, RVO explicitly asks about programming languages, development environments, tools, technical novelty, risks and uncertainties.
- Technical goal: what must be made technically possible?
- Programming bottleneck: what is technically not possible?
- Existing technology: why do frameworks/libraries not solve this?
- Solution direction: what will you technically develop yourself?
- Technical uncertainty: why is it not certain in advance that it works?
- Software: in which language/environment is the principle realised?
Use the extensive guide for a strong WBSO project description and the step-by-step plan for applying for WBSO.
Project records for software
Git history, tickets and technical designs are a good basis. Extend this with:
- commits and pull requests;
- issue tracker;
- technical experiments;
- benchmark results;
- performance profiles;
- test logs;
- architecture decision records;
- prototypes;
- measurement results;
- documentation of failed solution directions.
Not everything has to be present. The point is that the records make visible which technical work was actually carried out. View the full requirements at WBSO project records.
WBSO software in 2027: what might change?
The government is currently investigating how the WBSO can better align with developments in AI and modern software development. The precise changes have not yet been established. As soon as new criteria are known, we will update this page.
Frequently asked questions about WBSO software
When is software technically new?
When you develop a new information-technology operating principle yourself and realise it in a formal programming language, solving concrete programming bottlenecks.
Is a new app or feature automatically WBSO?
No. An innovative app is not automatically WBSO. The question is which information-technology problem you solve yourself and which technically new operating principle you actually realise in software.
Can training an AI model be WBSO?
Training a standard model with an existing framework is not in itself technically new software. Own technically new software around it can qualify.
Does API integration qualify for WBSO?
Usually not. Only when the technical challenge lies in a self-developed new communication or collaboration principle can this possibly qualify.
Must software be written in a specific programming language?
No, but the operating principle must be realised in a formal programming language; an idea or algorithm on paper alone is not sufficient.
Does performance optimisation qualify as WBSO?
Only when existing techniques demonstrably fall short and you must develop a technically new software solution yourself.
What does not count as R&D in software?
Including standard CRUD applications, front-end, dashboards, CMS configuration, standard API connections and learning to use a new development environment (first use).
Want to know whether your software project qualifies for WBSO?
Have it assessed without obligation which information-technology problem you solve and which technically new operating principle you actually realise in software.
SOURCES AND SUBSTANTIVE REVIEW
Reviewed by Peter Klaren, WBSO specialist since 2004. Last substantively updated: 21 September 2026.