Eén maker vs. een heel bureau: waarom solo soms sneller en beter is

"We zetten een team voor je klaar." Het klinkt geruststellend, een heel bureau dat voor jou aan de slag gaat. Maar wie weleens met een bureau heeft gewerkt, kent ook de keerzijde: de accountmanager die je brief doorgeeft aan een projectleider, die het doorgeeft aan een designer, die het doorgeeft aan een ontwikkelaar die jou nooit heeft gesproken. Tegen de tijd dat je idee de persoon bereikt die het echt bouwt, is het door vijf paar handen gegaan. Ik bouw bewust solo. Niet omdat groot per se slecht is, maar omdat één maker in veel gevallen sneller en beter levert. In dit artikel leg ik eerlijk uit waarom, en ook waar de grenzen liggen en hoe ik die opvang.

Het probleem van overdracht

Elke keer dat informatie van de ene persoon naar de andere gaat, lekt er iets weg. Dat is geen kwestie van slechte mensen of een slecht bureau, het is gewoon hoe communicatie werkt. Jij vertelt wat je wilt, de accountmanager noteert zijn interpretatie, de projectleider maakt daar een briefing van, de designer vult de gaten met aannames, en de ontwikkelaar bouwt uiteindelijk wat hij denkt dat de bedoeling was.

Bij elke overdracht verschuift de betekenis een paar graden. Aan het eind van de keten kan het resultaat verbazend ver van je oorspronkelijke idee af staan, zonder dat iemand iets fout deed. Iedereen deed precies wat hem werd doorgegeven. Het probleem zit niet in een schakel, het zit in het aantal schakels.

Bij een solo maker is die keten één persoon lang. Jij vertelt mij wat je wilt, en ik bouw het. Als ik je verkeerd begrijp, merken we dat meteen in het werk zelf, niet pas drie schakels verderop wanneer correctie duur is geworden.

Ruis kost tijd, en tijd is geld

Overdracht kost niet alleen kwaliteit, het kost tijd. Een groot deel van wat een bureau in rekening brengt, gaat niet naar bouwen maar naar coördineren. Statusoverleggen, afstemmingsdocumenten, interne hand-overs, mensen die elkaar bijpraten over wat de klant nou eigenlijk bedoelde. Dat is reëel werk dat ook betaald wordt, maar het levert jou geen functionerende software op.

Ik wil niet doen alsof coördinatie altijd verspilling is. Bij grote, complexe projecten met tientallen mensen is afstemming gewoon nodig, en een goed bureau doet dat vakkundig. Maar voor het type werk dat ik doe, maatwerksoftware, koppelingen en automatisering voor het MKB, is veel van die overhead vermijdbaar. De tijd die niet naar overleg gaat, gaat naar bouwen. Dat scheelt zowel in doorlooptijd als in rekening. Met slim werken, loont hard werken: door de ruis eruit te halen, komt mijn tijd terecht waar hij waarde maakt, in het product zelf.

Een directe lijn met de bouwer

Dit is misschien wel het grootste verschil in de praktijk. Als je met mij werkt, praat je met de persoon die het ook echt maakt. Geen vertaalslag, geen "ik check het even met het team", geen wachten tot de volgende sprintplanning.

Dat heeft concrete gevolgen. Wanneer je halverwege bedenkt dat iets net anders moet, kan ik vaak meteen inschatten of dat een kwestie van vijf minuten is of van een week, omdat ik de code in mijn hoofd heb. Bij een bureau moet die vraag eerst weer de keten in, en komt het antwoord vertraagd en afgevlakt terug. De directe lijn betekent ook dat ik de vraag achter de vraag hoor. Vaak vraagt iemand om knop A, terwijl hij eigenlijk probleem B wil oplossen, en bestaat er een betere oplossing C. Dat gesprek voer je alleen goed als de persoon die luistert ook degene is die bouwt.

Eigenaarschap, in beide richtingen

Als ik iets bouw, ben ik er volledig verantwoordelijk voor. Er is niemand om naar te wijzen als er iets niet klopt, geen "dat was de vorige ontwikkelaar" of "dat zat niet in de overdracht". Wat ik oplever, ken ik tot in de details, want ik heb elke regel zelf geschreven.

