Scale-up tooling rond Utrecht Science Park
Software-scale-ups rond Utrecht bouwen vaak hun eigen interne ops-tooling toen ze tien man waren. Op vijftig man is dat een liability geworden. Vier signalen dat je interne systeem aan een fix of vervanging toe is.
Rond Utrecht Science Park en de stad zelf zit een dichte concentratie software-scale-ups, vaak voortgekomen uit een UU- of HU-traject of een spin-off van een vroeg-fase product-team. Een terugkerend patroon: in de begintijd is iemand uit het team een keer een eigen admin-panel begonnen. Daarna kwam er een klant-dashboard bij, een factuur-generator, een mini-CRM, een interne tool voor onboarding. Op tien man was dat sneller dan elke SaaS, en het paste precies bij hoe het bedrijf werkte. Op vijftig man is het iets anders geworden. De vraag is niet "wat is er mis met onze tooling", de vraag is of de kosten van die zelfgebouwde laag inmiddels groter zijn dan de waarde.
Vier signalen waar wij op letten als we bij een scale-up binnenkomen.
Het eerste is knowledge-silo bij één engineer. "Joep heeft het gebouwd, alleen Joep weet hoe het werkt." Joep is geen probleem zolang hij blijft, maar elke vakantie wordt een mini-incident en elke nieuwe feature wacht op zijn agenda. Wanneer een systeem alleen door één persoon onderhouden kan worden, is dat geen technisch probleem maar een bedrijfsrisico. Een audit van de tool met een tweede engineer erbij, gevolgd door documentatie en een test-suite, haalt het meeste van die afhankelijkheid weg zonder dat je het hele ding hoeft te vervangen.
Het tweede is downtime bij een minor change. Een kleine deploy gaat fout, en een halve dag ops-werk valt stil. Klant-support kan geen tickets afhandelen, finance kan geen factuur maken, sales kan geen demo-omgeving optuigen. Dat is het signaal dat de tool een single point of failure is geworden voor processen die er omheen gegroeid zijn. Een staging-omgeving, feature-flags, en een rollback-pad die getest is, lossen het meeste op.
Het derde is integraties die alleen via die ene developer lopen. Een nieuwe SaaS-tool koppelen kost twee weken omdat het interne systeem geen externe input accepteert, of alleen via een endpoint dat ooit voor een ander doel is gebouwd. Wanneer je integraties tijd kosten in weken in plaats van uren, is dat geen flexibiliteit meer maar een rem op het bedrijf.
Het vierde is onboarding-tijd van nieuwe engineers op het systeem boven twee weken. Niet "tot ze productief zijn op de hele codebase", maar tot ze een eerste kleine wijziging veilig in productie hebben gezet. Als dat meer dan twee weken kost, is de code te eigenwijs voor zijn omvang.
Waar deze aanpak niet helpt: als de scale-up duidelijk richting een ander product-model gaat (bijvoorbeeld een platform-shift of een overname) waarbij de bestaande tooling toch verdwijnt. In dat geval is een korte-termijn-stabilisatie zinvoller dan een rationalisatie-traject. Niet alles intern bouwen of alles inkopen; gericht beslissen waar je je eigen tooling rationaliseert en waar je beter naar een SaaS overstapt.
Bouw je een product rond Utrecht en herken je een paar van deze signalen? Lees [wat we voor scale-ups in Utrecht doen](https://www.vectel.nl/regio/utrecht), of bekijk onze [Development-aanpak](https://www.vectel.nl/services/development) als je wil sparren over wat je het eerst zou aanpakken.