← Alle notitiesENNL
Strategie Proces

Freelancer, bureau of softwarebedrijf?

Je hebt besloten te bouwen. Nu kies je wie het bouwt, en de drie opties gaan elk op een andere plek mis.

11 sep. 2026·6 min leestijd·99six

Bouwen of kopen heb je beslist. De volgende keuze is freelancer, bureau of softwarebedrijf, en dat is geen budgetvraag: kiezen welke zwakke plek je kunt hebben, is het grootste deel van de beslissing.

Wie moet het dan bouwen?

Een freelancer, als het werk één persoon breed is — een eerste MVP is dat meestal. Een bureau, als meerdere specialisten er tegelijk aan moeten werken en iemand ze in de pas moet houden. Een softwarebedrijf, als je een klein senior team wilt dat alles doet.

  • Freelancer. Het goedkoopst, het snelst begonnen, en het stopt als hij stopt.
  • Bureau. Capaciteit, proces en vervanging, deels betaald in lagen die je nooit ontmoet.
  • Softwarebedrijf. Senior mensen die het werk doen in plaats van het te verkopen, zonder reservebank erachter.

Ligt bouwen of kopen nog open, beslis dat dan eerst — onze notitie over bouwen of kopen voor kleine teams zit een niveau hoger.

Wanneer is een freelance developer de juiste keuze?

Als het werk één persoon breed is en dat blijft. Dat is de hele test als je twijfelt tussen een freelance developer en een bureau: één developer die het geheel in zijn hoofd kan houden, verslaat een team, want meer mensen betekent meer overleg, niet meer snelheid.

  • De klus heeft duidelijke grenzen. Een site, een koppeling, één functie in een systeem dat al bestaat.
  • Je weet wat je wilt en kunt het simpel zeggen, of je bent technisch genoeg om het week na week bij te sturen.
  • Er is al een plek waar het kan draaien, en iemand die het daarna beheert.

Een eerste MVP heeft meestal deze vorm. Vraag je je af wie je MVP moet bouwen, dan is een freelancer vaak het eerlijke antwoord. Vraag wel wat er gebeurt als het werkt: een prototype dat niemand anders kan overnemen, is een herbouw waarvoor je geen offerte kreeg.

Wat je erbij neemt, is het risico op stilstand. Eén persoon wordt ziek of krijgt een beter aanbod, en het project stopt waar het stond. Niemand reviewt de code. Niemand spreekt het eerste idee tegen.

Waar betaal je een bureau voor?

Vooral voor coördinatie. Het tarief dekt de developer, de designer, de projectmanager die ze in dezelfde week houdt, en de accountmanager die je vertelt hoe het gaat.

Dat is het waard als het werk echt parallel loopt. Een merk, een campagne, een app en het systeem erachter, alles op een datum die niet kan schuiven: dat is meer dan een klein team kan dragen. Bureaus zijn daarvoor gebouwd, en ze overleven het als iemand halverwege vertrekt.

Het is het niet meer waard als er meer lagen zijn dan werk. Het teken: wie je probleem begreep, is niet wie het bouwt, en een kleine vraag staat dagen in een wachtrij. Bij een bescheiden maatwerk systeem is dat gat het grootste deel van de factuur.

Wat is een boutique softwarebedrijf, en waarom legt niemand het uit?

Een klein team dat de hele bouw zelf doet, met senior mensen die de code schrijven in plaats van verkopen. Niemand marketeert het helder, want "klein bureau" klinkt als een slechter bureau en "team van freelancers" als een slechtere freelancer.

Vergeleken met een bureau ruilt een boutique softwarebedrijf lagen in voor continuïteit: kleiner, en iedereen in het gesprek schrijft ook de code.

"Softwareontwikkelingsbedrijf" zegt iets over de papieren, niet over de omvang. Zo'n bedrijf vergelijken met een freelancer zegt dus niets, tot je weet hoeveel van hun mensen op jouw project zitten.

Wat je koopt, is dat er niets wordt overgedragen: wie het probleem begreep, is er nog als de beslissingen vallen. Dat is 99six — twee oprichters, strategie en bouw, niemand ertussen. Op de pagina Over staat wie welke helft doet.

De keerzijde is capaciteit. Een klein softwarebedrijf heeft geen reservebank, dus boven een bepaalde omvang is het eerlijke antwoord een bureau. Een goed softwarebedrijf vertelt je waar zijn plafond zit voordat je het vraagt.

Freelancer, bureau of softwarebedrijf: hoeveel mensen tegelijk?

Eén persoon tegelijk: een freelancer. Een paar die dagelijks moeten overleggen: een softwarebedrijf. Meer dan er rond één tafel passen, met een vaste datum: een bureau. Eén vraag beslist het: hoeveel mensen moeten hier tegelijk aan werken? Niet het budget, en niet de deadline.

  • Eén persoon tegelijk. Een freelancer, en besteed een deel van wat je bespaart aan een review van de code.
  • Een paar mensen die elke dag moeten overleggen. Een softwarebedrijf, waar coördinatie een gesprek is, geen proces.
  • Meer mensen dan er rond één tafel passen, met een vaste datum. Een bureau, waarvan de marge het proces betaalt dat iedereen dezelfde kant op houdt.

De meeste mkb-software is het middelste geval, verkocht als het derde. Daar gaat het geld heen.

Wat je koopt, is hoe weinig mensen het eens moeten worden voordat iets live gaat.

Wat verandert er als het proces het bedrijf is?

Wie je inhuurt, verandert compleet. Is de manier waarop je werkt de reden dat klanten voor jou kiezen, dan betekent bouwen dat iemand bij je bedrijf meekijkt tot hij begrijpt waarom het zo in elkaar zit.

Geef een freelancer een specificatie en je krijgt de specificatie. Geef een bureau een verkenningsfase en je krijgt een document, overgedragen aan een developer die bij geen van die gesprekken was. Allebei prima als de software generiek is, en geen van beide als de waarde zit in wat niemand opschreef.

Vraag dus wie er nog is als je proces het databaseschema tegenkomt.

Hoe vertelt een goede bouwer je dat hij niet bij je past?

Vroeg, zonder dat je het vraagt, en met een reden die je kunt controleren. Iedereen die het inhuren waard is, kan beschrijven in wat voor project hij niet goed is.

We wijzen projecten af die niet passen: één helder stuk werk waarbij een team alleen overhead is, of werk dat breder is dan wij. Waar we kunnen, zeggen we wie beter past. Dat belooft de boekingspagina al voordat je ooit in gesprek gaat: jij beschrijft het probleem, wij zeggen of we kunnen helpen, en zo niet, wie wel. Dat in het eerste gesprek zeggen kost ons een project en bespaart jou een slecht project.

Stel alle drie dezelfde vragen. De antwoorden onderscheiden ze sneller dan welk portfolio ook:

  • Wie schrijft de code, en spreek ik die persoon ooit?
  • Wat gebeurt er als je een maand niet beschikbaar bent?
  • Tegen wat voor project zeg je nee?
  • Van wie zijn de code, de repository en de hosting aan het eind?
  • Wat kost maand twee, als het live is en er op vrijdag iets stukgaat?

Geen van de drie is de veilige keuze. De veiligheid zit in of het antwoord de persoon die het geeft iets kost. Daar is de boekingspagina voor: dertig minuten met ons allebei, en je gaat weg met een ja, een nee of een naam.

Herken je jouw week hierin? Dertig minuten is genoeg om het uit te zoeken.

Plan 30 minuten →
Volgende notitie Vaste prijs of nacalculatie bij software