Eén ontwikkelaar, geen team: waarom solo bouwen duur kan uitpakken

De aantrekkingskracht van solo werken

Je hebt een ontwikkelaar gevonden die snel levert, minder kost dan een bureau en geen vergaderingen nodig heeft. Er wordt dagelijks code gepusht. Features verschijnen op schema. Van buitenaf ziet alles er geweldig uit.

Wat je pas later ziet: niemand heeft die code gereviewed. Niemand stelde vragen bij het databaseontwerp. Niemand vroeg: "Wat gebeurt er als deze tabel een miljoen rijen heeft?" of "Hoe pakt een andere ontwikkelaar dit over zes maanden op?"

Dit gaat niet over vaardigheidsniveau. Een senior freelancer die tien jaar alleen heeft gewerkt, produceert dezelfde blinde vlekken als een junior — alleen met meer zelfvertrouwen.

Wanneer een solo-ontwikkelaar prima werkt

Laten we eerlijk zijn: niet elk project heeft een team nodig. Een marketingwebsite van vijf pagina's, een landingspagina voor een productlancering, een eenvoudige WordPress-site met een contactformulier — dit zijn bekende problemen met bewezen oplossingen. Een junior developer of een solo freelancer kan ze prima afhandelen zonder architectuurrisico.

Zelfs bij grotere projecten kan een solo-ontwikkelaar goed presteren — als ze echte teamervaring hebben. Iemand die jarenlang code reviews deed, architectuurkeuzes besprak en systemen onderhield die door anderen waren gebouwd, neemt die gewoontes mee naar solowerk. Ze schrijven documentatie niet omdat iemand het vraagt, maar omdat ze weten wat er zonder gebeurt.

Het probleem is niet solo werken. Het probleem is solo werken zonder ooit te hebben geleerd waartegen een teamproces je beschermt.

Waar het misgaat: projecten die architectuur vereisen

Het risico ontstaat wanneer het project te groot wordt om in het hoofd van één persoon te passen. Meerstaps-gebruikersflows. Achtergrondtaken. Koppelingen met derden. Rolgebaseerde toegang. Databaseschema's die jarenlang zullen evolueren. Migratiepaden. Deployment-pipelines.

Dit zijn geen features — het zijn architectuurbeslissingen. En architectuurbeslissingen die door één persoon worden genomen, zonder tegenspraak of review, optimaliseren doorgaans voor "werkt nu" in plaats van "werkt op schaal" of "kan door iemand anders worden onderhouden."

Een ontwikkelaar die nooit op hun architectuur is uitgedaagd, weet niet wat ze niet weten. Ze kiezen patronen omdat ze vertrouwd zijn, niet omdat ze juist zijn voor het probleem. En tegen de tijd dat de gevolgen zichtbaar worden, zit het project te diep in een specifieke aanpak om goedkoop bij te sturen.

Code die maar één persoon begrijpt

Wanneer een ontwikkelaar alleen werkt, bouwt deze mentale modellen die nooit hun hoofd verlaten. Variabelenamen zijn logisch voor hén. De mapstructuur volgt hún persoonlijke logica. Het deploymentproces leeft in een shellscript op hun laptop.

In software engineering heet dit de bus factor — het aantal mensen dat zou moeten wegvallen voordat een project vastloopt. Een studie uit 2022 van Jabrayilzade et al. vond dat 10 van de 25 populaire open-sourceprojecten op GitHub een bus factor van één hadden. Dit zijn publieke projecten met bijdragers wereldwijd. Stel je nu een private codebase voor die volledig door één freelancer is gebouwd.

Wanneer die ontwikkelaar verder gaat — en dat zullen ze, want freelancers wisselen tussen klanten — blijf je achter met een codebase die niemand anders efficiënt kan onderhouden. De volgende ontwikkelaar besteedt de eerste weken (of maanden) alleen aan begrijpen hoe alles werkt, voordat ze veilig iets kunnen wijzigen.

Geen review betekent geen vangnet

Code review is geen bureaucratie. Het is de meest effectieve methode voor het opsporen van fouten in software engineering.

Volgens het onderzoek van Steve McConnell in Code Complete vangen code-inspecties ongeveer 60% van de defecten op — meer dan unittesten (25%), functionele testen (35%) of integratietesten (45%). In één studie die hij aanhaalt, hadden gereviewed programma's 0,82 fouten per 100 regels code, vergeleken met 4,5 fouten per 100 regels zonder review. Dat is een reductie van 82%, simpelweg door een tweede paar ogen.

Een solo-ontwikkelaar test eigen aannames tegen eigen inzicht. Bugs die een teamgenoot in een review van 15 minuten zou opvangen, overleven tot productie en worden later dure reparaties.

Technische schuld die je niet ziet — tot je ervoor betaalt

