Afgelopen dinsdag heb ik een product stopgezet.
Niet omdat het slecht was. Het werkte prima. Een Laravel-app die ik in maart had gelanceerd, met een strakke authenticatieflow, Stripe-integratie, een dashboard waar mijn eerste drie gebruikers daadwerkelijk op inlogden. Ik heb het stopgezet omdat ik me realiseerde — zittend aan mijn bureau om 23:47 uur, starend naar een feature-roadmap die ik had opgebouwd alsof het nog steeds 2023 was — dat ik AI aan het vastschroeven was op iets dat vanaf de eerste regel code rondom AI ontworpen had moeten zijn.
Dat is de rode oceaan. Daar zwemmen de meesten van ons nog steeds in, zonder het te beseffen.
De blauwe oceaan is iets totaal anders, en daar cirkel ik nu al zo’n zes maanden stilletjes omheen. Een AI-first bedrijf in 2026 heeft niet “een AI-feature”. Het heeft geen chatbot die rechtsonder vastgepind zit. In sommige gevallen is er zelfs helemaal geen traditionele UI — geen formulieren, geen dashboards, geen “nieuw project aanmaken”-knoppen. Het heeft een agent die het werk doet, een telefoonnummer dat de kandidaat belt, een stem die de e-mail aan je voorleest terwijl je rijdt. Het app-paradigma lost op. En als je nog steeds bouwt zoals je twee jaar geleden bouwde, maak je de software van gisteren met de tools van morgen eraan vastgeniet.
Ik denk hier veel over na in de context van Dan Martell’s venture studio — Martell Ventures — dat inmiddels het meest geciteerde praktijkvoorbeeld is van hoe een AI-first bedrijf in 2026 er operationeel uitziet. Het team van Martell mikt op $25 miljard aan enterprise value in drie jaar, en runt meer dan 15 AI-first bedrijven met een operationeel team van ongeveer 15 mensen. Dat is geen typefout. Eén ops-team. Meerdere bedrijven. Martell lanceerde eind maart ook APEX, een self-hosted AI-operatielaag voor founders die integreert met Slack, e-mail en WhatsApp. Het studiomodel werkt voor hem omdat hij 350+ playbooks heeft, decennia aan founder-kapitaal, en een netwerk waar de meesten van ons alleen maar van kunnen dromen.
Dus de vraag waar ik steeds op terugkom is: wat is er daadwerkelijk overdraagbaar naar een solo-operator of een team van vier? Wat is signaal, wat is theater, en waar breekt de overgang van doener naar directeur in de praktijk echt?
Dit is mijn eerlijke kijk. Ik voer mijn eigen versie van dit experiment al bijna een jaar uit binnen mijn merken. Sommige dingen werkten. Sommige dingen waren stilletjes gênant. Ik vertel je beide kanten.
De Rode Oceaan Waarin Je Waarschijnlijk Nu Zwemt
Laten we het goed definiëren, want "AI-first" is zo’n term geworden waar iedereen ja op knikt, maar die niemand echt kritisch onderzoekt.
AI-added is wat 95% van de SaaS-bedrijven momenteel doen. Je hebt een product. Het product werkt. Je voegt een AI-functie toe — samenvatting, autocompletion, een "chat met je data"-zijbalk. De kernworkflow blijft ongewijzigd. Een gebruiker logt nog steeds in, klikt op knoppen, vult formulieren in, exporteert CSV’s. De AI is een likje verf op een gebouw dat is ontworpen voor menselijke handen.
AI-first keert de hele stack om. De workflow ís de agent. De interface is welk medium de gebruiker op dat moment ook gebruikt — voice, SMS, e-mail, een Slack-thread. Het "product" is een set uitkomsten die het systeem levert, niet een set schermen waar de gebruiker doorheen navigeert.
Een recruitmentbedrijf genaamd Hero is het voorbeeld waar ik steeds op terugkom. Geen traditionele UI. Je vertelt wat voor rol je zoekt. Het schrijft de vacaturetekst. Het zoekt kandidaten. Het stuurt ze een sms. Het belt ze. Het pre-screent ze. Een mens komt pas in beeld op het beslismoment — niet bij de data-entry. Volgens recente analyse in MIT Sloan Management Review behalen bedrijven die zich echt rondom AI hebben georganiseerd 2-3x snellere productiteratiecycli dan digitale voorlopers die nog steeds in de "AI-feature toevoegen"-modus zitten. Dat verschil groeit elke maand.
Hier is de test die ik nu op mijn eigen producten loslaat. Stel jezelf deze ene vraag: Als ik morgen het AI-component verwijder, functioneert het product dan nog steeds?
Als het antwoord is "ja, het wordt gewoon minder handig" — dan ben je AI-added. Je product is een gebouw met een slimme thermostaat.
Als het antwoord is "nee, er is letterlijk geen product zonder" — dan ben je AI-first. De thermostaat ís het gebouw.
Mijn Laravel-app? Zonder AI was het identiek aan een SaaS van $9 per maand uit 2022. Toen wist ik het.
Maar er is iets wat de venture-studio-mensen niet hardop zeggen, en hier wil ik eerlijk tegen je zijn voordat we verder gaan. AI-first gaan is niet automatisch beter. Voor bepaalde categorieën — gereguleerde sectoren, high-trust B2B met inkoopcycli, alles waarbij je koper verwacht een scherm te zien voordat hij betaalt — is AI-added in 2026 nog steeds de juiste keuze. De vraag is niet "moet ik AI-first zijn." De vraag is "welk van mijn producten of lijnen verdient het om AI-first te zijn, en welke zijn prima als traditioneel softwareproduct met een slimme assistent die er netjes op zit."
De meeste solo-operators slaan die vraag over en bouwen uiteindelijk het verkeerde ding prachtig uit. Ik ben die persoon geweest. Twee keer.
Het Neural Transformation Framework — Wat Echt Standhoudt
Er is een framework dat Dan Martell zijn studio-operators aanleert, genaamd Neural Transformation. Op het eerste gehoor klinkt het als weer zo’n stukje consultancy-jargon. Maar er schuilt een echt idee achter, en dat idee is het waard om bij stil te staan.
De kern van de aanpak: focus op wat nooit verandert. In elke rol, in elke afdeling — HR, marketing, sales, engineering, operations — haal je de specifieke tools weg en vraag je je af wat het werk op het diepste niveau eigenlijk is. Het werk van een marketeer is niet “Instagram-captions schrijven.” Het is: een koper begrijpen, een boodschap produceren die hem of haar raakt, meten of het werkt, bijsturen. Dat werk is sinds de jaren vijftig hetzelfde gebleven. De tools veranderden vierhonderd keer. Het werk zelf nooit.
Als je een rol op dat niveau kunt zien, wordt AI vanzelfsprekend. Je vervangt de marketeer niet. Je stelt hem of haar in staat om tien keer zoveel output te leveren, omdat de laag “de boodschap produceren” van vier uur naar twaalf minuten teruggebracht wordt. Het 2026-rapport van het World Economic Forum over AI voorbij de experimenteerfase maakt hetzelfde punt op ondernemingsniveau: de organisaties die als eerste de drempel overgaan, zijn degenen die de manier waarop werk stroomt opnieuw hebben ingericht, niet degenen die simpelweg meer AI-licenties hebben aangeschaft.
De tweede stap in het framework — en de stap waarvan ik denk dat de meeste solo-operators hem zullen afwijzen — is deze: iedereen in je bedrijf moet kunnen coderen in het Engels. Niet in TypeScript. Niet in Python. In het Engels.
“AI-coderen is nu Engels” klinkt als een leuke oneliner, totdat je drie maanden lang daadwerkelijk probeert je bedrijf op deze manier te runnen. Dan houdt het op met schattig zijn en wordt het de belangrijkste filter bij het aannemen van mensen. Je HR-medewerker schrijft een Claude Code-prompt om het onboardingproces te herstructureren. Je marketingverantwoordelijke bouwt in gewoon Engels een custom scraper om concurrentieprijzen te verzamelen. Je customer success contractor ontwerpt een voice-agent voor tier-1 support. Geen van hen was “engineer”. Maar allemaal leveren ze nu software op.
De mensen in je team die deze omslag niet kunnen maken — of weigeren — worden het equivalent van die collega die in 2005 nog alles geprint wilde hebben. Je kunt ze uit loyaliteit houden. Je moet er niet op rekenen dat ze met het bedrijf meegroeien. Dit is het harde deel dat niemand op LinkedIn zet, en ik zeg het hier omdat de cijfers het daadwerkelijk aantonen.
Voordat we bij het punt komen waar ik uitleg hoe de overgang van doener naar directeur op manieren stukloopt die de goeroes niet benoemen, neem ik je eerst mee in wat die overgang eigenlijk inhoudt — want de meeste mensen hebben het mentale model verkeerd.
De Evolutie van Doener → Regisseur → Ontwerper
Er is een pad waarop elke operator en programmeur zich momenteel bevindt, of ze zich daar nu bewust van zijn of niet. Drie fasen. Jij bevindt je ergens op dat pad.
Fase 1: Doener. Je schrijft zelf de code. Je schrijft zelf de e-mail. Je ontwerpt zelf de landingspagina. Je handen raken elk deliverable aan. Hier zijn de meesten van ons begonnen, en lange tijd was dit de enige optie.
Fase 2: Regisseur. Je stopt met het regel voor regel schrijven van code. In plaats daarvan beschrijf je wat je wilt, AI produceert een eerste versie, en jij stuurt het resultaat bij. Je zit nog steeds diep in het werk — je beoordeelt elke agent-run, vangt elke hallucinatie, corrigeert elke toonfout — maar je handen zitten niet meer urenlang op het toetsenbord. Ze zitten aan het roer. Claude Code schrijft de feature. Jij beoordeelt de PR. Ik schreef een volledige uiteenzetting van hoe deze workflow er in de praktijk uitziet over de zes niveaus van Claude Code-beheersing als je de tactische diepgang wilt.
Fase 3: Ontwerper. Je stopt met het beoordelen van individuele outputs en begint systemen te ontwerpen die de outputs produceren. Je schrijft het draaiboek één keer. Je schrijft de system prompt van de agent één keer. Je ontwerpt de feedbackloop. Daarna draait het systeem, en jouw taak is om de metrics te monitoren, het draaiboek te verbeteren en patronen te herkennen. Je beoordeelt niet één PR — je kijkt naar 400 PR’s per week en vraagt je af of de onderliggende agent slimmer wordt of juist afdrijft.
Het venture studio-model opereert vrijwel volledig op het Ontwerper-niveau. Zo kunnen 15 mensen meer dan 15 bedrijven ondersteunen. Martell zelf schrijft geen prompts. Hij ontwerpt het meta-systeem dat de prompts schrijft.
Hier moet ik eerlijk zijn: ik leef nu ongeveer een jaar op het Regisseur-niveau, en de sprong naar Ontwerper is moeilijker dan de goeroes doen voorkomen. Specifiek breekt het op drie punten voor solo-operators.
Breekpunt 1: Je hebt niet genoeg volume om patronen te zien. De studio van Martell draait honderden agent-executies per dag over vijftien bedrijven. Patronen ontstaan omdat de data dicht opeengepakt is. Als je solo bent en je agent draait twaalf keer per dag, kijk je niet naar patronen — je kijkt naar individuele outputs, want twaalf is te weinig om van te abstraheren. Je wordt gedwongen terug te keren naar de Regisseur-modus, of je dat nu wilt of niet.
Breekpunt 2: Je kunt geen oordelen uitbesteden die je niet hebt uitgeschreven. Het Ontwerper-niveau vereist dat je een beslissing zo vaak hebt genomen dat je hem kunt codificeren in een draaiboek. Voor een beginnende founder die zijn eerste AI-first product lanceert, worden de meeste oordelen nog voor het eerst gemaakt. Er is geen “zo pakken we dit aan”, want je hebt het nog nooit aangepakt. Ik leerde dit op de harde manier toen ik probeerde kwaliteitsbeoordelingen van content te delegeren aan een agent voordat ik daadwerkelijk had gedefinieerd wat “goede content” betekende voor mijn eigen merkstem. De agent deed precies wat ik hem had opgedragen. Wat ik hem had opgedragen, was fout. Dat lag aan mij, niet aan de agent.
Breekpunt 3: De visie-coaching-uitbestedingsloop vereist een team. De pitch is: de CEO focust op visie, coacht het team op standaarden, en besteedt herhaling uit aan AI. Maar als je een eenmanszaak bent, ben je tegelijkertijd de CEO, het team dat gecoacht wordt, en de persoon die het repetitieve werk doet. De loop stort in. Je moet bewust tijd vrijmaken om elke rol apart te spelen, anders vervaagt alles tot dezelfde 14-urige werkdag als altijd.
Dus wat doe je nu echt als je solo bent? Dat is de sectie die telt.
Wat een Solo Operator Echt Moet Kopiëren van Martell Ventures
Hier is de lijst waar ik na een jaar experimenteren op ben uitgekomen. Ik ga niet doen alsof ik ze allemaal al onder de knie heb — de punten gemarkeerd als (in progress) zijn waar ik nog aan werk.
1. Bouw vanaf dag één je playbook-bibliotheek op. (Klaar.) Elke herhaalbare beslissing wordt opgeschreven zodra je hem drie keer hebt genomen. Tone-of-voice richtlijnen. Prijsregels. Selectiefilters voor aannames. Criteria voor feature-prioritering. Als je tien playbooks hebt, heb je een bedrijf. Met honderd heb je een machine. Ik heb er nu ongeveer 40. De meeste leven als Claude Code slash-commando’s, agent-definities en skill-bestanden in mijn repositories. Je ziet de opzet van dit systeem in mijn post over AI-agenten die het werk van solo operators herdefiniëren.
2. Kies één product en maak het écht AI-first. (Klaar, pijnlijk.) Probeer niet je hele portfolio om te bouwen. Kies het product waarbij de AI-first aanpak duidelijk sterker is en bouw het opnieuw op, vanaf de interface-laag naar buiten toe. Voice, SMS, e-mail, async — welk medium je gebruiker ook al gebruikt. Voor mij is dit een content-pijplijn die volledig binnen mijn bestaande tools draait; de "UI" is een Slack-bericht en het "dashboard" is de content zelf die verschijnt in Notion en Webflow.
3. Huur mensen in op hun bereidheid om in het Engels te coderen, niet op functietitel. (In progress.) Mijn aannamefilter is dit jaar veranderd. De enige vraag die ik nu stel: "Beschrijf de laatste keer dat je iets met AI hebt gebouwd wat je zonder AI niet had kunnen bouwen." Kunnen ze dat niet beantwoorden, dan kunnen ze niet in mijn stack werken. Dat klinkt hard. Dat is het ook. Maar het is het verschil tussen wel of niet kunnen opschalen.
4. Automatiseer eerst de repetitieve laag, daarna pas de beoordelingslaag. (Op de harde manier geleerd.) Begin met de delen van je workflow waar het antwoord altijd ongeveer hetzelfde is — formatteren, eerste versies, datatransformatie, boilerplate code, planningen. Begin niet met de onderdelen waar het antwoord afhangt van smaak, context of relatie. Die volgorde is belangrijker dan welke tool je kiest.
5. Meet agent-output zoals je een junior medewerker zou beoordelen. (In progress.) Niet "heeft de agent de taak afgerond" — dat is binair en waardeloos. Kijk in plaats daarvan naar: kwaliteitsrubriek, consistentie over tijd, verbeteringsgraad, kosten per bruikbare output. Industrie-analyse in 2026 suggereert dat de bedrijven die echte leverage uit AI halen, de agenten behandelen als beheerde teamleden met prestatiebeoordelingen, niet als magische dozen.
6. Bescherm één ongestructureerd blok per week. (Klaar.) Op Designer-niveau is de valkuil dat je zo hard optimaliseert dat je geen ruimte meer hebt voor doorbraken. Ik blokkeer één middag per week zonder agenda, zonder agent die draait, zonder dashboards open. Ik lees. Ik schets. Ik discussieer met mezelf. Dáár komen de playbooks voor het volgende kwartaal vandaan.
Wil je liever dat iemand anders de AI-first automatiseringslaag voor je bedrijf bouwt in plaats van dit zelf te doen, dan neem ik precies dit soort opdrachten aan via mijn Fiverr — agent-systeemontwerp, playbook-bibliotheken, Claude Code-workflows. Ik zie je liever zelf aan de slag gaan, maar als je snel wilt schakelen en het fundament gebouwd wilt hebben, is dat de weg.
Het Leiderschapsgedeelte Waar Niemand Eerlijk Over Schrijft
Er is een tweede onderdeel van Martells framework dat volgens mij minder aandacht krijgt dan het technische stuk, terwijl het misschien wel belangrijker is. Sam, een van zijn operators, onderwijst vijf leiderschapsregels die ik nu ongeveer acht maanden test op mijn eigen kleine team en netwerk van freelancers.
Hart voor de ziel, training voor de rol. Huur eerst op de mens. Train daarna de vaardigheid. In een AI-first setup worden vaardigheden goedkoper om aan te leren — je kunt iemand in twee weekenden Claude Code leren. Je kunt iemand niet leren om te geven om het werk. Stop met filteren op diploma’s en begin met filteren op karakter.
Standaard vertrouwen. Ga uit van het beste in de persoon tegenover je. Dit klinkt soft, maar is juist hard: de kosten van het wantrouwen van een goede kracht zijn veel hoger dan de kosten van het vertrouwen van een zwakke, want de zwakke valt binnen 90 dagen door de mand en de goede vertrekt als hij zich gecontroleerd voelt.
Train, vertel niet. Als je freelancer of teamlid een fout maakt, is de reflex om het juiste antwoord te geven. De juiste zet is om hun beoordelingsvermogen te trainen zodat ze de volgende keer zelf tot het juiste antwoord komen. Dit kost aanvankelijk meer tijd. Maar het schaalt oneindig. “Vertellen” doet dat niet.
Meet wat telt. Niet clicks, niet uren, niet regels code. Meet datgene wat het bedrijf daadwerkelijk vooruit helpt. Voor mij is dat: hoeveel AI-first workflows zijn er deze kwartaal productie-stabiel, en wat is het cumulatieve outputtempo per workflow. Al het andere is theater.
Wees het baken, niet de sleepboot. Je trekt je team niet vooruit. Je blijft staan waar je bent, blijft zichtbaar, en laat hen naar jou toe navigeren. Vooral solo-operators worstelen hiermee — onze reflex is om het zelf te doen. Als je die reflex niet tempert, bouw je nooit iets dat zonder jou draait. Het hele punt van de AI-first transitie is juist een bedrijf bouwen dat niet jouw handen aan elk touw nodig heeft.
Sam heeft ook iets wat hij de Builder’s Pyramid noemt: Standaarden > Talent > Strategie > Dromen. Ik lees dat als: “je standaarden voor kwaliteit en uitvoering zijn belangrijker dan wie je aanneemt, wat weer belangrijker is dan wat je kiest om te bouwen, wat weer belangrijker is dan de visie die je ervoor hebt.” De meesten van ons draaien dit om en raken geobsedeerd door de droom. De droom is het goedkoopste onderdeel. De standaarden zijn wat iedereen ziet en waar niemand over praat.
Wat LLM’s Echt Doen — En Waarom Dat Belangrijk Is Voor Hoe Je Bouwt
Een korte introductie, omdat ik nog steeds operators tegenkom die AI-first bedrijven runnen zonder een mentaal model van hoe de modellen waarop ze inzetten daadwerkelijk werken. Je kunt dit overslaan als je al vertrouwd bent met tokenisatie en transformers. Zo niet, dan zullen twintig minuten hierover de manier waarop je elk prompt het komende jaar ontwerpt, volledig veranderen.
Wanneer je een bericht typt naar Claude of GPT, gebeurt als eerste tokenisatie — je tekst wordt opgesplitst in kleine eenheden, grofweg woordfragmenten. “Incredible” kan bijvoorbeeld drie tokens worden. “The” is meestal één. Die tokens worden vervolgens gemapt in een embedding-tabel: een gigantisch numeriek raster waarin elke token een vector heeft die de betekenis ervan ten opzichte van alle andere tokens in de vocabulaire van het model encodeert.
Daarna doet de transformer-architectuur zijn werk. Het kijkt naar je reeks tokens, berekent attention — welke tokens in je prompt het meest relevant zijn voor welke andere tokens — en voorspelt de volgende token. Daarna de volgende. En weer de volgende. Dat is het. Dat is de hele truc. Een LLM is een next-token voorspeller, getraind op zoveel tekst dat zijn voorspellingen op redeneren beginnen te lijken.
Waarom is dit belangrijk voor hoe je een AI-first bedrijf bouwt? Drie praktische redenen:
Ten eerste, promptkwaliteit is hefboomwerking. Het model voorspelt de volgende token op basis van de tokens die jij hebt gegeven. Vage prompts voorspellen vage tokens. Specifieke prompts, met de juiste context vooraf geladen, voorspellen specifieke tokens. Daarom besteden de teams die echte output uit AI halen, onevenredig veel tijd aan prompt- en context-engineering in plaats van bij elk nieuw model te wisselen.
Ten tweede, spraakinterfaces zijn het volgende app-paradigma, en de reden daarvoor is architectonisch. Zodra een LLM betrouwbaar spraak kan ontvangen en spraak kan produceren met een latency onder de 500 ms, vervalt de hele noodzaak voor een visuele UI voor een enorme categorie taken. Het app-paradigma van de afgelopen vijftien jaar — iconen, schermen, knoppen — was een workaround omdat computers niet konden luisteren. Die workaround loopt ten einde. Tony, de AI CTO-assistent binnen Martell’s studio, is een voorproefje van hoe dit er operationeel uitziet: jij praat, het voert uit over je hele stack, jij krijgt een antwoord. Geen app om te openen. Geen formulier om in te vullen.
Ten derde, agents zijn te combineren. Een enkele LLM-call is beperkt. Een grafiek van LLM-calls, elk met een eigen rol, geheugen en tooltoegang, is een workforce. Dit is waar het agentic AI-transformatie framework dat Google publiceerde interessant wordt — de architectuur voor bedrijven die AI-first gaan is niet “één groot model in het midden van alles.” Het zijn tientallen kleine, doelgerichte agents die aan elkaar overdragen, elk ontworpen voor een specifieke rol.
Als het mentale model klikt, worden de ontwerpbeslissingen een stuk eenvoudiger. Als dat niet zo is, blijf je achter de glimmende model van de maand aanlopen.
Resultaten: Hoe Dit Er Na Een Jaar Echt Uitziet
Hier volgt een eerlijke weergave van waar ik na ongeveer elf maanden dit playbook op mijn eigen merken te hebben toegepast, ben uitgekomen. Ik geef je richtinggevende cijfers in plaats van verzonnen precisie, omdat ik liever eerlijk ben dan indrukwekkend.
Wat werkte. Mijn content-pijplijn is nu echt AI-first — ik beschrijf het artikel dat ik wil in een Slack-achtige workflow, agents doen onderzoek en schrijven een eerste versie, en ik besteed mijn tijd aan redactie op smaakniveau en positionering in plaats van schrijven vanaf een leeg scherm. De output op mejba.me is gegroeid tot 232+ posts. De kwaliteitslat ligt hoger dan toen ik alles met de hand schreef, omdat de agents niet moe worden en ik beslissingen neem over structuur en invalshoek in plaats van zinnen slijpen.
Wat deels werkte. De playbook-bibliotheek. Ik heb ongeveer 40 playbooks geschreven. De playbooks die ik het meest gebruik, zijn de beste. De playbooks die ik schreef en nooit meer aanraakte, zijn in feite ballast. De les: schrijf playbooks nadat je iets drie keer hebt gedaan, niet vooraf. Voorspellende playbooks zijn gokken. Terugblikkende playbooks zijn goud waard.
Wat niet werkte. Mijn eerste twee pogingen om oordeelsvorming te delegeren aan agents. Kwaliteitsbeoordelingen, aannamebeslissingen, prijsbepalingen — ik probeerde ze allemaal te vroeg te codificeren. In elk geval voerde de agent precies uit wat ik had opgegeven, en wat ik had opgegeven was een slechte benadering van wat ik eigenlijk geloofde. De oplossing was confronterend: doe het zelf nog 30-50 keer, let op wat je daadwerkelijk doet, en probeer het dan te codificeren.
Waar ik nog mee bezig ben. De sprong van Director naar Designer. Ik ben dichterbij dan in januari, maar ik ben er nog niet, en de eerlijke reden is breekpunt 1 uit het begin van deze post — ik heb nog niet het volume om patronen te herkennen zoals een venture studio met 15 mensen dat kan. Volume opbouwen is het project voor de komende 90 dagen.
Het compounding-effect is het deel dat ik niet had verwacht. Elk playbook dat ik schrijf, maakt de volgende makkelijker. Elke agent die ik inzet, versnelt de volgende implementatie. Elke maand voelt ongeveer twee keer zo productief als de maand ervoor, niet omdat ik harder werk, maar omdat het hefboomeffect dat ik opbouw cumulatief is. Dit is het aspect dat je van buitenaf niet voelt. Je moet er zes maanden inzitten voordat het kwartje valt.
Veelgestelde Vragen
Is een AI-first bedrijf realistisch voor een solo-operator in 2026?
Ja, voor ten minste één productlijn, mits je bereid bent om vanaf de interface-laag opnieuw te ontwerpen in plaats van AI op een bestaande codebase te plakken. Begin met één workflow waarbij spraak, sms of asynchrone berichten een dashboard volledig kunnen vervangen. De volledige "solo-operator realiteitscheck" wordt behandeld in de doer-to-director sectie hierboven.
Wat is het verschil tussen AI-first en AI-added?
AI-added betekent dat je product nog steeds zou werken als je de AI verwijdert — het is een functie bovenop traditionele software. AI-first betekent dat er geen product is zonder de AI — de agent is de workflow. De meeste SaaS in 2026 is nog steeds AI-added, maar noemt zichzelf AI-first.
Moet ik Python of TypeScript leren om een AI-first bedrijf te runnen?
Nee — maar je moet wel vloeiend kunnen beschrijven wat je wilt in gestructureerd Engels dat een agent kan uitvoeren. Die vaardigheid is nu de basis voor elke rol in een AI-first team, inclusief niet-technische functies zoals HR en marketing.
Wat is de grootste fout die mensen maken bij het overstappen naar AI-first?
Proberen om beoordelingsvermogen te delegeren voordat ze het hebben gecodeerd. Je kunt geen beslissing uit handen geven die je niet vaak genoeg hebt genomen om te kunnen verwoorden. Begin met het uitbesteden van herhalende taken — formatteren, eerste versies, datatransformatie — en ga pas over op beoordelingswerk nadat je zelf 30+ keer dezelfde beslissing hebt genomen.
Hoe lang duurt de transitie?
Eerlijk gezegd duurt het ongeveer een jaar voordat je het compounding effect voelt, en drie tot vijf jaar om een bedrijf er volledig omheen te herstructureren. Iedereen die een 30-dagen AI-first transformatie belooft, verkoopt je een cursus en beschrijft niet de realiteit.
De Zet
Hier is de vraag waar je vanavond eens goed bij stil moet staan: als ik morgen het AI-component uit mijn huidige product zou halen, zou het dan nog bestaan?
Als het antwoord ja is — dan heb je beslissingen te nemen. Niet per se "alles opnieuw bouwen." Meer zoiets als: kies één lijn, één workflow, één product, en ontwerp het opnieuw, beginnend bij de agent. Je hebt het netwerk van Dan Martell niet nodig of een operations-team van vijftien man. Je hebt één eerlijk uur met jezelf nodig, een notitieblok, en de bereidheid om de versie van het product te schrappen die ooit logisch leek.
De bedrijven die deze drempel in 2026 oversteken, gaan een voorsprong opbouwen die laatkomers niet meer kunnen inhalen, hoeveel geld ze er ook tegenaan gooien. Het goede nieuws is dat de drempel lager ligt dan het lijkt. Je hoeft niet overal AI-first te zijn. Je moet ergens AI-first zijn — en je moet intellectueel eerlijk zijn over waar dat is.
Ik heb afgelopen dinsdag een product de nek omgedraaid. Dit kwartaal bouw ik de AI-first versie. Spraak in, spraak uit, geen dashboard, geen inlogscherm, geen knoppen. Of het nu werkt of me voor schut zet, ik schrijf er sowieso over.
Jouw zet.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
