Ik ben Erik de Roos, fractional CTO uit Kampen. Eigenaren van softwarebedrijven bellen me als ze voelen dát er iets moet, maar niemand er een opdracht van kan maken. Mijn werk begint daar: vaststellen wat het echte vraagstuk is, vóórdat er iemand gaat bouwen. Dat doe ik door bij je mensen te gaan zitten — in de code, op support, bij sales, en waar het kan bij je klanten.
Kies hieronder de situatie die het meest op de jouwe lijkt en zie hoe zo'n traject verloopt.
Stel
Maar wat, en wat vooral niet? Je wilt geen demo die na drie maanden stof vangt; je wilt een stap die je klanten merken.
Week 1–2
Wat weet je product al, waar zit het echte werk van je gebruikers, en waar is AI het antwoord — en waar niet?
Maand 1–2
We kiezen de kleinste AI-stap die waarde levert en bouwen die in — in je bestaande applicatie, met je eigen team.
Daarna
Een AI-koers die van jou is: wat volgt er, in welke volgorde, en wat laten we bewust liggen.
Een AI-functie in productie — geen demo.En een team dat weet hoe de volgende stap eruitziet.
Dit is geen theorie. Bij TransportPlan was de vraag "wat doen we met AI". Het antwoord bleek niet in een AI-functie te zitten maar in de laag eronder: zolang de eigen data niet veilig en gestructureerd te benaderen was, had elk AI-idee geen fundament. Die volgorde omdraaien leverde de eerste MCP-connector in de transportsector op — in de bestaande applicatie, bij betalende klanten.
Stel
Het loopt. En toch: zit er meer groei in? We kijken samen naar de kracht van je mensen, de kansen en zwakten van je product, wat de markt gaat vragen en wat je klanten je al vertellen.
Week 1–2
Gesprekken met je mensen, je cijfers, je klantfeedback. Niet om te beoordelen — om te zien wat er al is.
Week 3–4
Waar zit de groei werkelijk: in het product, in de markt, in hoe het werk georganiseerd is? En wat vraagt dat van jou?
Daarna
Twee of drie richtingen, elk met wat het oplevert en wat het kost. Jij kiest — met overzicht in plaats van onderbuik alleen.
Je weet waar de groei zit — en wat die vraagt.Of de geruststelling dat het huidige pad het juiste is. Ook dat is een antwoord.
Dit is geen theorie. Bij Topicus werd al jaren gevoeld dat er te weinig uit het team kwam, zonder dat iemand kon zeggen waarom. Ik haalde in de eerste weken data uit Jira en Bitbucket en maakte de verhouding tussen onderhoud en nieuwe waarde zichtbaar. Daarmee verschoof het gesprek van "we moeten harder" naar een besluit over waar de capaciteit heen ging — en vanaf mijn tweede periode schoof ik aan bij de productmeetings.
Stel
Je wilt een bedrijf overnemen, je koopt een partner uit, of jullie samenwerking is vastgelopen en niemand is het eens over wat het gebouwde waard is. Iedereen die aan tafel zit heeft er belang bij. Jij wilt iemand die dat belang niet heeft.
Vooraf
Cijfers, techniek, contracten, afspraken. Wat wordt er beweerd, wat is er nooit vastgelegd — en wat wordt er niet gezegd?
Aan tafel
De software, het team, de klanten. Zit de waarde in wat er gebouwd is, of ergens anders? En wat kost het om dit over te nemen of voort te zetten?
Daarna
Risico's en kansen op een rij, vertaald naar de onderhandeling: wat is het waard vóór jou — en onder welke voorwaarden.
Je weet wat er werkelijk op tafel ligt, en wat het waard is.Soms is de uitkomst: niet doen. Dat is dan een goedkope conclusie geweest.
Dit is geen theorie. Twee ondernemers met een vastgelopen samenwerking vroegen me te oordelen wie recht had op wat. In plaats daarvan liet ik ze zien dat hun tool als generiek werd gepresenteerd terwijl hij rond één specifieke klantsituatie was gebouwd, en dat de waarde niet in de software zat maar in markttoegang die ze niet hadden. Precies het soort ding dat je vóór een handtekening wilt weten.
Stel
De applicatie is instabiel, elke marktwens duurt te lang, en het team blust vooral brandjes. Hoe kom je hieruit, zonder alles stil te leggen?
Week 1–2
Ik kijk mee met de code en de incidenten, maar vooral met de mensen die ermee moeten werken — ook op support en sales. Meestal zijn het twee of drie dingen, niet twintig.
Maand 1–3
Stabiliteit eerst: de grootste brandhaarden gedoofd, releases die niet meer spannend zijn. Het bedrijf draait gewoon door.
Maand 3–6
Met de rust komt tempo: keuzes die maken dat marktwensen weer landen, geborgd in het team — niet in mij.
Van brandjes blussen naar vooruit sturen.De tijd van klantwens naar productie wordt meetbaar korter — en jij hebt weer controle.
Dit is geen theorie. Bij TransportPlan lag de vraag op tafel hoe er sneller geleverd kon worden. Het knelpunt bleek niet de bouwsnelheid maar het releasen zelf: dat ging met de hand, zonder terugweg, dus het gebeurde zo min mogelijk. Door dat om te draaien werden releases een non-event — 59 achter elkaar, zonder één mislukking. Bij Thinkwise zat het knelpunt ergens anders: een migratie die al een jaar stilstond kwam pas los toen duidelijk werd waaróm hij vaststond.
Stel
Je bedrijf draait op wat jij weet. Dat was jarenlang de kracht en is nu de rem: je team komt niet verder zonder jou, en jij komt niet los. Meer delegeren is al geprobeerd.
Week 1–2
Welke beslissingen horen echt bij jou, en welke belanden alleen bij jou omdat er niets anders is dat ze opvangt? Dat blijken twee heel verschillende lijsten te zijn.
Maand 1–2
Niet beter delegeren, maar defaults en kaders neerzetten waardoor een keuze niet meer gemaakt hoeft te worden. Wat niet op tafel komt, hoeft ook niet langs jou.
Daarna
De keuzes die bij de eigenaar horen, scherp afgebakend. De rest heeft een eigenaar, een kader of een default — en jouw week gaat weer over de dingen die alleen jij kunt doen.
Je agenda loopt niet meer vol met andermans beslissingen.En je kunt twee weken weg zonder dat er iets stilvalt.
Dit is geen theorie. Bij NS liep elke koppeling via één centrale afdeling waar we maanden op konden wachten. Ik heb die schakel nagebouwd zodat het team weer op eigen tempo verder kon — zonder dat iemand iets hoefde af te staan. Bij TransportPlan was releasen een beslissing die telkens opnieuw genomen moest worden: handmatig, zonder terugweg, dus spannend. Na de ombouw is het een handeling — 59 keer achter elkaar, zonder mislukking. Dat is het patroon: ik vraag je niet om los te laten, ik zorg dat er minder vast te houden valt.
Een developer inhuren
Het probleem is al geformuleerd. Jij weet wat er moet komen, hij bouwt het goed. Dat is waardevol werk en er zijn goede mensen voor te vinden — dit is niet waarvoor je mij belt.
Waarvoor je mij belt
Je voelt dát er iets moet — er moet iets met AI, het schaalt niet, de releases zijn spannend — maar niemand kan er een opdracht van maken. Ik stel vast wat het echte vraagstuk is, en zet de richting uit over projecten en mensen heen. Wat je koopt is niet de uitvoering, maar de kwaliteit van de beslissing en de fouten die niet gemaakt worden.
En een stap verder
Bij een fractional CTO-rol komt daar de bedrijfskant bij: wat vraagt technologie van jouw business, en je business van je technologie. Roadmap gekoppeld aan geld, zelf bouwen of kopen, wat je aan mensen nodig hebt, welk risico je loopt.
Bouwen kan ik ook, en ik doe het graag. Maar mijn doel is mezelf als developer overbodig maken: iets neerzetten dat een klasse hoger zit dan wat er stond, zodat een hele categorie werk verdwijnt en je team er zelf mee vooruit kan. Hoe ik dat doe →
De meeste bedrijven die me bellen hebben al een goede technische man. Vaak één iemand die het meeste draagt — en die juist daarom zelden iemand naast zich heeft die verder kijkt dan de volgende sprint, en weinig tegenspraak krijgt van iemand die het werk echt begrijpt.
Ik kom niet boven hem staan. Ik ga ernaast zitten: in de code, in de keuzes, in de dingen waar hij op vastloopt. Eerst om te verdienen dat hij iets van me aanneemt — dat gaat niet vanzelf en dat hoort ook niet. Daarna om de moeilijke keuzes sámen te maken, zo dat hij er zelf achter staat en ze kan uitleggen aan de rest.
Wat je daarvoor terugkrijgt is niet alleen een betere beslissing. Het is iemand die groeit in een functie waarin hij anders was uitgeleerd. Dat is meestal de goedkoopste reden waarom hij blijft.
Dit is geen theorie. Ik ken dit model van binnenuit: bij Luminis werden architecten naast het team van de klant gezet om op de zware onderwerpen mee te beslissen — niet om het over te nemen. Bij Thinkwise trok ik een migratie vlot die een jaar had stilgestaan, en werd ik door de oorspronkelijke architect van het platform als technisch gelijke behandeld; het team heb ik daarnaast gecoacht in hoe ze onderling tot besluiten kwamen. Bij Topicus begon ik als developer en werd ik in mijn tweede periode meegevraagd naar de productmeetings — en in totaal drie keer teruggevraagd.
Twee dagen per week
Vaste dagen, zodat je team weet wanneer ik er ben. Die twee leveren meer op dan je zou rekenen — niet omdat ik harder werk, maar omdat ik werk uitkies dat op meerdere plekken tegelijk vooruitgang geeft. Fulltime doe ik niet.
Eén dag bij jou op kantoor
De eerste weken vaker, omdat je een bedrijf niet via een scherm leert kennen. Zit je verder weg, dan kan dat ook — alleen wordt het dan bijvoorbeeld één kantoordag per twee weken. Die ruil spreken we vooraf af.
Vanuit Kampen
Zwolle, Deventer, Apeldoorn, Dronten, Emmeloord, Harderwijk en Lelystad liggen binnen een klein uur. Geen consultant die invliegt en verdwijnt — iemand die terugkomt.
Ik werk mee
Niet omdat het aardig staat, maar omdat het moet: ik zie pas wat ertoe doet als ik met je vraag heb geworsteld. Dus zit ik in de code en aan tafel bij je mensen — niet als extra paar handen, maar omdat mijn beslissingen daar beter van worden.
Dat kan. De situaties hierboven zijn voorbeelden, geen menukaart — de vorm volgt uit het gesprek. Vertel wat er speelt.