WBSO · APPLICATION

This is what a good WBSO project description looks like

The project description is the document on which your WBSO application stands or falls. RVO uses this story to assess whether your work is technically new and which hours and costs belong to it. On this page I show how such a description is structured — with an anonymised example.

Why the project description determines your chances

WBSO is a rights-based scheme with one substantive criterion: is the work technically new and do you solve bottlenecks yourself? RVO can only assess this on the basis of what you write down. A strong project described vaguely is rejected; a modest project that is cleverly substantiated gets the R&D declaration (S&O-verklaring).

A good description reads like a technical story with a narrative arc: this is what we faced, this was uncertain, this is what we came up with and this is how we started developing it.

What belongs in a project description

• The technical bottleneck: what had to happen and why did that not work with existing technology?
• The uncertainty in advance: which solution directions were conceivable and why was the result not guaranteed?
• The chosen solution direction: which approach did you choose and which alternatives were dropped?
• The activities: what did you concretely do — design, experiments, prototypes, testing.
• The hours estimate: which employees, which role, how many R&D hours per period.
• Delineation: what is R&D and what explicitly is not (production, implementation, support).

For self-employed professionals, the substantiation of the 500 R&D hours and the relationship with the business is added to that.

Example structure (anonymised)

Project: real-time matching algorithm for a B2B platform. Bottleneck: at the expected data volume, response time grew above the 200 ms requirement; existing indexing and caching offered no solution. Uncertainty: three directions — alternative data structure, pre-filtering on statistics, hybrid precomputation — each with unpredictable accuracy. Work: prototypes per direction, benchmarks, ultimately a hybrid approach with an own scoring function. Result: R&D declaration granted without an information notice.

Note the structure: bottleneck → uncertainty → choice → work. No marketing language, no product description — but the technical story behind it.

Common mistakes in project descriptions

• Describing functionalities instead of technical problems.
• Claiming market novelty where RVO wants to see technical novelty.
• Jumping straight to the solution without reasons.
• Estimating hours without substantiation per employee and period.
• Including implementation and management work that does not qualify.

In my practice I write or rewrite project descriptions daily — for new applications and in response to information notices.

SOURCES AND SUBSTANTIVE REVIEW

RVO — WBSO Guide 2026

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