Agentische AI-transformatie: het vierstappenplan van Google
Afgelopen zondagochtend had ik een kleine discussie met mezelf. Ik had net het zevende "AI-agentje" in kaart gebracht dat ik dit kwartaal had gebouwd — een overzichtelijk Claude-gestuurd dingetje dat concurrentieprijzen scrapt, ze in een sheet zet en me een seintje geeft in Slack. Het werkt. Het bespaart me misschien veertig minuten per week. En terwijl ik naar het diagram staarde, realiseerde ik me iets ongemakkelijks.
Ik had zeven agents gebouwd. Ik had nul workflows gebouwd.
Dat onderscheid klinkt als semantisch geneuzel totdat je er even bij stilstaat. Dan klinkt het niet meer als geneuzel, maar als de volledige reden waarom de meeste enterprise AI-pilots stilletjes sneuvelen in hun tweede jaar. En dat is precies het probleem dat Google's nieuwe Agentic AI Transformation Framework — het framework dat Clara behandelt in de Agentic Strategy-cursus op Google Skills — probeert op te lossen.
Ik heb het grootste deel van drie dagen besteed aan het doorwerken van het framework, het naast mijn eigen projecten gelegd en getest of het ook buiten een gelikte retail-demo standhoudt. Sommige onderdelen hebben mijn aanpak voor mijn volgende klantproject daadwerkelijk veranderd. Sommige delen vind ik eerlijk gezegd te ingewikkeld voor solo-bouwers. En één onderdeel — de value engineering-fase — is precies het stuk waarvan ik wou dat iemand het me achttien maanden geleden had aangereikt.
Laat me je laten zien wat ik bedoel.
Het verschil tussen een agent en een agentische workflow
Hier is de zin die voor mij alles in een ander perspectief plaatste: een AI-agent voert een taak uit. Een agentisch AI-systeem voert een proces uit.
Toen ik die scraper voor concurrentieprijzen bouwde, bouwde ik een agent. Die doet één ding, op één moment, en stopt dan. Een mens moet nog steeds naar de data kijken, beslissen of onze prijs aangepast moet worden, het wijzigingsverzoek schrijven, goedkeuring krijgen en het live zetten. De agent is een hulpmiddel. De workflow is nog volledig menselijk.
Een agentisch systeem ontstaat wanneer je AI niet langer in losse taken plaatst, maar het volledige proces overdraagt. Het haalt concurrentieprijzen op. Het redeneert of het prijsverschil relevant is. Het controleert ons margebeleid. Het stelt een prijswijziging op. Het legt die voor aan de juiste goedkeurder. Het voert de update door in de productcatalogus. Het monitort de conversie de komende 72 uur en handhaaft de wijziging of draait deze terug.
Dat is geen grotere agent. Dat is een andere categorie systeem.
Volgens Google — en ik denk dat ze gelijk hebben — staan we met agentische AI op hetzelfde kantelpunt als bij cloud computing rond 2010 of mobiel rond 2008. Niet “handige nieuwe tool”, maar een reorganisatie van hoe werk gedaan wordt. De bedrijven die vroeg cloud-native architectuur begrepen, haalden het maximale uit de markt ten koste van bedrijven die AWS zagen als “gehuurde servers”. Diezelfde tweedeling ontstaat nu tussen agentische en taakgerichte AI.
En nergens is dat verschil duidelijker zichtbaar dan in de retail.
Agentic Commerce en de Stille Dood van de Klik
Hier is een cijfer waar elke e-commerce oprichter van zou moeten schrikken. eMarketer voorspelt dat door AI-platforms aangedreven e-commerce in 2026 ongeveer $20,9 miljard zal bereiken — zo’n verviervoudiging ten opzichte van 2025. McKinsey verwacht dat agentic commerce tegen 2030 $1 biljoen aan Amerikaanse retailomzet zal genereren. Morgan Stanley denkt dat tegen die tijd bijna de helft van de online shoppers AI-shopping agents zal gebruiken, goed voor ongeveer een kwart van hun uitgaven.
Vertaling: een aanzienlijk percentage van je toekomstige klanten zal je landingspagina nooit zien. Ze vertellen een agent wat ze nodig hebben. De agent koopt het.
Dit is wat mensen bedoelen met “zero-click commerce”, en het is nu al zichtbaar in de verkeersdata — het zoekmachineverkeer naar merk-specifieke bestemmingen daalt met ongeveer 25% richting 2026, met een duidelijke verschuiving naar GenAI-kanalen zoals ChatGPT, Perplexity en Gemini die zowel de ontdekking als (in toenemende mate) de transactielaag overnemen. Ongeveer 70% van de consumenten zegt zich in ieder geval enigszins comfortabel te voelen bij het laten doen van aankopen door een AI-agent. 45% gebruikt al AI-assistenten voor productideeën. 13% heeft daadwerkelijk een aankoop afgerond via zo’n agent — en dat cijfer is het kanariepietje, niet het plafond.
Ik kom straks terug op wat dit betekent voor de manier waarop je productpagina’s bouwt — er is een specifieke, pijnlijke implicatie voor SEO die de meeste teams nog niet hebben meegenomen. Maar eerst het framework zelf, want het framework bepaalt of je iets bouwt dat deze verschuiving overleeft, of iets dat eraan ten onder gaat.
Google's Vierfasenraamwerk, Getest op Echte Projecten
Het raamwerk bestaat uit vier fasen: Discover, Design, Build, Scale. Dat klinkt verdacht veel als elk ander consultancydeck dat ik heb gezien. Maar dat is het niet. De inhoud van elke fase is waar het zijn waarde bewijst, en de volgorde is belangrijker dan men doorgaans denkt. Ik neem je mee door elke fase zoals Clara die in de cursus structureert, en daarna vertel ik waar ik denk dat het in de praktijk buigt.
Fase 1: Discover — De "Wat Als"-Mindsetverschuiving
De Discover-fase is vooral cognitief. De these is dat de meeste bedrijven AI benaderen vanuit een "as-is"-perspectief — oftewel, ze kijken naar hun bestaande proces en vragen: "Waar kunnen we AI inzetten om dit sneller te maken?" Die vraag heeft een plafond, en dat plafond ligt laag. Je eindigt met een snellere versie van hetzelfde proces. Een taak van veertig minuten wordt een taak van twaalf minuten. Mooi. Niet transformerend.
De "wat als"-mindset stelt een andere vraag. Die zegt: als we een onvermoeibaar, redelijk intelligent systeem hadden dat dit hele end-to-end proces kon observeren, beslissen en handelen, hoe zou het proces er dan uitzien? Je stopt met het optimaliseren van de stappen en begint je af te vragen of die stappen überhaupt nodig zijn.
Ik probeerde deze oefening met een klant-onboardingworkflow die ik aan het "AI-ficeren" was voor een kleine SaaS. As-is-denken liet me een agent bouwen die welkomstmails opstelt. Wat-als-denken vroeg: waarom is er überhaupt een welkomstmail? De reden dat die bestond, was om een nieuwe gebruiker handmatig door de setup te leiden. Als een agent een nieuw account kan detecteren, de eerste sessie van de gebruiker kan volgen en proactief hulp kan bieden in het product zodra er frictie ontstaat — dan is er geen welkomstmail. Er is geen setupgids. Er is geen helpdeskticket over "hoe begin ik". De hele vorm van onboarding verandert.
Dat is het verschil tussen as-is en wat-als. En het ongemak van dat verschil is het daadwerkelijke resultaat van fase één. Je hoort deze fase lichtelijk gedesoriënteerd te verlaten. Als je vertrekt met een keurig lijstje "plekken om AI toe te passen", heb je het verkeerd gedaan.
Fase 2: Design — Value Engineering en Kritische Gebruikersreizen
Dit is de fase die volgens mij het echte juweel van het raamwerk is, en het is de meest onderbelichte in de discussie rond agentic AI. Fase twee doet twee dingen: het dwingt je om de zakelijke waarde van elk potentieel agentisch project te kwantificeren vóór je gaat bouwen, en het verplicht je om de Kritische Gebruikersreizen — de CUJ’s — die het agentische systeem moet doorlopen, in kaart te brengen.
Value engineering, simpel gezegd, is de discipline waarbij je weigert het volgende AI-project te bouwen totdat je drie vragen kunt beantwoorden: wat verandert dit concreet voor het bedrijf in euro’s of uren, wie is de mens die nu verantwoordelijk is voor dat resultaat, en wat gebeurt er met het werk van die persoon als de agent het goed doet. Kun je niet alle drie met details beantwoorden, dan gaat het project terug in de wachtrij. Het krijgt geen prioriteit omdat iemand op de leiderschapsoffsite het woord "AI" met overtuiging uitsprak.
Eerlijk gezegd — dit is de fase waarin ik zelf de grootste overtreder ben geweest. Ik hou van bouwen. Ik rationaliseer de waarde achteraf wel. Het raamwerk gaat er terecht van uit dat de meesten van ons dat doen, en bouwt de discipline in vóór er een regel code wordt geschreven.
Het onderdeel Kritische Gebruikersreizen is het operationele complement. Een CUJ is geen featurelijst. Het is het specifieke pad dat een echte gebruiker (of een echte agent namens een gebruiker) aflegt om iets belangrijks te bereiken. Je brengt de reis in kaart, markeert elk beslismoment, elke datadependentie, elke plek waar het huidige proces vastloopt of overdraagt aan een ander systeem. Vervolgens vraag je je af welke van die stappen een agent end-to-end kan uitvoeren en welke nog een mens in de loop vereisen.
Dit is belangrijk omdat de meeste "agentische" projecten niet falen omdat het model dom is, maar omdat niemand de reis in kaart heeft gebracht. De agent loopt vast bij stap 4 omdat de data van stap 3 in een systeem staat waar de agent niet bij kan. Of stap 6 vereist een goedkeuring die niemand heeft gedocumenteerd. Of de overdracht tussen agent en mens gebeurt via een Slack-kanaal dat alleen één specifieke manager monitort en verder niemand. CUJ-mapping brengt dit allemaal aan het licht vóór je gaat bouwen, wat ongeveer 200x goedkoper is dan het achteraf ontdekken.
Fase 3: Build — No-Code Prototyping met de Juiste Tools
Fase drie is waar het leuk wordt, en waar Google een behoorlijk gedurfde gok neemt. Het standpunt van het raamwerk is dat het prototype gebouwd moet worden door het crossfunctionele team dat de CUJ heeft gemapt — niet overgedragen aan een engineeringteam om te interpreteren. Het hele punt van no-code tools zoals Google AI Studio en Gemini Enterprise in deze fase is om de mensen die het dichtst bij het proces staan aan het stuur te houden terwijl het systeem vorm krijgt.
Dit deel van de cursus is gericht op AI-productmanagers — de expliciete insteek is dat een PM een werkend agentisch prototype moet kunnen bouwen zonder een enkel engineeringticket aan te maken. Ik heb hier gemengde gevoelens over. Aan de ene kant heb ik veel te vaak gezien dat enterprise AI-initiatieven sneuvelen in de kloof tussen de specificatie van een PM en de interpretatie daarvan door een engineer. De PM het prototype direct laten bouwen, overbrugt die kloof, en de versnelling is echt.
Aan de andere kant hebben no-code prototypes de neiging om per ongeluk productiesystemen te worden. Het ding dat in drie dagen is gebouwd "om het concept te bewijzen" wordt aan het leiderschap gedemonstreerd, leiderschap is enthousiast, en plotseling draait het in productie met de architecturale discipline van een zaterdagmiddag-hackathon. Ik heb dit zien gebeuren met Zapier-workflows, met Bubble-apps, met Notion-automatiseringen. Er is geen reden waarom agentische AI-prototypes hiervan gevrijwaard zouden blijven.
De discipline van het raamwerk rond fase drie is wat het redt. Prototypes zijn expliciet afgebakend als wegwerpproducten — proof of concept, geen productie. Het doel van deze fase is om te valideren dat de CUJ standhoudt als een agent hem daadwerkelijk uitvoert, dat de value engineering-cijfers kloppen, en dat de menselijke overdrachten werken. Als dat gevalideerd is, ga je door naar fase vier, waar het daadwerkelijke productiesysteem wordt gebouwd met de architectuur, beveiliging en observability die productie vereist.
Fase 4: Scale — De Fase Waar Niemand Over Wil Praten
De cursus is eerlijk over iets: fase vier — het daadwerkelijk opschalen en operationaliseren van agentische systemen binnen een onderneming — is de fase met het minst volwassen draaiboek. Iedereen is het nog aan het uitzoeken. De bedrijven die het hebben gedaan (en dat zijn er nog niet veel) behandelen het als een meermaandenprogramma met platformteams, governance-raamwerken, agent-observability en een duidelijk beleid voor wanneer de beslissingsbevoegdheid van een agent wordt geëscaleerd naar een mens.
De twee personages die Clara gebruikt om dit concreet te maken zijn Beth, Head of Strategy bij een fictieve retailketen genaamd Symbol Mart, en Tomo, de technische leider. Beth’s taak is om de agentische transformatie in lijn te houden met de bedrijfswaarde en ervoor te zorgen dat de geprioriteerde projecten daadwerkelijk de beoogde metrics beïnvloeden. Tomo’s taak is om ervoor te zorgen dat de systemen die gebouwd worden veilig, pragmatisch en schaalbaar genoeg zijn om de overgang van prototype naar enterprise deployment te overleven.
Die samenwerking is cruciaal. De reden dat de meeste agentische AI-initiatieven falen in fase vier, is dat ze exclusief eigendom zijn van één van die twee mensen. Alleen-Beth-leiderschap levert prachtige slide decks en prototypes op die nooit schalen. Alleen-Tomo-leiderschap levert robuuste systemen op die dingen automatiseren die niemand nodig had. De centrale operationele stelling van het raamwerk is dat het succespercentage in fase vier een functie is van hoe nauw die twee rollen gedurende de hele transformatie samenwerken.
Dat is het raamwerk. Nu vertel ik waar ik denk dat het buigt.
Wat Echt Werkt, en Wat Ik Overgeëngineerd Vind
Ik wil hier voorzichtig zijn, want het is makkelijk om een Google-framework te lezen en het klakkeloos te volgen of juist direct af te wijzen. Beide reacties zijn gemakzuchtig. Dit is wat ik daadwerkelijk denk na het doorlopen ervan.
De mindsetverschuiving in de Discover-fase is het belangrijkste onderdeel, en tegelijk het makkelijkst om over te slaan. Bijna niemand doet dit goed. Vrijwel iedereen stapt agentische AI in met het bestaande procesmodel en plaatst agents in de bestaande stappen. De prijs van het overslaan van de what-if-oefening is dat je een jaar besteedt aan het bouwen van agents die een gedoemd proces slechts iets sneller maken.
De value engineering-discipline uit de Design-fase is het onderdeel dat ik volledig overneem en toepas op mijn eigen werk, ook bij projecten die niets met agentische AI te maken hebben. Het principe is universeel toepasbaar — kwantificeer de waarde voordat je bouwt, benoem de persoon wiens werk verandert, en geef het project pas groen licht als je beide kunt doen. Waarschijnlijk schrijf ik hier nog een apart artikel over, want het verdient die aandacht.
De CUJ-mapping is inhoudelijk juist, maar in de praktijk wat zwaar voor alles onder enterprise-niveau. Ben je een startup met vijf mensen of een solobouwer, dan heb je geen formeel CUJ-document nodig. Je moet het workflowproces op een whiteboard doorlopen en de overdrachtsmomenten markeren. De formaliteit van het framework schaalt mee met de grootte van de organisatie. Gebruik het principe, schaal het artefact.
De nadruk op no-code in de Build-fase is terecht voor prototypes en riskant voor productie. Behandel het ook zo. Het prototype wordt snel gebouwd in Google AI Studio, Gemini Enterprise, of wat je stack ook is. Het productiesysteem wordt gebouwd met een echt engineeringproces. Laat de demo niet de uitrol worden.
De Scale-fase is waar het framework eerlijk is over zijn eigen beperkingen, en dat waardeer ik. Niemand heeft nog een draaiboek voor agentische transformatie op enterpriseniveau. Wat het framework je biedt, is de juiste organisatorische vorm — de Beth-en-Tomo-combinatie, de waardeafstemming, het technische pragmatisme. De details zul je al doende moeten uitvinden.
Wat het framework niet hardop zegt, maar eigenlijk wel zou moeten: een aanzienlijk deel van deze transformaties zal mislukken. Niet omdat het framework verkeerd is, maar omdat de organisatorische verandering die nodig is om het toe te passen echt moeilijk is. Een agent een end-to-end proces laten beheren betekent dat iemands baan verandert. Soms is die verandering een verrijking — ze gaan van het uitvoeren van het werk naar het superviseren van het systeem. Soms betekent het eliminatie. Het framework is een strategiedocument, geen verandermanagementdocument. Je hebt beide nodig.
Wat Dit Betekent Als Je Nu Aan Het Bouwen Bent
Als je een ontwikkelaar bent, is de meest waardevolle verschuiving om te stoppen met de vraag "welke taak kan ik automatiseren met een agent" en te beginnen met de vraag "welk proces kan ik overdragen aan een autonoom systeem." Een andere vraag, een andere architectuur, een ander waardemaximum. De agents die je bouwt vanuit de tweede vraag zijn naar mijn ervaring ongeveer tien keer zoveel waard als die vanuit de eerste.
Als je een productmanager of oprichter bent, is value engineering de meest impactvolle discipline die je dit kwartaal kunt adopteren. Voordat je het volgende AI-feature goedkeurt, schrijf in één alinea op: wat verandert er concreet voor het bedrijf als dit werkt, wie is vandaag de mens die verantwoordelijk is voor dat resultaat, en wat gebeurt er met hun werk als de agent het goed doet. Als je die alinea niet kunt schrijven, is het feature niet klaar om gebouwd te worden.
Als je een e-commercebedrijf runt, is de agentic commerce-verschuiving geen probleem voor 2030. Het is een probleem voor 2026. Het feit dat 70% van de consumenten zich comfortabel voelt met agent-gedreven aankopen betekent dat de koopagent die leeft in ChatGPT of Gemini gaat bepalen of jouw product überhaupt in de overwegingsset verschijnt, lang voordat de klant ooit jouw merknaam intypt. Dat heeft gevolgen voor de structuur van productdata, voor API-toegankelijkheid, voor hoe je je producten beschrijft op een machine-leesbare manier. Als je vandaag een productpagina bouwt voor de shopper van morgen, bouw je voor een koper die stilletjes wordt vervangen.
Als je een enterprise-leider bent, is de Beth-en-Tomo-combinatie het deel om te internaliseren. Vind jouw Beth. Vind jouw Tomo. Laat ze samen eigenaar zijn van de transformatie. Als een van beiden ontbreekt of buitenspel staat, zal het programma wel iets opleveren — slides of systemen — maar geen transformatie.
Een Kanttekening bij de No-Code Belofte
Er is een aspect van de positionering van deze cursus waar ik graag voorzichtig tegenin wil gaan. De belofte dat AI-productmanagers productieklare agentische systemen kunnen bouwen zonder engineers is, naar mijn eerlijke mening, deels waar en gevaarlijk verleidelijk.
Het deels-ware deel: PM’s kunnen absoluut prototypes bouwen die de CUJ aantonen, de waarde valideren en de workflow demonstreren. Dat is echt, en het is een betekenisvolle doorbraak. Het gevaarlijk-verleidelijke deel: de kloof tussen een werkend prototype en een productiesysteem dat beveiliging, schaalbaarheid, foutafhandeling, observability, compliance en de edge cases die na 73 uur onafgebroken draaien opduiken aankan, is enorm. Die kloof is waar engineering om draait. No-code overbrugt die niet. Het maakt het prototype sneller, en dat is geweldig. Zie het ook als zodanig.
De juiste manier om Google’s nadruk op no-code te lezen is niet “engineers zijn niet langer nodig voor agentische AI.” Het is: “de prototypingfase hoeft niet langer te wachten op engineeringcapaciteit, waardoor meer ideeën sneller gevalideerd kunnen worden, waardoor engineeringcapaciteit besteed wordt aan de prototypes die hun waarde bewezen hebben.” Dat is een veel bescheidener claim, en het is degene waarvan ik denk dat die daadwerkelijk standhoudt.
Wat Ik Deze Week Anders Doe
Terugkomend op de discussie van zondagochtend waarmee ik begon — die waarin ik me realiseerde dat ik zeven agents en nul workflows had gebouwd — heb ik gisteren een van die agents opnieuw ontworpen.
De concurrentieprijs-scraper wordt nu een concurrentieprijzensysteem. Het haalt nog steeds de data op. Maar nu redeneert het systeem of het prijsverschil relevant is gezien onze margedrempel, stelt het een voorgestelde prijsaanpassing op, stuurt mij een korte goedkeuringsaanvraag met de bijbehorende motivatie, en voert na goedkeuring de wijziging door. Vervolgens monitort het 72 uur lang de conversie, waarna het besluit om de wijziging te behouden of terug te draaien. Het werk dat ik vroeger deed — data bekijken, beslissen, uitvoeren, monitoren — wordt nu ondersteund door het systeem. Mijn taak is om de voorgestelde wijziging goed of af te keuren. Dat is een proces, geen taak.
Het kostte me ongeveer vier uur om het te herontwerpen. Ik schat dat het me voortaan vier uur per maand zal besparen. De agent-versie bespaarde me veertig minuten per week. De workflow-versie bespaart me een halve dag. Zelfde model, zelfde data, zelfde tools — maar een andere vraag gesteld tijdens het ontwerpproces.
Daarvoor is het framework eigenlijk bedoeld. Niet om betere slides te maken over AI-strategie. Maar om je een andere vraag te laten stellen op het moment dat de hele architectuur van wat je bouwt wordt bepaald.
Kies deze week één ding dat je al hebt "ge-AI-ficeerd" als taak. Stel de what-if-vraag erover. Vraag je af of een agentisch systeem het hele proces kan overnemen in plaats van slechts een onderdeel. Als het antwoord ja is, ontwerp het dan opnieuw. Als het antwoord nee is, vraag dan waarom — want dat "nee" wijst meestal op de echte beperking, en die beperking is meestal een menselijke overdracht die niemand in kaart heeft gebracht.
Dat is, meer dan welk framework dan ook, de echte stap vooruit.
Veelgestelde Vragen
Wat is het verschil tussen een AI-agent en een agentisch AI-systeem?
Een AI-agent voert één enkele taak uit; een agentisch AI-systeem voert een volledig proces autonoom uit over meerdere stappen, beslissingen en overdrachten. De agent is een hulpmiddel binnen een nog steeds door mensen aangestuurde workflow. Het agentische systeem vervangt de workflow zelf. Voor een diepgaandere uitleg met voorbeelden, zie de bovenstaande sectie over agents versus workflows.
Wat zijn de vier fasen van Google's Agentic AI Transformation Framework?
De vier fasen zijn Discover (mindsetverschuiving van as-is naar what-if), Design (waarde-engineering plus Critical User Journey mapping), Build (no-code prototyping met tools zoals Google AI Studio en Gemini Enterprise), en Scale (operationeel maken van agentische systemen binnen de hele organisatie). De volgorde is belangrijk — het overslaan van Discover is de meest voorkomende faalmodus.
Wat is agentische commerce en waarom is het belangrijk in 2026?
Agentische commerce is e-commerce die wordt uitgevoerd door AI-agents die namens menselijke shoppers handelen — een "zero-click" koopervaring waarbij de agent ontdekt, evalueert en aankoopt zonder dat de gebruiker een website bezoekt. eMarketer voorspelt $20,9 miljard aan door AI-platforms aangedreven e-commerce in 2026, ongeveer een verviervoudiging ten opzichte van 2025, terwijl McKinsey $1 biljoen verwacht tegen 2030.
Wat is een Critical User Journey (CUJ) in agentisch AI-ontwerp?
Een Critical User Journey brengt het specifieke end-to-end pad in kaart dat een gebruiker (of agent die namens hen handelt) aflegt om een betekenisvol resultaat te bereiken, waarbij elke beslissing, datadependentie en overdracht wordt gemarkeerd. CUJ-mapping brengt de operationele hiaten aan het licht die agentische projecten de das omdoen — ontbrekende data-toegang, niet-gedocumenteerde goedkeuringen, gebroken overdrachten — nog voordat er code is geschreven.
Kunnen AI-productmanagers agentische systemen bouwen zonder engineers met no-code tools?
Gedeeltelijk. Productmanagers kunnen gevalideerde prototypes bouwen met tools zoals Google AI Studio en Gemini Enterprise, wat een aanzienlijke versnelling oplevert. Maar de stap van een werkend prototype naar een productiesysteem dat beveiliging, schaalbaarheid, foutafhandeling en observability aankan, vereist nog steeds engineering. De juiste benadering is snellere prototyping, niet het vervangen van engineering.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.
- Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise-oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
