Van WUR-prototype naar productie in Wageningen
Agritech-spin-offs en WUR-startups hebben vaak een mooi prototype, gebouwd door een of twee onderzoekers. Bij commercialisering loopt dat vast. Vier valkuilen die wij telkens terugzien, en hoe je het prototype behoudt zonder de productiediscipline op te geven.
Wageningen blijft de natuurlijke uitvalsbasis voor agritech, food-science en biotech. Veel jonge bedrijven die hier opstarten, vaak voortgekomen uit een WUR-onderzoekstraject of een PhD-project, beginnen met een prototype dat door een of twee onderzoekers is gebouwd. Het werkt op een laptop, het levert prachtige resultaten op de test-dataset, en het demo't goed bij investeerders. Dan komt de eerste betalende klant, of de eerste pilot in een productielocatie, en het hele bouwsel kraakt. Niet omdat de wetenschap fout was, maar omdat een prototype geen software is.
Vier valkuilen kom je vrijwel altijd tegen.
De eerste is code zonder tests. Elke nieuwe feature is automatisch ook een regressie-risico, omdat er geen vangnet is dat aangeeft dat het oude gedrag nog klopt. Voor onderzoek is dat acceptabel, daar telt alleen dat het experiment klopt. Voor een klant die er morgen op moet draaien is het de garantie dat de derde release iets stuk maakt zonder dat iemand het merkt. Een eerste tranche unit-tests rondom de kern-algoritmes, plus integratietests op de pipeline, vangt het meeste op.
De tweede is geen CI/CD. Deploys gaan met de hand vanuit de IDE van de onderzoeker. Werkt zolang de onderzoeker beschikbaar is en zich elke stap herinnert. Werkt niet als er een tweede engineer bijkomt, als er een productie-incident is op vrijdagavond, of als de onderzoeker een paper aan het afronden is. Een eenvoudige GitHub Actions of GitLab CI-pipeline die test en deployt zet je in een dag op en haalt veel ongelukken weg.
De derde is data-pipelines die alleen op één laptop draaien. Hardgecodeerde paden naar lokale mappen, scripts die afhangen van een specifieke Python-versie of een R-installatie, een Jupyter-notebook dat eerst handmatig in de juiste volgorde moet worden uitgevoerd. Wanneer een nieuwe engineer of de productieomgeving de pipeline niet zonder een halve dag prutsen kan reproduceren, is dat de pipeline en niet de engineer. Container, requirements lock-file, expliciete data-paden, en een orchestratie-laag (Prefect, Airflow, of vaak gewoon Make) is de minimale upgrade.
De vierde is lock-in op research-tooling die niet productie-geschikt is. Jupyter notebooks die als productiecode dienst doen, R-scripts zonder packaging, een Streamlit-dashboard waar de hele klant-interactie doorheen loopt. Voor exploratie zijn die tools prima, voor productie hebben ze geen security-isolatie, geen versioning, en geen monitoring. De kern-algoritmes blijven in Python of R, maar er komt een productie-laag omheen die wel multi-user is en wel iets te zeggen heeft over uptime.
Waar deze aanpak niet helpt: als het prototype zelf niet klopt. Software-discipline bovenop een algoritme dat nog niet wetenschappelijk staat, is geld in een put. Eerst de research afhechten, dan de productie-jas eromheen. Behoud van de research-discipline blijft het doel; we voegen alleen toe wat de stap naar betalende klanten haalbaar maakt.
Werk je in een WUR-spin-off of agritech-bedrijf en herken je de overgang van prototype naar productie? Lees [wat we voor MKB in Wageningen doen](https://www.vectel.nl/regio/wageningen), of bekijk onze [Development-aanpak](https://www.vectel.nl/services/development) als je wil sparren over een concrete eerste stap.