Dat eigenaarschap snijdt twee kanten op. Voor mij betekent het dat ik me niet kan verschuilen. Voor jou betekent het dat je software krijgt die je daadwerkelijk bezit, in plaats van iets dat verstrengeld zit met de interne processen van een bureau. Je weet wie het gebouwd heeft en waar je terecht kunt, en je zit niet vast aan een leverancier die jou nodig heeft om zijn urenstaat te vullen. Hoe ik daarover denk, en waarom ik zo werk, lees je op over ons.

De eerlijke grenzen van solo

Nu het deel waar je een verkoper niet snel over hoort, want geen enkele aanpak is gratis. Solo werken heeft twee echte beperkingen, en ik zou je niet serieus nemen als ik ze verzweeg.

Capaciteit. Ik ben één persoon. Ik kan niet tien projecten tegelijk opleveren, en een gigantisch systeem dat de inzet van een heel team vraagt bouw ik niet in mijn eentje in dezelfde tijd. Een groot bureau schaalt op door mensen bij te zetten. Ik niet, althans niet op die manier.

De bus-factor. De ongemakkelijke vraag: wat als mij iets overkomt? Bij een team van twintig kan iemand uitvallen en draait de rest door. Bij een solo maker is er per definitie één persoon die alles weet. Dat is een reëel risico, en wie er overheen praat, is niet eerlijk bezig.

Ik noem deze twee niet om mezelf onderuit te halen, maar omdat een keuze pas eerlijk is als je ook de prijs ervan kent. De vraag is niet of die grenzen bestaan, maar of ze opgevangen kunnen worden. Dat kunnen ze.

Hoe ik die grenzen opvang

Voor het capaciteitsvraagstuk ben ik eerlijk over wat ik aankan. Ik neem niet meer aan dan ik goed kan leveren, en ik ben helder over de planning in plaats van overal ja op te zeggen en dan achter te lopen. Liever een realistische datum die ik haal, dan een mooie belofte die ik breek. Voor sommige projecten ben ik simpelweg niet de juiste partij, en dat zeg ik dan ook.

De bus-factor vang ik op door niet op mezelf te bouwen, maar op overdraagbaarheid. Concreet:

• Alles staat gedocumenteerd. Niet alleen in mijn hoofd, maar in leesbare code en heldere documentatie, zodat een andere ontwikkelaar het kan overnemen.
• Je bezit je eigen spullen. Code, server, accounts en data staan op jouw naam, niet achter een slot waar alleen ik de sleutel van heb. Raakt de samenwerking zoek, dan kun je verder zonder mij.
• Geen exotische geheimen. Ik bouw op gangbare, open technologie en standaarden, geen zelfbedachte trucs die niemand anders snapt.

Het komt erop neer dat ik werk alsof iemand het na mij moet kunnen overnemen. Daardoor krijg je de voordelen van solo, de korte lijn en het lage ruisniveau, zonder dat je vastzit aan mij als enige die het snapt.

Wanneer een bureau juist de betere keuze is

Om het eerlijk te houden: er zijn situaties waarin een bureau gewoon beter past. Bij een enorm project dat permanent de inzet van meerdere specialisten vraagt, of wanneer je expliciet de zekerheid van een groot team met reservecapaciteit wilt inkopen. Dat is geen zwakte van solo, het is een ander soort vraag.

Voor het overgrote deel van wat het MKB nodig heeft, ligt dat anders. Een koppeling tussen je systemen, een stuk maatwerk dat je proces echt past, automatisering die handwerk wegneemt: dat zijn projecten waar een korte lijn en weinig ruis juist winnen.

Tot slot

Eén maker tegenover een heel bureau is geen kwestie van groot tegen klein, of duur tegen goedkoop. Het is een afweging tussen coördinatie en directheid. Een bureau brengt capaciteit en reserve, en betaalt daarvoor met overdracht, ruis en afstand tot de bouwer. Een solo maker brengt een korte lijn, weinig ruis en echt eigenaarschap, mits hij de grenzen van capaciteit en bus-factor bewust ondervangt.

Ik kies voor solo omdat de meeste software beter wordt als de persoon die luistert ook degene is die bouwt. De keuze is uiteindelijk niet ideologisch maar praktisch: welke structuur past bij wat je wilt bouwen? Weet je dat antwoord, dan weet je ook welke maker je nodig hebt.