WBSO voor software- en ICT-ontwikkeling

Softwareontwikkeling valt onder de WBSO-categorie "ontwikkelingsproject programmatuur". Maar niet elk softwareproject kwalificeert. Deze pagina legt uit waar de grens ligt.

Wanneer is software WBSO-waardig?

Voor programmatuur draait het om informatietechnologisch nieuwe werkingsprincipes. Deze elementen moeten samen aanwezig zijn:

1. 1Er is een technisch knelpunt waarbij bestaande kennis, technieken of marktoplossingen tekortschieten
2. 2Er is een reëel risico dat het mislukt: je kunt terug naar de tekentafel moeten
3. 3Je ontwikkelt het zelf, en legt dat vast in een formele programmeertaal (dus niet no-code)
4. 4Het is voorgenomen en planmatig: je hebt vooraf een beoogd werkingsprincipe en oplossingsrichtingen voor ogen

Dat vierde punt wordt vaak onderschat. Mislukken mag. Maar doelloos doorproberen tot het werkt valt buiten de regeling: de WBSO vraagt om voorgenomen, planmatig werk.

Als ontwikkelaars en ondernemers (waar we onszelf ook onder scharen) kijken we daar vaak net wat anders tegenaan. Problemen zijn er om op te lossen, en we beschrijven ze zeker niet met woorden als "technische knelpunten die om ontwikkeling van een oplossing voor een vooringenomen, informatietechnologisch nieuw werkingsprincipe vragen".

Levert het werk programmeercode op die een nog onbewezen werkingsprincipe moet aantonen? Dan zit je in de goede richting. Zodra het werkingsprincipe is aangetoond, stopt het S&O-werk.

In dit artikel gaan we wat meer de diepte in om uit te leggen hoe het zit.

Wat wél in aanmerking komt

• Technisch ontwerpen, ontwikkelen en technisch testen, tot het werkingsprincipe is aangetoond
• Mislukte pogingen en proofs of concept die niet werkbaar bleken
• Voorwaardelijk ondersteunend werk: omliggende code die noodzakelijk is om te kunnen testen waarvoor je WBSO aanvraagt
• Legacy-modernisering met echte technische onzekerheid, bijvoorbeeld rondom schalingsproblematiek
• Eigen algoritmen en zelfontwikkelde constructies rond bestaande technologie, zoals een eigen library, framework of vector-database

Wat niet in aanmerking komt

• Bestaande componenten, systemen of API's aan elkaar koppelen of configureren
• Toepassen, samenstellen of implementeren van bestaande programmatuur
• No-code werk of puur prompten zonder zelf te programmeren
• UI- en UX-werk, nieuw frontend-design, een nieuwe mobiele app, routinewerk in HTML en CSS
• Functioneel testen en acceptatietests
• Onderhoud, bugfixes en doorontwikkeling nadat het werkingsprincipe is aangetoond
• Puur porten of migreren naar een ander platform, framework of de cloud met dezelfde functionaliteit
• Onderzoek zonder eigen ontwikkeling: uitzoeken wat er al bestaat, documentatie lezen, bestaande tools evalueren
• Requirements opstellen, projectmanagement, meetings en overhead

AI en machine learning

Belangrijk onderscheid: het toepassen van bestaande AI-modellen an sich is geen S&O. Dat geldt ook voor fine-tunen, prompts maken, RAG implementeren en API's aan elkaar knopen. Het ontwikkelwerk dat je eromheen bouwt kan wél kwalificeren, mits je daar tegen technische knelpunten aanloopt.