De vacature staat open, maar de markt is leeg
Wie vandaag een ervaren AI-engineer of fullstack ontwikkelaar zoekt, concurreert met tech-bedrijven, banken en consultancy om dezelfde kleine groep mensen. Goede engineers kiezen hun werkgever uit, niet andersom. Ze willen een omgeving met collega's van niveau, moderne tooling en werk dat er technisch toe doet. Een werving die maanden duurt is geen uitzondering, en daarna begint het pas: inwerken, het domein leren kennen, de eerste bruikbare oplevering. Voor een bedrijf waar software niet de kern is, betekent dat een lange aanloop voordat er iets in de operatie draait. Dat is geen reden om nooit iemand aan te nemen, maar wel een reden om eerst te bepalen of je die persoon over twee jaar nog steeds veertig uur per week zinvol werk kunt geven.
Wanneer eigen mensen aannemen wél de juiste keuze is
Eigen ontwikkelaars aannemen loont als software structureel onderdeel is van je verdienmodel of je operatie. Denk aan een bedrijf dat een eigen platform doorontwikkelt, of een operatie waar wekelijks nieuwe koppelingen, rapportages en procesaanpassingen nodig zijn. Maar reken jezelf niet rijk met één vacature. Eén ontwikkelaar is een single point of failure: niemand die zijn code controleert, niemand die het overneemt bij vertrek of ziekte, niemand om architectuurkeuzes mee te toetsen. Serieus intern bouwen betekent een team, met alles wat daarbij hoort: technisch leiderschap, code review, vervangbaarheid. Kun je dat dragen en gebruiken, dan is een intern team op termijn de sterkste optie. Kun je dat niet, dan koop je met één hire vooral risico.
Wanneer een standaardpakket of SaaS gewoon volstaat
Voor generieke processen hoef je niemand aan te nemen en niets te laten bouwen. Boekhouding, HR, standaard CRM: daar bestaan volwassen pakketten voor die het werk prima doen. De vuistregel is simpel. Als jouw proces niet wezenlijk anders is dan dat van duizend andere bedrijven, en het proces is geen onderdeel van waarom klanten voor jou kiezen, dan koop je een standaardoplossing en pas je je werkwijze daarop aan. Laat je in dat geval ook niet door een leverancier maatwerk aanpraten. De vraag wordt pas interessant zodra het standaardpakket structureel wringt: uitzonderingen die niet passen, handwerk eromheen, exports naar Excel om het echte werk te doen. Dat wringen is het signaal dat je proces domeinspecifieker is dan het pakket aankan.
Het gat ertussen: domeinspecifiek werk zonder vast team
De meeste bedrijven die ons bellen zitten precies in dat gat. Het proces is te specifiek voor een standaardpakket, maar het werk is niet structureel genoeg om een eigen ontwikkelteam te dragen. Voor die situatie bestaat de externe route, en daar loont het om scherp te kijken naar wat voor partij je binnenhaalt. Een detacheerder levert capaciteit en jij blijft verantwoordelijk voor het resultaat. Een projectbureau levert op en vertrekt. Een operating partner neemt verantwoordelijkheid voor het resultaat in productie: bouwen tot het draait, mijlpalen met go/no-go momenten, en eigendom van code en data dat bij jou ligt, niet bij de leverancier. Dat laatste maakt ook een hybride model mogelijk dat in de praktijk goed werkt: een externe partij bouwt het systeem, en één eigen medewerker groeit mee als functioneel eigenaar die het systeem daarna draagt. Dat is een veel haalbaardere vacature dan een senior AI-engineer.
Hoe je de keuze concreet maakt
Stel jezelf drie vragen, in deze volgorde. Eén: is software een structurele stroom werk in mijn bedrijf, of een inhaalslag van een tot twee jaar? Structureel werk rechtvaardigt een team, een inhaalslag niet. Twee: kan ik een team dragen, met minimaal enkele ontwikkelaars en technisch leiderschap? Zo nee, neem dan geen enkele ontwikkelaar aan in de hoop dat het meevalt. Drie: is het proces onderscheidend genoeg voor maatwerk, of wringt het standaardpakket vooral omdat we onze werkwijze niet willen aanpassen? Wees daar eerlijk in. En welke route je ook kiest: leg vast wie eigenaar wordt van code en data. Een externe partij die daar vaag over doet, bouwt aan haar eigen lock-in, niet aan jouw systeem.