Waarom kiezen voor externe ontwikkelaars, en wanneer juist niet

Het is de eerste dag van je campagne en de webshop wordt traag. Of een koppeling met een leverancier valt uit, terwijl niemand in huis precies weet waar het probleem zit. Op zo'n moment heb je geen maanden om een developmentteam op te bouwen. Dat is voor de meeste bedrijven de eerlijkste reden om te kiezen voor externe ontwikkelaars: technische vertraging werkt direct door in je omzet, je klantenservice en de dagelijkse operatie.

Mijn advies is daarom vrij uitgesproken. Is software niet je kernproduct, beleg de techniek dan extern en houd intern het eigenaarschap: wie de prioriteiten stelt, wie beslist en wie het proces kent. Is software wel je product, dan pak ik het andersom aan.

Kies externe ontwikkelaars voor alles behalve je kernproduct

Eén developer aannemen voelt als de verstandige eerste stap. Kennis dichtbij, korte lijnen. Alleen moet die ene persoon dan ook architectuur, beveiliging, testen, documentatie, deployment en monitoring dragen. Is hij of zij op vakantie of ziek, dan ligt het stil.

Dat weegt zwaar bij bedrijven waar software de motor is van het werk. Denk aan een uitgever die draait op een snel platform, een e-commercebedrijf met ingewikkelde voorraadkoppelingen of een bureau dat betrouwbare omgevingen voor zijn klanten nodig heeft. Daar hoort je team met klanten en processen bezig te zijn, en elk uur dat naar het najagen van foutmeldingen gaat, gaat daarvan af.

De uitzondering is een bedrijf dat een uniek technologieproduct bouwt waar zijn concurrentiepositie op rust. Daar vallen elke dag productbeslissingen en moet de kennis volledig in eigen huis landen. In die situatie zou ik investeren in een sterk intern product- en developmentteam.

Groei wacht niet op je vacature

Een nieuw klantsegment vraagt om een portal. De backoffice die je met de hand bijhoudt, wordt te foutgevoelig. Een bestaande applicatie moet ineens veel meer verkeer aankunnen. Als je dan eerst moet werven, inwerken en processen inrichten, loopt de operatie achter de feiten aan.

Een externe partner start met een duidelijke opdracht en een werkwijze die al staat. De winst zit vooral in het voorwerk: requirements scherp krijgen, risico's herkennen en bepalen wat technisch werkelijk nodig is. Dat valt vaak kleiner uit dan je denkt. Soms is een gerichte API-koppeling of een intern hulpmiddel genoeg, waar je een complete nieuwe applicatie verwachtte.

Ook de capaciteit beweegt mee. Voor een migratie, een app-release of een piekperiode zet je tijdelijk meer ontwikkelkracht in dan voor regulier onderhoud, en daarna blijft dezelfde kennis beschikbaar voor doorontwikkeling en support.

Voor je begroting is dat prettig. Je ziet per project, verbetering of beheervraag wat het kost en kunt er een businesscase naast leggen. Een interne developer heeft werk nodig dat bij zijn of haar niveau past, en dat gaat wringen zodra de vraag wisselt tussen frontend, integraties, infrastructuur en mobiele apps. Een extern team zet per fase de discipline in die erbij hoort.

Eén partij voor de code en de server

Met meerdere leveranciers gaat het bij een storing vaak zo: de ontwikkelaar wijst naar de hoster, de hoster naar de externe koppeling en de leverancier van die koppeling weer naar de applicatie. Je klant wacht op antwoord en je eigen team staat stil.

Software draait altijd in een omgeving, en die omgeving bepaalt of gebruikers een snel systeem ervaren en of een incident klein blijft. Hosting, performance, beveiliging, back-ups en monitoring en deployments horen daarom bij dezelfde verantwoordelijkheid als de code. Een partner die beide kanten kent, ziet sneller waar een probleem werkelijk zit en bouwt nieuwe functies met de omgeving in het achterhoofd.

Bij LJPc in Assen liggen ontwikkeling, hosting en support om die reden bewust onder één dak. Ben je dagelijks afhankelijk van je platform, dan is dat de kortste weg van melding naar oplossing.

De keerzijde is dat je afhankelijker wordt van één partij. Daarom verdienen de afspraken hieronder meer aandacht dan ze meestal krijgen.

Vraag naar broncode en toegang vóór de offerte

Een uurtarief en een fraai portfolio zeggen weinig over hoe een samenwerking loopt als er iets stukgaat. Vraag hoe een partner werkt bij een storing, hoe kennis wordt vastgelegd en wie je daadwerkelijk aan de lijn krijgt. Leg daarna vast, voordat er een regel code geschreven is:

• wie eigenaar is van de broncode;
• wie toegang heeft tot de omgevingen;
• welke afspraken er over beveiliging gelden;
• hoe support loopt bij een urgente storing.

Dit zijn geen juridische details voor later, maar voorwaarden voor continuïteit.

Let ook op hoe je straks een storing meldt. Bij een urgent probleem wil je direct iemand aan de lijn die de context begrijpt. Tegelijk wil je achteraf kunnen nagaan welke keuzes er zijn gemaakt en wat er is gedaan. Persoonlijk contact en een traceerbaar proces versterken elkaar.

En kijk naar je eigen kant. Zonder heldere doelen, bereikbare beslissers en een eigenaar binnen je organisatie loopt ook een technisch sterk project vast. Een partner kan adviseren, bouwen en beheren. Welke processen bij jou voorgaan, bepaal je zelf.

Begin met één knelpunt en een klein resultaat

Wat ik zou overslaan, is de lange lijst met gewenste functies. Begin bij de plek waar het pijn doet. Waar verliest je team tijd? Waar haken klanten af? Welke informatie wordt dubbel ingevoerd, en welke uitval kost omzet of vertrouwen? Kies daar één van.

Spreek daarna het eerste tastbare resultaat af. Een werkende koppeling, een verbeterd bestelproces of een intern dashboard dat handwerk overneemt. Zo zie je snel hoe de samenwerking loopt en blijft het project concreet.

Geef de partner de context achter de opdracht. Een developer die weet waarom een order vóór een bepaald tijdstip verwerkt moet zijn, maakt andere keuzes dan iemand die alleen een schermontwerp krijgt.

Reserveer vanaf de start ruimte voor wat na de oplevering komt: onderhoud, security-updates, performanceverbeteringen en kleine optimalisaties. Software verandert mee met je klanten, processen en leveranciers, en een systeem dat niemand bijhoudt, groeit langzaam uit tot het volgende knelpunt.

Schrijf vandaag het ene knelpunt op dat je deze maand de meeste tijd of omzet kost, met de naam van de persoon die er intern over beslist. Met dat halve A4'tje heeft je eerste gesprek met een technische partner meteen richting.