Elke codebase bouwt enige technische schuld op. Dat is normaal. Het probleem met solo-ontwikkelaars zonder teamervaring is dat schuld ongecontroleerd groeit. Er is niemand die zegt: "Deze shortcut kost ons later geld" of "Laten we dit refactoren voordat het zich verspreidt."

De cijfers zijn onthutsend. Het CISQ-rapport uit 2022 schat dat slechte softwarekwaliteit de Amerikaanse economie jaarlijks $2,41 biljoen kost, waarvan $1,52 biljoen aan opgebouwde technische schuld. McKinsey's onderzoek brengt het dichterbij: technische schuld vreet ongeveer 40% van IT-balansen, en meer dan 20% van budgetten bestemd voor nieuwe producten gaat stilletjes naar het oplossen van oude problemen.

Volgens Stripe's Developer Coefficient-studie besteden ontwikkelaars gemiddeld 17,3 uur per week — 42% van hun werktijd — aan technische schuld en onderhoud in plaats van het bouwen van nieuwe features. Wanneer je een codebase erft van een solo-ontwikkelaar zonder reviewgeschiedenis, gaat dat percentage omhoog, niet omlaag.

Snelheid is niet hetzelfde als vooruitgang

Solo-ontwikkelaars lijken vaak snel omdat er geen proces is dat hen vertraagt. Geen pull requests om op te wachten. Geen architectuurdiscussies. Geen "Kunnen we deze aanpak heroverwegen?"-gesprekken.

Maar snelheid zonder feedback is slechts snelheid in een onbekende richting. Het DORA State of DevOps Report 2024 — gebaseerd op data van meer dan 32.000 professionals — toont consequent aan dat teams die metrics en praktijken delen tussen development en operations beter presteren dan geïsoleerde individuen. Het rapport vond ook dat het aandeel goed presterende teams kromp van 31% naar 22%, grotendeels doordat samenwerkingspraktijken verslechterden.

Een ontwikkelaar die features in twee dagen oplevert maar code creëert die twee weken nodig heeft om aan te passen, heeft je geen tijd bespaard. Ze hebben die geleend — tegen een hoge rente.

Wat dit je werkelijk kost

Dit is wat er doorgaans gebeurt wanneer een bedrijf voor een echt complex project vertrouwt op een solo-ontwikkelaar zonder teamachtergrond:

Dit patroon is zo gebruikelijk dat het een naam heeft in onze branche: de herschrijf-valkuil. En het begint bijna altijd met een solo-bouwer op een project dat hen ontgroeid is.

Hoe je een solo-ontwikkelaar beoordeelt voordat je je vastlegt

Je hebt niet altijd een team nodig. Maar je moet altijd verifiëren dat de persoon aan wie je je project toevertrouwt, de complexiteit aankan. Dit is waar je op let:

• Vraag naar teamervaring. "Beschrijf je code review-proces." Als het antwoord is "Ik doe geen code reviews want ik werk alleen" — dan ken je het risico. Als ze zeggen "Ik reviewde dagelijks PR's in mijn vorige team en ik schrijf nog steeds code alsof iemand het gaat reviewen" — dan is dat een ander persoon.
• Stem de ontwikkelaar af op de projectomvang. Een website van vijf pagina's heeft geen senior architect nodig. Een SaaS-platform met gebruikersrollen, betaalflows en koppelingen met derden wel. Te veel betalen voor een eenvoudig project is verspilling; te weinig betalen voor een complex project is een valkuil.
• Kijk naar hoe ze documenteren. Vraag om een README, een deploymentgids of een architectuurbeslissing van een eerder project. Als die niet bestaan, leeft de kennis alleen in hun hoofd.
• Controleer op geautomatiseerde tests. Geen 100% dekking omwille van een metric — maar genoeg dat de volgende ontwikkelaar code kan wijzigen zonder te gokken wat er kapot kan gaan.
• Eis gedeelde toegang vanaf dag één. Hostinggegevens, CI/CD-pipelines, domeinregistrars, API-sleutels. Als iets hiervan alleen op iemands laptop staat, is je bus factor één.

De echte vraag die je moet stellen

Voordat je een solo-ontwikkelaar aanneemt — freelancer, contractor of medewerker — stel jezelf deze vraag: "Wat gebeurt er als deze persoon niet meer beschikbaar is?"

Als het project een eenvoudige website is, is het antwoord waarschijnlijk "We vinden iemand anders en die pikt het binnen een dag op." Dat is prima. Neem dan gerust degene die goed werk levert voor een eerlijke prijs.

Als het project echte complexiteit heeft — en het eerlijke antwoord is "Dan zitten we vast" — dan bespaar je geen geld. Je stelt een kostenpost uit die elke maand groeit. De ontwikkelaar is misschien getalenteerd, snel en prettig om mee te werken. Maar talent zonder feedbackloop creëert fragiele software — en fragiele software wordt altijd iemand anders' dure probleem.