Ik Testte Gemini 3.1 Flashlight — Google's Snelheidswonder
Driehonderddrieënzestig tokens per seconde.
Ik las dat getal op het specificatieblad en dacht dat het een typefout was. Ik werk al lang genoeg met AI-modellen om te weten dat snelheidsclaims vrijwel altijd gepaard gaan met voetnoten, kleine lettertjes en benchmarkomstandigheden die je in de praktijk nooit tegenkomt. Dus toen Google Gemini 3.1 Flashlight lanceerde — gepositioneerd als hun snelste, meest kostenefficiënte model tot nu toe — deed ik wat elke sceptische ontwikkelaar zou doen. Ik opende mijn terminal, haalde de API op en begon er echte taken aan te geven.
Wat er de komende uren gebeurde, verraste me oprecht. Niet omdat het model perfect is — dat is het absoluut niet — maar omdat het fundamenteel veranderde hoe ik denk over welk model thuishoort in welk deel van mijn development stack. Er bestaat een specifieke categorie werk waarbij Flashlight niet alleen concurreert met grotere modellen. Het beschaamt ze regelrecht.
Maar ik loop op de zaken vooruit. Voordat ik je vertel wat me omver blies (en wat tegenviel), moet je begrijpen wat Google hier eigenlijk probeerde te bouwen — en waarom dat ertoe doet als je voor je werk code schrijft.
Waarom Nog Een "Light" Model Dit Keer Wél Uitmaakt
Dit viel me het afgelopen jaar op in het AI-modellandschap: de kloof tussen "flagship" en "efficiënte" modellen blijft krimpen op rare, onvoorspelbare manieren. We gingen er vroeger vanuit dat kleinere modellen duidelijk inferieur waren — handig voor snelle classificatietaken of chatbotopvulling, maar niets wat je zou vertrouwen voor echt engineeringwerk.
Die aanname brokkelt af. Snel.
Gemini 3.1 Flashlight zit in een categorie die Google hun snelheidsgeoptimaliseerde laag binnen de Gemini 3-familie noemt. Het verhaal is eenvoudig: neem de intelligentiewinsten van Gemini 3, schrap de overhead die grote modellen duur en traag maakt, en lever iets wat ontwikkelaars zich écht kunnen veroorloven op schaal te draaien — zonder het gevoel te hebben dat ze hebben gedowngraded.
De prijsstelling vertelt een deel van het verhaal: $25 per miljoen input tokens, met output tokens variërend van $0,50 tot $1,50 per miljoen afhankelijk van je configuratie. Dat is agressief. Niet "gratis tier hobbyproject" goedkoop, maar ruim binnen bereik voor productiewerklast waarbij je dagelijks duizenden API-calls doet.
Interessanter zijn de prestatiegegevens. Op de GPQA-benchmark — die redeneren op academisch niveau test — scoorde Flashlight 86,9%. De MMU Pro-benchmark, die multimodale begripsvaardigheden evalueert, kwam uit op 76,8%. En op de Arena leaderboard behaalde het een ELO-score van 1400. Dat zijn geen "light model"-cijfers. Dat zijn cijfers die achttien maanden geleden flagship-niveau waren geweest.
Ik weet uit ervaring dat benchmarks slechts de helft van het verhaal vertellen. De andere helft zit in wat er gebeurt als je het model echt aan het werk zet. Dáár werd het pas echt interessant.
De Snelheidstest Die Mijn Mening Veranderde
Mijn eerste echte test was eenvoudig maar veelzeggend. Ik vroeg Flashlight een 360-graden productviewer-component te genereren — het soort ding dat je op een hoogwaardige e-commercesite zou zien. Meerdere camerahoeken, soepele rotatie en een kleurwisselfunctie. Niet triviaal, maar ook geen raketwetenschap.
De reactie kwam binnen enkele seconden terug. Niet "redelijk snel" seconden. Het soort snelheid waarbij je je afvraagt of het model je verzoek daadwerkelijk heeft verwerkt of gewoon een template heeft gecached.
Het had niets gecached. De code was specifiek afgestemd op mijn prompt, goed gestructureerd en — dit overviel me — visueel aantrekkelijker dan wat ik van Gemini 3.1 Pro had gekregen voor een vergelijkbare taak. Een lichter, goedkoper model dat betere front-end output levert dan zijn grotere broer. Dat hoort niet te gebeuren.
Ik draaide de component in mijn browser. Soepele rotatie. Werkende camerahoeken. De kleurwisseling had een kleine fix nodig, maar de basis was solide. Voor rapid prototyping was dit precies het soort output dat me een uur scaffolding bespaart.
Voordat je denkt dat ik ga beweren dat Flashlight overal perfect in is — dat is het niet. Toen ik de complexiteit opschroefde, begonnen er scheuren te ontstaan. Een multi-component dashboard met onderling afhankelijke widgets? Het haalde zo'n 70%. Sommige instructieopvolgingsgaten slopen erin, waarbij het model beperkingen die ik in de prompt had gesteld leek te vergeten.
Maar hier kom ik steeds op terug: de kosten voor die onvolmaakte output waren verwaarloosbaar. Als je snel itereert, is een 70%-oplossing voor een tiende van de prijs en driemaal de snelheid vaak waardevoller dan een 95%-oplossing die meer tijd en geld kost om te genereren. Je dicht de gaten sneller dan je op het dure model wacht.
Die afweging klopt niet altijd. Maar voor de workflows die ik dagelijks gebruik — rapid prototyping, componentgeneratie, UI-verkenning — is dit een game-changer op dit prijsniveau.
De "Thinking Level"-Functie Waar Niemand Over Praat
Hier is iets dat de meeste reviews van Flashlight over het hoofd zien, en eerlijk gezegd denk ik dat het de belangrijkste functie van het hele model is.
Gemini 3.1 Flashlight heeft een instelbaar "thinking level". Je kunt de redeneerdiepte op- of afschroeven afhankelijk van je taak. Eenvoudige chatreactie? Zet het laag. Complexe meerstaps codegeneratie? Zet het hoog.
Waarom maakt dit uit? Omdat het betekent dat je niet betaalt voor redenering die je niet nodig hebt.
Elke AI-ontwikkelaar heeft dit meegemaakt: je stuurt een eenvoudig opmaakverzoe naar een krachtig model, het "denkt" veel te lang, verbrandt tokens, en levert een antwoord dat veel uitgebreider is dan nodig. De thinking level-instelling elimineert dat verspilling.
Ik testte dit in drie scenario's:
Laag thinking level — JSON-data herformatteren en basis type-definities genereren. Responstijden daalden drastisch, kosten waren minimaal en de kwaliteit was precies wat ik nodig had. Geen overdenken.
Medium thinking level — React-componenten genereren met specifieke stijlvereisten en state management. Goede balans tussen snelheid en nauwkeurigheid. Dit werd mijn standaardinstelling voor de meeste ontwikkeltaken.
Hoog thinking level — Multi-file codegeneratie met complexe bedrijfslogica en foutafhandeling. Trager, maar de outputkwaliteit sprong merkbaar omhoog. Het model ving edge cases die het bij lagere instellingen miste.
De mogelijkheid om dit per verzoek dynamisch aan te passen is echt krachtig voor productiesystemen. Stel je voor dat je eenvoudige gebruikersvragen naar de lage denkmodus routeert en complexe analytische verzoeken naar de hoge denkmodus — allemaal vanuit hetzelfde model, met hetzelfde API-eindpunt. Je infrastructuur blijft eenvoudig, je kosten blijven geoptimaliseerd en je gebruikers krijgen passende antwoordkwaliteit voor hun specifieke behoeften.
Ik zie niet genoeg ontwikkelaars over dit patroon praten, maar het wordt standaardpraktijk. Onthoud mijn woorden.
Echte Taken, Echte Resultaten: De Volledige Analyse
Praten is goedkoop. Benchmarks zijn interessant. Maar wat telt is of het model nuttig werk levert. Ik besteedde een volledige dag aan het gooien van steeds moeilijkere taken naar Flashlight, en dit vond ik.
Front-End Development: Verrassend Sterk
Dit is waar Flashlight echt uitblinkt — en ik wil specifiek zijn over wat ik bedoel.
Voor het genereren van enkelvoudige componenten (kaarten, modals, navigatiebalkjes, productweergaven, interactieve widgets) levert Flashlight output die gelijk staat aan of af en toe beter is dan modellen die 5-10 keer meer kosten. De code is schoon, de CSS is modern en de componenten werken echt wanneer je ze in een project plakt.
Ik genereerde een volledige productshowcasepagina met geanimeerde overgangen, responsieve breakpoints en toegankelijke opmaak. Het model trof de responsieve werking de eerste keer precies. De animaties hadden aanpassing nodig — het koos een springgebaseerde overgang terwijl ik een lineaire ease wilde — maar de structuur was solide.
Waar het moeite heeft: multi-pagina lay-outs met complexe routeringslogica, diep geneste state management-patronen en taken waarbij de prompt meer dan 6-7 afzonderlijke vereisten bevat. Het model begint beperkingen te laten vallen bij dat complexiteitsniveau.
Mijn oordeel: Als je front-end prototyping doet, component library-ontwikkeling of UI-verkenning, zou Flashlight je standaardmodel moeten zijn. Schakel alleen over naar iets zwaardere wanneer je het echt nodig hebt.
Codegeneratie Buiten de Browser
SVG-generatie? Uitstekend. Ik vroeg om een vlinder met vleugelklapanimaties, en het resultaat was oprecht indrukwekkend — correcte SVG-paden, vloeiende CSS keyframe-animaties en passende kleurverloopen. Het geheel renderde prachtig.
Algemene hulpfuncties, API-eindpunt scaffolding, datatransformatiepijplijnen — allemaal solide. Flashlight schrijft competente, leesbare code voor alledaagse programmeertaken.
Waar ik het plafond merkte: complexe algoritmische implementatie. Toen ik vroeg om een geoptimaliseerd graaftraversalalgoritme met specifieke geheugenbeperkingen, was de eerste poging correct maar naïef. Een krachtiger model had direct naar de optimale oplossing gegrepen.
Game- en Simulatiegeneratie: Het Wilde Kaart
Hier werd het leuk — en hier moesten mijn verwachtingen het meest bijgesteld worden.
Ik vroeg Flashlight een 2D-racegame te bouwen met animatie en real-time rendering. Wat terugkwam was... eigenlijk best goed? De rijfysica gebruikte slimme wiskundige shortcuts om momentum en drift te simuleren. De rendering loop was soepel. Het baanontwerp was eenvoudig maar functioneel.
Daarna pustte ik harder. Een 3D Formula 1-autodriftsimulatie. Hier raakte Flashlight zijn echte grenzen. De simulatie was technisch functioneel — de auto bewoog, de fysica had enige basis in werkelijkheid en het renderde zonder te crashen. Maar visueel? Het zag eruit als een PlayStation 1-game. Niet op een charmante retro manier. Op een "dit raakte duidelijk het complexiteitsplafond van het model"-manier.
Eerlijk gezegd had ik dat verwacht. Het genereren van overtuigende 3D-graphics uit één prompt is nog steeds een ontzettend moeilijk probleem, en Flashlight is expliciet geoptimaliseerd voor snelheid, niet voor het doorbreken van grenzen van wat AI-gegenereerde code visueel kan doen. Dat het überhaupt iets functioneels produceerde is al opmerkelijk.
Mijn eerlijke mening: Gebruik Flashlight niet voor complexe gamedev of rijke 3D-simulaties. Gebruik het voor 2D-games, interactieve demo's en visuele prototypes waarbij de iteratiesnelheid belangrijker is dan visuele afwerking.
Langvormige Tekstgeneratie: Beter Dan Verwacht
Ik vroeg Flashlight een analytisch essay te schrijven over de thematische diepgang van In de Ban van de Ring, met de nadruk op narratieve impact en filosofische onderbouwingen. Waarom dit onderwerp? Omdat literaire analyse aanhoudend coherent redeneren, thematische verbinding en structuurbesef vereist — precies het soort ding waarbij "light"-modellen gewoonlijk tekortschíeten.
Het essay kwam terug goed georganiseerd, met een duidelijke these, ondersteunende argumenten die daadwerkelijk op elkaar voortbouwden en specifieke tekstuele referenties. Het proza zou geen Pulitzer winnen, maar het was aanzienlijk beter dan wat Gemini 3 Flash opleverde voor dezelfde prompt — en het arriveerde merkbaar sneller.
Voor ontwikkelaars die contenttools, samenvattingspijplijnen of documentatiegeneratoren bouwen, is dit relevant. Snelheid plus aanvaardbare kwaliteit op schaal is het hele spel.
De Kilo Code-Integratie: Waar Snelheid Workflow Ontmoet
Een van de dingen die me het meest indrukten was niet Flashlight zelf — het was hoe goed het werkt binnen de Kilo Code CLI-tool en VS Code-extensie.
Ik plugde Flashlight in de autonome modus van Kilo Code, waarbij het model meerstaps redeneerketens afhandelt: bestanden lezen, verificatie uitvoeren, externe tools gebruiken en output genereren in een continue workflow. De ervaring was opmerkelijk soepel.
Hier is een concreet voorbeeld. Ik vroeg het een Mac OS-achtige browserinterface te genereren met basis functionele apps — een rekenmachine, kladblok en bestandsbrowser. Van prompt tot werkende output: 35 seconden. Totale kosten: 8 cent.
Acht cent. Voor een multi-component, multi-app-interface met basisinteractiviteit.
Waren de apps volledig afgewerkt? Nee. De rekenmachine werkte. Het kladblok was functioneel maar basic. De bestandsbrowser was meer een statische mockup dan een echte bestandssysteeminterface. Maar als startpunt voor iteratie? Dat is een ongelooflijke kosten-waardeverhouding.
De integratie verwerkt ook live dataverificatie, wat betekent dat het model zijn eigen output kan controleren aan de hand van echte databronnen tijdens de generatie. Dat is een subtiele maar krachtige mogelijkheid voor het bouwen van betrouwbare autonome workflows.
Pro tip: Kilo Code biedt momenteel $25 aan gratis gebruikskredieten voor hun CLI-tool. Als je Flashlight in een echte ontwikkelomgeving wilt testen — en dat zou je moeten — is dit de manier met de minste wrijving om te beginnen.
Wat de Meeste Mensen Fout Begrijpen Over Dit Model
Ik wil eerlijk zijn over iets. Na Flashlight uitgebreid te hebben getest, denk ik dat de ontwikkelaarsgemeenschap het in twee tegengestelde richtingen verkeerd inschat.
De hype-menigte behandelt het alsof het een model is dat Pro-tier opties voor alles kan vervangen. Dat kan het niet. Complexe multi-file refactoring, diep architectureel redeneren en genuanceerde instructieopvolging vereisen nog steeds krachtigere modellen. Als je Flashlight in een workflow plaatst die echt diep redeneren nodig heeft, raak je gefrustreerd.
De sceptici verwerpen het als "gewoon nog een klein model" dat alleen nuttig is voor speelgoedprojecten. Dat is even fout. Voor de specifieke werklast waarvoor het geoptimaliseerd is — snelle generatie, hoogvolume taken, real-time toepassingen en front-end prototyping — is Flashlight op zijn prijsniveau echt de beste beschikbare optie.
De slimme zet is niet kiezen voor Flashlight ÓF een groter model. Het is het bouwen van routeringslogica die de juiste taken naar het juiste model stuurt. Eenvoudige generatietaken, UI-prototyping, contentopmaak, basis code scaffolding — stuur deze naar Flashlight. Complexe redenering, multi-beperkingsproblemen, architectuurbeslissingen — stuur die naar Pro.
Ik leerde dit de harde manier. Mijn eerste instinct was alles door Flashlight te laten lopen omdat de snelheid verslavend was. Binnen een dag had ik genoeg edge cases geraakt om te beseffen dat modelkeuze taakspecifiek moet zijn, niet one-size-fits-all.
Hier is de ongemakkelijke waarheid die niemand wil toegeven: het model dat "het beste" is, hangt volledig af van wat je nu aan het doen bent, niet van wat het hoogst scoorde op een leaderboard. Flashlights 1400 ELO maakt niet uit als jouw taak mogelijkheden vereist die het niet heeft. En Pro's superieure redenering maakt niet uit als je taak eenvoudig genoeg is dat je gewoon geld verbrandt aan onnodige compute.
De Prijsrealiteitscheck
Ik noemde dat Flashlight $25 per miljoen input tokens kost. Dat verdient nader onderzoek.
Toen ik deze prijs voor het eerst zag, had ik een gemengde reactie. Aan de ene kant is het, gezien de prestaties die je krijgt, concurrerend. Aan de andere kant verwachtte ik dat Google agressiever zou zijn gezien de "light"-positionering. Modellen in deze efficiëntietier van andere aanbieders kunnen lager uitkomen.
Hier is mijn breakdown na een dag echt gebruik:
- Lichte prototypingsessie (15-20 componentgeneraties, laag thinking level): ruwweg $0,30-0,50
- Zware ontwikkelsessie (complexe meerstaps taken, hoog thinking level): ruwweg $2,00-4,00
- Het Mac OS-browserproject (autonoom meerstaps met Kilo Code): $0,08
Voor individuele ontwikkelaars en kleine teams zijn deze kosten triviaal. Voor productiesystemen die duizenden calls per uur doen, wordt de berekening interessanter — en hier compenseert Flashlights snelheidsvoordeel echt. 2,5x snellere time-to-first-token betekent dat je gebruikers minder wachten, je infrastructuur meer gelijktijdige verzoeken aankan en je kosten per verzoek lager blijven.
Mijn ruwe berekening: het overschakelen van geschikte workloads van een Pro-tier model naar Flashlight bespaarde me ongeveer 60-70% op API-kosten terwijl de responstijden daadwerkelijk verbeterden. De kwaliteitscompromis bestond maar was acceptabel voor de taken die ik ernaartoe routeerde.
Als Google de prijs zelfs 20-30% verlaagt — en concurrerende druk suggereert dat ze dat misschien doen — wordt dit een vanzelfsprekende standaard voor de meerderheid van API-calls van ontwikkelaars.
De Echte Benchmark: Mijn Productieworkflow
Benchmarks vertellen je wat een model kan doen onder gecontroleerde omstandigheden. Wat ik echt wil weten, is wat het doet in mijn rommelige, echte ontwikkelworkflow.
Na een week integratietesten is hier hoe Flashlight een permanente plek in mijn toolkit verdiende:
Ochtendprototypingsessies: Wanneer ik ideeën verken, verschillende UI-benaderingen probeer of snel nieuwe functies scaffold, is Flashlight nu mijn standaard. De snelheid betekent dat ik door 5-6 variaties kan itereren in de tijd die het vroeger kostte om één te genereren. Dat is geen kleine verbetering — het verandert fundamenteel hoe ik ontwerpverkenning benader.
Klantendemoproductie: Wanneer ik snel interactieve prototypes moet bouwen om aan klanten te laten zien, brengt Flashlight plus Kilo Code me van concept naar klikbare demo in minuten. Geen gepolijste productiecode, maar overtuigend genoeg voor een ontwerpbeoordeling.
Documentatie- en contentpijplijnen: Voor het genereren van gestructureerde content, herformatteren van data en het bouwen van documentatie uit codecommentaar, handelt Flashlight 90% van mijn behoeften af voor een fractie van de kosten.
Wanneer ik nog naar grotere modellen grijp: Complexe debugsessies waarbij ik het model nodig heb om te redeneren over subtiele interactiepatronen. Multi-file refactoring waarbij context over vele bestanden ertoe doet. Architectuuraanbevelingen waarbij ik het "beste denken" van het model wil, niet het snelste denken.
De combinatie van snel-en-goedkoop plus langzaam-en-krachtig is echt effectiever dan elk afzonderlijk. Het is alsof je zowel een sportwagen als een bestelwagen hebt. Je rijdt niet met de bestelwagen naar de supermarkt, en je vervoert geen hout in de sportwagen.
Waar Flashlight Past in de Gemini 3-Familie
Voor context: zo positioneer ik de huidige Gemini 3-lineup op basis van mijn tests:
Gemini 3.1 Pro — je zware krachtpatser. Complexe redenering, multi-beperkingsproblemen, taken waarbij je de absolute beste output van het model nodig hebt en kosten secundair zijn. Ik grijp hiernaar wanneer de taak moeilijk is en de inzet hoog.
Gemini 3.1 Flashlight — je snelle loper. Hoogvolume generatie, rapid prototyping, real-time toepassingen en elke taak waarbij iteratiesnelheid belangrijker is dan perfectie bij de eerste poging. Dit is mijn standaard voor 60-70% van dagelijkse ontwikkeltaken.
Gemini 3 Flash — het efficiënte model van de vorige generatie. Heeft nog steeds zijn plek, maar Flashlight overtreft het op snelheid en kwaliteit in vrijwel elke test die ik uitvoerde. Als je Flash nog gebruikt, upgrade dan.
De 45% snellere outputsnelheid en 2,5x verbetering in time-to-first-token ten opzichte van Flash zijn geen incrementele verbeteringen. Ze overschrijden een drempel waarbij het model echt real-time aanvoelt. Prompts die vroeger voelden als "wachten op de AI" voelen nu aan als "een gesprek voeren."
Die perceptuele verschuiving is belangrijker dan welk benchmarkcijfer dan ook, omdat het verandert hoe ontwikkelaars met het model omgaan — en uiteindelijk wat ze ermee bouwen.
Mijn Voorspelling: Het Thinking Level-Patroon Gaat Overal Naartoe
Ik noemde het instelbare thinking level eerder, en ik wil er op terugkomen omdat ik oprecht geloof dat dit de meest vooruitstrevende functie in Flashlight is — en één die elke grote modelaanbieder binnen de komende 12 maanden zal kopiëren.
Het idee is eenvoudig: niet elk verzoek heeft dezelfde hoeveelheid redenering nodig. Een model dat zijn rekenkundige inspanning per verzoek dynamisch kan aanpassen is niet alleen efficiënter — het is nuttiger. Je krijgt eigenlijk meerdere modellen in één API-eindpunt.
Ik denk dat we naar een wereld gaan waar modelkeuze niet "kies een model" is maar "kies een redeneerbudget." Je stelt een thinking level in voor elke API-call op basis van de verwachte complexiteit, en het model wijst dienovereenkomstig compute toe.
Flashlight is het eerste model dat ik heb gebruikt waarbij dit niet alleen een theoretisch concept is maar een praktische, productieklare functie. En zodra je ermee begint te bouwen, voelt terugkeren naar fixed-reasoning-modellen verspillend.
De ontwikkelaars die dynamische redeneerallocationering als eersten doorgronden, zullen een betekenisvol kosten- en snelheidsvoordeel hebben. Dit is het patroon om in de gaten te houden.
Wat Ik Een Ontwikkelaar Zou Vertellen Die Flashlight Overweegt
Als je twijfelt, hier is mijn eerlijke aanbeveling.
Begin met het identificeren van de 30-40% van je huidige AI API-calls die "eenvoudig" zijn — opmaak, basisgeneratie, enkelvoudige componentcode, datatransformatie. Routeer die vandaag naar Flashlight. Meet de kostenbesparingen en snelheidsverbeteringen. Je zult directe resultaten zien.
Breid dan geleidelijk uit. Test het in je prototypingworkflows. Probeer het voor documentatiegeneratie. Duw het in je CI/CD-pijplijn voor geautomatiseerde codebeoordelingscommentaren of testgeneratie.
Je zult de grens vinden waar Flashlights kwaliteit onder jouw drempel daalt. Die grens is jouw schakelpunt — alles eronder gaat naar Flashlight, alles erboven blijft bij je huidige model.
Die grens ligt hoger dan je denkt. Ik verwachtte snel Flashlights grenzen te raken. In plaats daarvan handelde het zo'n 65% van mijn dagelijkse workload beter of vergelijkbaar af met de zwaardere modellen die ik daarvoor gebruikte — en voor een fractie van de kosten en latency.
Het model is beschikbaar via Google AI Studio, de Gemini API, OpenRouter en de Kilo Code CLI/VS Code-extensie. Mijn aanbeveling: begin met Kilo Code's gratis credits om het in je echte ontwikkelomgeving te testen, schakel dan over naar directe API-toegang zodra je de fit hebt gevalideerd.
Driehonderddrieënzestig tokens per seconde. Ik begon dit artikel met de gedachte dat dat getal marketinghype was. Na een week het daadwerkelijk verschepen van code met Flashlight als mijn primaire generatie-engine, denk ik dat het misschien de meest praktisch relevante spec in AI op dit moment is. Niet omdat snelheid alles is — maar omdat zodra generatie snel genoeg is om instant aan te voelen, je stopt met wachten en begint te bouwen. En dat verandert wat mogelijk is.
Laten We Samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je tech-infrastructuur opschalen? Ik help je graag.
- Fiverr (custom builds & integraties): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (enterprise oplossingen): ramlit.com
- ColorPark (design & branding): colorpark.io
- xCyberSecurity (beveiligingsdiensten): xcybersecurity.io
