How Companies Structure Projects to Maximize WBSO

March 6, 2026

Ricardo Benitez

639593931_10164065725754729_3095225003728549460_n

The WBSO (Wet Bevordering Speur- en Ontwikkelingswerk) is one of the most valuable innovation incentives available to companies in the Netherlands. It reduces wage tax for employees involved in research and development, helping organizations invest more in technological innovation.

However, many companies do not fully benefit from the WBSO—not because they lack innovation, but because their projects are not structured in a way that clearly distinguishes research from routine development work.

Understanding how to properly structure R&D projects can significantly increase the portion of work that qualifies for WBSO.

The Core Principle: R&D vs Routine Development

The WBSO supports technical research and experimentation, not standard implementation work.

Typical WBSO-eligible activities include:

Developing new algorithms or architectures
Solving technical uncertainties in software or engineering
Designing new system architectures
Experimental prototyping and validation

Activities that are usually not eligible include:

Standard feature development
UI implementation
Integrations with existing software
Maintenance or bug fixing

Because of this distinction, the way a project is organized internally matters greatly.

Structuring Projects Around Technical Uncertainty

Successful WBSO projects typically start by clearly defining technical bottlenecks (technische knelpunten). Instead of describing work as building a product, companies frame projects around the technical problems that must be solved.

Less effective framing

“Developing an AI-powered document processing system.”

Stronger WBSO framing

“Developing a scalable architecture for semantic document retrieval capable of handling unstructured multilingual datasets with explainable output.”

The second formulation highlights the technical challenges, which is what WBSO evaluates.

Separating R&D from Implementation Work

A practical strategy used by many companies is to separate project phases:

Phase 1 — R&D (WBSO eligible)

Research and experimentation aimed at solving technical uncertainties:

Designing AI architectures
Testing new algorithms
Prototyping data pipelines
Performance experiments

Phase 2 — Product Development (non-WBSO)

Once the technical challenges are solved, development shifts toward:

Feature implementation
UI development
Integrations
Deployment pipelines

This separation ensures maximum clarity for the RVO evaluation process.

Structuring Teams for Efficiency

Another strategy companies use is splitting responsibilities across specialized teams.

R&D Team focuses on:

algorithms
system architecture
technical experimentation

Engineering Team focuses on:

product implementation
APIs
integrations
front-end development

This structure makes WBSO documentation clearer and allows companies to allocate resources more efficiently

Why This Matters for Cost Efficiency

Companies that structure their projects strategically often see two benefits:

Higher WBSO utilization – More R&D hours qualify for the tax credit.

Lower development costs – Routine engineering work can be optimized through external development teams or specialized partners.

This approach allows organizations to focus internal resources on innovation while maintaining cost-effective delivery.

To Wrap Up

Maximizing the value of the WBSO is not only about writing strong applications—it also depends on how projects are organized internally. By clearly separating research activities from routine development work, companies can both:

increase the likelihood of WBSO approval
improve the efficiency of their development process

For organizations investing heavily in technology and software development, structuring projects with this in mind can make a significant difference in the return on innovation investment.