10 juni 2026
One man company, hoe ik in mijn eentje bouw wat eerder een team vroeg
Afgelopen week keek ik naar mijn eigen lijstje en moest ik even lachen. Er draait een AI-platform waar organisaties veilig met hun eigen kennis kunnen werken. Er draait een LLM-router op Europese infrastructuur. Er staat een coding agent cloud in de steigers. Daarnaast geef ik presentaties, doe ik consultancytrajecten en schrijf ik blogs zoals deze. En het team achter dat alles ben ik. Eén persoon, een laptop, een stapel servers en een verzameling AI-tools.
Vijf jaar geleden was dit een belachelijk plan geweest. Niet omdat ik de onderdelen niet zou snappen, maar omdat de uren simpelweg niet bestonden. Voor elk van die producten had je destijds een klein team nodig: iemand voor de backend, iemand voor de frontend, iemand voor infra, en het liefst nog iemand die de documentatie bijhield. Nu doe ik het alleen. En ik ben daar lang niet de enige in: overal duiken eenpersoonsbedrijven op die softwareproducten draaien waar vroeger een bureau voor werd ingehuurd.
Ik wil eerlijk opschrijven hoe dat werkt. Niet als succesverhaal, want het schuurt op genoeg plekken. Maar wel als praktijkverslag, omdat ik denk dat dit iets zegt over hoe bedrijven straks naar teams en uitbesteding gaan kijken.
Wat er veranderd is
Het korte antwoord: de prijs van een eerste versie is ingestort.
Vroeger zat de meeste tijd van softwarebouwen niet in het moeilijke deel. Die zat in het saaie deel. Formulieren, API-endpoints, databasemigraties, foutafhandeling, het zoveelste inlogscherm. Allemaal werk dat gedaan moet worden, dat niemand leuk vindt, en dat per project net anders genoeg is dat je het niet zomaar kunt kopiëren.
Coding agents hebben precies dat deel overgenomen. Ik beschrijf wat ik wil, het model schrijft een eerste versie, en ik beoordeel of het klopt. Voor boilerplate werkt dat verrassend goed. Voor de eerste versie van een feature ook. Niet omdat het model briljant is, maar omdat tachtig procent van softwarewerk patroonwerk is, en patronen zijn precies waar deze modellen goed in zijn.
Hetzelfde geldt buiten de code. Een eerste opzet van documentatie, een ruwe versie van een presentatie, redactie op een tekst die ik zelf heb geschreven: het scheelt allemaal uren. Geen dagen per taak, maar wel een structurele factor over de hele linie. En die factor telt op. Het verschil tussen "dit kost drie weken" en "dit kost vier dagen" is niet alleen sneller. Het is het verschil tussen een product dat er komt en een product dat op de stapel goede ideeën blijft liggen.
Daar komt nog iets bij dat minder vaak genoemd wordt: de drempel om iets úit te proberen is bijna verdwenen. Twijfel ik of een aanpak werkt, dan laat ik een agent in een uurtje een prototype bouwen en weet ik het. Vroeger was dat een beslissing, nu is het een middagje.
Wat AI niet overneemt, en dat is het echte werk
Hier wordt het interessant, want de lijst van wat AI niet doet is korter maar zwaarder.
AI heeft geen smaak. Het model schrijft je tien werkende versies van een scherm, maar het weet niet welke goed voelt. Het weet niet dat die ene extra instelling het product juist slechter maakt. Elke keuze over wat erin gaat, wat eruit gaat en hoe iets hoort te voelen, is van mij. En die keuzes bepalen uiteindelijk of iets een product is of een demo.
AI heeft geen focus. Sterker nog, het maakt focus moeilijker. Als alles in een middag te bouwen is, wordt nee zeggen het schaarse goed. Mijn grootste risico is niet dat ik te weinig kan maken. Het is dat ik te veel begin. Drie producten en een consultancypraktijk naast elkaar draaien lukt alleen als ik streng ben over wat ik níet doe, en dat is een spier die geen enkele tool voor je traint.
AI maakt geen productkeuzes. Welke klant bedien ik wel en welke niet? Bouw ik deze feature omdat een klant erom vraagt of omdat het product hem nodig heeft? Wordt dit een betaald onderdeel of niet? Dat zijn vragen waar geen prompt voor bestaat, want het antwoord hangt af van wat je wilt zijn als bedrijf.
En AI draagt geen verantwoordelijkheid. Als de router van een klant midden in een demo hapert, kan ik niet naar mijn tooling wijzen. De code mag dan voor een flink deel door een agent zijn geschreven, de handtekening eronder is van mij. Dat betekent dat ik alles wat live gaat moet begrijpen, kunnen verdedigen en kunnen repareren. Code accepteren die je niet snapt is geen tijdwinst, het is een lening met rente.
Waar het schuurt: alles is jouw probleem
Dit is het deel dat in de enthousiaste verhalen over solo ondernemen met AI meestal ontbreekt.
Een team is niet alleen bouwcapaciteit. Een team is ook redundantie. Als ik op vakantie ben, is er niemand die de monitoring in de gaten houdt. Als er om elf uur 's avonds een security-advisory uitkomt over een library die ik gebruik, is er niemand anders die hem leest. Support, security, infra, facturen, contracten, de AVG-vraag van een klant: het komt allemaal op hetzelfde bureau terecht, en dat bureau is van mij.
In de praktijk betekent dat een paar dingen.
Ik moet conservatiever bouwen dan een team. Elke exotische technologiekeuze, elke extra service, elke dependency is iets wat ik er over twee jaar in mijn eentje nog uit moet kunnen vissen. Saaie, bewezen techniek is voor een one man company geen gebrek aan ambitie, het is overlevingsstrategie.
Ik moet eerlijk zijn over beschikbaarheid. Ik kan geen 24/7 support beloven, dus ik beloof het niet. Wel duidelijke afspraken over reactietijden, automatische monitoring die mij eerder wakker maakt dan de klant, en systemen die zichzelf herstellen waar dat kan. Een deel van mijn AI-tooling zet ik trouwens precies hiervoor in: logs samenvatten, incidenten voorsorteren, de eerste analyse doen voordat ik er zelf naar kijk. De agent is mijn eerste lijn, ik ben de tweede.
En ik moet accepteren dat sommige klanten afvallen. Er zijn organisaties die terecht een leverancier willen met een team, een SLA met tanden en een continuïteitsplan dat niet afhangt van één persoon. Daar kan ik twee dingen mee doen: erover liegen, of het onderdeel van het gesprek maken. Ik kies het tweede, inclusief afspraken over broncode-toegang en exit-scenario's. Gek genoeg wekt dat vaak meer vertrouwen dan de grote belofte.
De kwetsbaarheid blijft. Dat is geen voetnoot, dat is de fundamentele trade-off van dit model. Wie je vertelt dat AI dat probleem oplost, heeft het nog niet zelf gedragen.
Wat dit betekent voor bedrijven
Je kunt dit lezen als een verhaal over zzp'ers, maar ik denk dat de echte verschuiving bij organisaties ligt.
Ten eerste: de rekensom achter uitbesteden verandert. Veel werk dat nu naar bureaus en detacheerders gaat, bestaat voor een groot deel uit precies het werk dat AI goed overneemt: standaardschermen, koppelingen, rapportages, het zoveelste interne portaal. Als één ervaren persoon met goede tooling dat werk kan doen, gaat de vraag verschuiven van "hoeveel mensen zet je erop" naar "wie is die ene persoon en hoe goed is die". Dagtarief maal aantal koppen wordt een steeds slechtere maat voor wat je krijgt.
Ten tweede: het kleine, senior team wordt het interessante model. Niet één persoon voor alles, dat is voor de meeste organisaties terecht te kwetsbaar. Maar ook niet meer het team van tien waarvan zes mensen vooral patroonwerk doen. Twee of drie ervaren mensen met agents eronder kunnen verrassend veel aan, mits ze de verantwoordelijkheidskant serieus regelen. Voor wie teams samenstelt of inhuurt is dat de vraag voor de komende jaren: niet "hoe groot", maar "hoe senior, en met welke tooling".
Ten derde: de bottleneck verschuift naar smaak en richting. Als bouwen goedkoop wordt, wordt weten wát je moet bouwen het schaarse onderdeel. Dat klinkt abstract, maar je ziet het direct in de praktijk: organisaties die AI-tooling omarmen zonder iemand die keuzes maakt, produceren vooral sneller meer half afgemaakte dingen. Snelheid zonder richting is gewoon duurdere chaos.
En ten vierde, voor wie zaken doet met kleine leveranciers zoals ik: stel de continuïteitsvraag gewoon. Wat gebeurt er als jij wegvalt? Waar staat de code, waar draait de infrastructuur, wat zijn de afspraken? Een serieuze one man company heeft daar een antwoord op. Wie er omheen praat, heeft het niet geregeld.
Een eerlijk denkmodel
Voor wie zelf overweegt om dit te doen, of overweegt om met zo iemand te werken, dit zijn de vragen die er volgens mij toe doen:
- Kan ik elk onderdeel dat live staat zelf uitleggen en repareren, ook de delen die een agent heeft geschreven?
- Is mijn techniekkeuze saai genoeg om over twee jaar nog alleen te beheren?
- Heb ik monitoring en alerting die problemen eerder ziet dan mijn klanten?
- Wat is mijn eerlijke verhaal als een klant vraagt naar vakantie, ziekte en continuïteit?
- Wat doe ik bewust níet, en staat dat ergens opgeschreven?
De laatste vraag is de belangrijkste. AI verlaagt de prijs van bouwen, maar daarmee stijgt de prijs van geen keuzes maken.
Tot slot
Ik draai in mijn eentje een portfolio dat vijf jaar geleden een team had gevraagd. Dat is geen claim dat ik een team ben. AI neemt het patroonwerk over: de boilerplate, de eerste versies, de redactie. Wat overblijft is precies het werk dat altijd al het echte werk was: smaak, focus, productkeuzes en verantwoordelijkheid dragen voor wat er draait.
De one man company is geen truc en geen toekomstbeeld, het bestaat al en het werkt. Maar het werkt alleen voor wie de keerzijde net zo serieus neemt als de snelheid. Alles wat misgaat is jouw probleem. Dat is geen reden om het niet te doen. Het is wel de reden dat dit model niet draait op tooling, maar op de persoon die ermee werkt.
↘︎ ALLE ARTIKELEN
- Waarom Europa eigen AI-modellen moet ontwikkelen
- De verborgen dataflow achter een simpele AI-vraag
- RAG begrijpelijk uitgelegd
- Het verschil tussen data residency en echte data-soevereiniteit
- Shadow AI: het datalek dat al gebeurd is
- Van AI-demo naar productie
- Embeddings en vector databases: de kopie van je bedrijfskennis waar niemand het over heeft
- AI-geletterdheid: waarom tooling zonder begrip een risico is
- Hoe je een open-source model host
- Agents, tool permissions en prompt injection: als AI niet alleen praat maar ook doet
- Waarom data in Europa houden belangrijk kan zijn
- Model gateways en LLM-routers, de verkeerstoren van je AI-landschap
- De AI Act is geen beleidsstuk, het is een technisch project
- Bedrijfskennis veilig aan AI koppelen: wie wat mag zien geldt ook voor de assistent
- GPU-infra zonder mist: VRAM, batching, latency en wat AI echt kost
- Observability, logs en audit trails voor AI, kun je terugzien wat er gebeurde?
- OpenAI-compatible APIs, de stekker die overal in past
- Self-hosting, Europese cloud en vendor lock-in, waar zit je nou echt vast?
- Use-case: host je eigen model in Europa
- One man company, hoe ik in mijn eentje bouw wat eerder een team vroeg
- Reverse engineering, bouw een compleet softwarepakket na in een dag
- Use-case: je complete boekhouding laten doen door een agent
- Een supervisor-agent voor al mijn projecten, een kopie van mezelf
- DeepGov, waarom honderden gemeenten niet elk hun eigen AI hoeven te bouwen
- The age of open source: de standaardkeuze voor AI kantelt
- Je moet het kunnen bedenken, AI werkt vooral als je het grotere plaatje ziet
- Gebruiken we over twee jaar nog wel een scherm?