WBSO en softwareontwikkeling: balanceren tussen wetgeving en werkelijkheid

De Wet Bevordering Speur- en Ontwikkelingswerk (WBSO) is een populaire regeling voor innovatieve bedrijven. Het biedt fiscaal voordeel op uren die besteed worden aan technisch nieuwe ontwikkelingen. Maar wie zich in de praktijk bezighoudt met softwareontwikkeling merkt al snel dat er een spanningsveld ontstaat: de WBSO is gestoeld op het idee van duidelijke, afgebakende projecten, terwijl software zich juist bij uitstek ontwikkelt via iteratie, voortschrijdend inzicht en agile werkwijzen. Hoe vind je in die dynamiek de juiste balans?

Een gestructureerde regeling binnen een flexibele ontwikkelpraktijk

De WBSO (programmatuurontwikkeling) verlangt van aanvragers dat zij hun werkzaamheden vooraf structureren in projecten met een duidelijke technische doelstelling. De werkzaamheden moeten technisch nieuw zijn voor de organisatie, programmeertaalgericht, en voortvloeien uit concrete technische knelpunten. Vanuit wet- en regelgeving is dat volkomen logisch: het maakt de regeling toetsbaar, controleerbaar en juridisch houdbaar.

Tegelijkertijd is softwareontwikkeling zelden zo lineair. Ontwikkelaars starten met een hypothese, bouwen een eerste versie, testen met gebruikers, en sturen bij. Er ontstaan nieuwe inzichten, edge cases en technische uitdagingen die pas zichtbaar worden bij het daadwerkelijk bouwen. Juist dit iteratieve karakter maakt softwareontwikkeling krachtig — maar schuurt met het projectmatige karakter waar de WBSO op is gebaseerd.

Vooruit plannen in een iteratieve werkelijkheid

Een van de grootste uitdagingen bij het opstellen van een WBSO-aanvraag is: hoe ver kun en moet je vooruitkijken? RVO verwacht een heldere, afgebakende projectstructuur. Maar als ontwikkelaars weten dat de gekozen architectuur waarschijnlijk meerdere keren zal veranderen -of dat de technische uitdaging zich pas écht toont bij schaalvergroting- is het lastig om dat allemaal vooraf te voorspellen.

Kies je voor kortlopende projecten van een paar maanden, dan behoud je meer flexibiliteit. Je kunt sneller bijsturen en beter aansluiten bij de daadwerkelijke voortgang. Het nadeel is dat dit het WBSO-aanvraagproces intensiever maakt: er zijn vaker updates nodig, meerdere projectbeschrijvingen moeten worden opgesteld en ingediend, en de samenhang tussen projecten kan versnipperd raken. Ga je voor een langere projectduur (6-12 maanden), dan is de kans groter dat de realiteit afwijkt van het oorspronkelijke plan. Bij voortschrijdend inzicht kunnen technische keuzes veranderen, of zelfs nieuwe knelpunten ontstaan. Het risico is groter  dat RVO bij beoordeling vraagtekens zet bij de scope van het project — bijvoorbeeld omdat de gekozen oplossingsrichting te algemeen blijft, of niet voldoende technisch onderbouwd blijkt in relatie tot het oorspronkelijk geschetste probleem.

Iteratie versus toetsbaarheid

Een ander spanningsveld zit in de verantwoording. RVO kijkt bij controle of de beschreven technische uitdagingen daadwerkelijk zijn onderzocht en opgelost — op een manier die past bij de oorspronkelijke aanvraag. In een agile omgeving, waarin de backlog continu wordt aangepast, moeten ontwikkelaars dus scherp blijven documenteren welke iteraties technisch relevant waren en waarom.

Dat vereist discipline. Niet alleen in de urenregistratie, maar vooral in het vastleggen van de technische context: wat was het probleem, waarom was de gekozen oplossing onzeker, en wat was de uiteindelijke implementatie? Voor veel teams is dit geen natuurlijke werkwijze. Het vraagt om een brug tussen ontwikkelpraktijk en subsidietaalkundige verslaglegging.

Slim omgaan met WBSO in een iteratieve praktijk

Hoe kun je hier als organisatie goed mee omgaan? Enkele lessen uit de praktijk:

1. Werk met modulaire deelprojecten. Splits grotere ontwikkeltrajecten op in logische, technische subprojecten die elk een eigen uitdaging adresseren. Zo blijf je binnen het WBSO-kader zonder de iteratieve werkwijze op te geven.
2. Houd de scope technisch. Vermijd functionele doelstellingen zoals “het bouwen van een dashboard”, en focus op technische onzekerheden, zoals “de ontwikkeling van een technische orkestratielaag die het mogelijk maakt om verschillende technologieën en subsystemen effectief met elkaar te laten communiceren en samenwerken binnen één consistent softwarelandschap”.
3. Blijf kritisch evalueren. Kijk elk kwartaal of je projecten nog passen bij de realiteit, en pas indien nodig de aanpak of scope aan — binnen de mogelijkheden van de regeling. Beslis op tijd of een wijziging van de aanvraag nodig is, bijvoorbeeld wanneer de gekozen oplossingsrichting wijzigt of er nieuwe technische knelpunten ontstaan.
4. Maak slim gebruik van bestaande ontwikkeladministratie. Richt systemen als Jira, GitHub of GitLab zó in dat ze niet alleen de voortgang van softwareontwikkeling ondersteunen, maar ook bruikbaar zijn voor WBSO-verantwoording. Door labels, branches of commentaren te koppelen aan technische knelpunten en oplossingsrichtingen, ontstaat een directe link tussen de ontwikkelpraktijk en de subsidieverantwoording.

Tot slot

De kracht van de WBSO zit in de stimulans voor technische innovatie. De kracht van softwareontwikkeling zit in het iteratieve, het onvoorspelbare. Juist op het snijvlak van die twee werelden moet een balans gevonden worden. Dat vraagt niet alleen om technisch inzicht, maar ook om vertaalvermogen — van de dynamiek van een sprint naar de kaders van een subsidieregeling.

Benieuwd hoe jouw organisatie deze balans optimaal kan benutten? Of worstel je met het vertalen van je agile werkwijze naar een WBSO-proof aanvraag? Wij denken graag met je mee. Neem vrijblijvend contact op en ontdek wat er mogelijk is.