Ik wil fair zijn, want de luie versie van dit argument is fout en iedereen in de branche weet het. Bureau engineers zijn niet trager dan in-house engineers. Veel zijn aanzienlijk beter, omdat ze veertig codebases hebben gezien in plaats van één.
En toch duurt hetzelfde werk wat een klein team drie weken doet routinematig zes maanden bij een bureau. Die kloof is geen moeite. Het is structuur.
Waar de tijd eigenlijk heen gaat
De discovery fase die ontdekt wat je ze al verteld hebt
Vier tot zes weken workshops, personas en journey maps, eindigend in een deck dat je brief in mooiere typografie herhaalt. Het bestaat om twee redenen: het is billable en het beschermt het bureau tegen blaam voor een verkeerde richting later.
Enige discovery is echt nodig — je kunt niet bouwen wat niemand gedefinieerd heeft. Maar de verhouding klopt niet. Als discovery meer kost dan de eerste shippable increment, financier je een verzekeringspolis, niet een product.
De personeelsgat
Je tekent in maart. Het team is vrij in mei. Ondertussen word je toegewezen aan een gedeeltelijk team, of een sterke lead die echt aan jouw project werkt — één dag per week.
Dit is het minst besproken en duurste regelitem, omdat het nooit als regelitem verschijnt.
Het pitch team en delivery team zijn verschillende mensen
Je kocht de persoon in de kamer. Je kreeg wie beschikbaar was. Dat is geen bedrog; bureaus zijn personeelsbedrijven en de senior people verkopen. Maar het oordeel dat je evalueerde is niet het oordeel dat je product bouwt.
Handoffs
Strategy schrijft een brief voor design. Design produceert files voor engineering. Engineering stelt de vragen die design niet bedacht heeft en design zit nu op een ander account. Elke handoff verliest context en voegt een queue toe, en queues zijn waar kalenderwerk verstopt zit.
Approval theatre
Drie rondes feedback per deliverable, elk met een week lead time, het meeste besteed aan iemands kalender wachten in plaats van aan werk.
Tel het op
Zes weken discovery. Vier weken personeelsgat. Zes weken design met twee review cycli. Tien weken bouwen, onderbroken door drie handoffs. Vier weken QA en stakeholder review. Zesentwintig weken — en het echte engineering was misschien vijftien dagen gefocuste senior work.
Niemand was lui. Niemand vulde een timesheet. De structuur produceerde het getal.
Wat de structuur eigenlijk voor je koopt
Fair: op een bepaalde schaal koopt het echte dingen. Continuïteit als iemand vertrekt. Capaciteit om vijf workstreams tegelijk te runnen. Iemand om te bezweken. Een merk dat je board kent. Voor een 200-persoonsbedrijf dat een kernsysteem vervangt, is dat betalen waard.
Voor een founder die probeert uit te vinden of een idee werkt, betaal je voor verzekering tegen risico's die je niet hebt.
Hoe je erumheen kunt kopen
- Vraag wie de code schrijft, met naam, voordat je tekent. Vraag dan wat percentage van hun week je krijgt. Het antwoord op de tweede vraag is het eerlijke.
- Cap discovery expliciet. "Één week, dan bouwen we iets." Een goede partner zal specifiek pushen als dat echt te kort is — en die pushback zegt je iets nuttigs.
- Koop korte fixed windows. Twee of drie weken met een shippable outcome aan het einde. Structuur kan niet verbergen in een twee-weekse window; daar is nergens voor om heen te gaan.
- Dring aan op werkende software vroeg, niet artefacten. Een deck is geen voortgang. Een build op je telefoon is.
- Beperk goedkeurers tot één. Elke extra persoon met vetorecht voegt een week toe, wat het contract ook zegt.
Het eerlijke tegenargument
Een klein senior team is sneller en goedkoper, en heeft een echt zwak punt: bus factor. Als het één of twee mensen zijn en één wordt ziek, stop je. Een bureau absorbeert dat; een individu niet.
Dat is een echte ruil en het juiste antwoord hangt af of je iets valideert of iets runt. Maak het gewoon een beslissing in plaats van default — en terwijl je toch bezig bent, beslis ook welke contractvorm aansluit hoe goed je het werk echt begrijpt.