GPT 5.4 getest: het beste AI-programmeermodel op dit moment?
Drie dagen geleden laadde ik een volledige Laravel-monoliet — 847 bestanden, ruwweg 120.000 regels code — in een enkel GPT 5.4-contextvenster. Geen chunking. Geen samenvattingen. Geen "hier is het relevante bestand"-workarounds die ik jarenlang had gedaan. Gewoon de hele codebase, rauw, in één sessie gedropt.
Toen vroeg ik het een race condition te vinden in mijn queue worker die productie al twee weken achtervolgde.
Het vond de bug in negentig seconden. Geen gok. Geen "dit zou het probleem kunnen zijn." Het traceerde het uitvoeringspad over vier services, identificeerde het exacte moment waarop twee workers dezelfde job konden pakken, en schreef een fix met een database-level advisory lock die ik te koppig was geweest om te overwegen. Ik staarde een volle minuut naar mijn scherm voordat ik de patch zelfs maar testte.
Dat moment — dat specifieke, viscerale "wacht, wat is er net gebeurd"-moment — is waarom ik dit artikel schrijf. GPT 5.4 is geen incrementele update. Het is het eerste AI-programmeermodel dat me oprecht deed heroverwegen hoe ik mijn volledige ontwikkelworkflow structureer. Maar het is niet perfect, en een deel van de hype eromheen slaat al door. Ik moet scheiden wat echt is van wat marketingruis is, want als je op het punt staat je toolchain rond dit model te reorganiseren, verdien je een eerlijke beoordeling van iemand die het daadwerkelijk heeft stressgetest.
Het contextvenster van een miljoen tokens verandert alles aan hoe je werkt
Ik klaag al over contextvenster-beperkingen sinds GPT-4's oorspronkelijke limiet van 8K tokens in 2023. Elke AI-codingtool die ik heb gebruikt, vereiste een versie van dezelfde dans: zorgvuldig selecteren welke bestanden je opneemt, gedetailleerde samenvattingen schrijven van de delen die niet passen, en hopen dat het model geen verbanden hallucineert tussen code die het niet echt kan zien. Met Claude Code en Opus 4.6 werd het contextbeheer slimmer — de tooling handelt veel automatisch af — maar de fundamentele beperking was altijd aanwezig. Je werkte altijd met een onvolledig beeld.
GPT 5.4 ondersteunt tot een miljoen tokens aan context. Dat is geen theoretisch maximum ergens in de documentatie. Dat is een bruikbaar, praktisch contextvenster dat ik de afgelopen week meerdere keren heb gevuld met echte codebases.
Dit is wat er verandert wanneer context geen bottleneck meer is.
Ten eerste stop je met nadenken over wat je moet opnemen. Ik besteedde vroeger vijf tot tien minuten aan het begin van elke complexe debugsessie om te beslissen welke bestanden relevant waren. Soms had ik het mis, ontdekte halverwege dat ik een configuratiebestand of middleware nodig had die ik niet had opgenomen, en moest het gesprek opnieuw beginnen. Met GPT 5.4 laad ik gewoon alles. Het model zoekt uit wat relevant is. Die keuzestress verdwijnt volledig.
Ten tweede worden transversale vraagstukken triviaal om te analyseren. Wil je begrijpen hoe authenticatie door je hele applicatie stroomt? Hoe een enkele omgevingsvariabele door configuraties, services en deploymentscripts propageert? Vragen die me vroeger dwongen handmatig paden door tientallen bestanden te traceren — GPT 5.4 beantwoordt ze gewoon. Het heeft het complete beeld. Het kan de databasemigratie, het model, de controller, de API-route, de frontend-aanroep en de test allemaal tegelijkertijd zien.
Ten derde — en dit verraste me — verbetert de codegeneratiekwaliteit van het model dramatisch wanneer het meer context kan zien. Ik voerde een informeel experiment uit: ik vroeg GPT 5.4 twee keer om een nieuwe functie aan een project toe te voegen. Eén keer met alleen de relevante bestanden (ongeveer 15 bestanden, zo'n 3.000 tokens aan code). Eén keer met de volledige codebase geladen. De tweede poging produceerde code die overeenkwam met mijn bestaande patronen, mijn custom helperfuncties gebruikte in plaats van ze opnieuw uit te vinden, en de naamgevingsconventies volgde die ik maanden geleden had vastgesteld. De eerste poging produceerde generieke, correcte-maar-vreemde code. Hetzelfde model. Dezelfde prompt. Het enige verschil was context.
Ik moet de praktische beperking hier noemen: het laden van een miljoen tokens is niet gratis. De API-kosten schalen met inputtokens, en een volledige codebase-load bij elke interactie zou je tegoed snel opbranden. Voor verkennende sessies en complex debuggen is het elke cent waard. Voor routinematige "schrijf deze functie"-taken betaal je te veel. Ik heb een patroon ontwikkeld waarbij ik de volledige codebase laad voor architectuurniveau-werk en kleinere, gerichte contexten gebruik voor dagelijks programmeren. Die balans voelt goed — maar je zult je eigen moeten vinden.
Computer Use: wanneer je AI zijn eigen code gaat testen
Dit is de functie die me recht deed zitten. GPT 5.4 kan met applicaties interageren zoals een mens dat zou doen — knoppen klikken, schermen lezen, door interfaces navigeren. OpenAI noemt het "computer use," en hoewel de naam klinkt als marketingpraat, is de mogelijkheid echt nieuw terrein voor een programmeermodel.
Ik testte dit op een React-dashboard dat ik aan het bouwen was. Ik vroeg GPT 5.4 om een data-exportfunctie toe te voegen, en in plaats van alleen de code te schrijven en aan mij terug te geven, schreef het de code, opende de app in een browser, navigeerde naar het dashboard, klikte op de exportknop die het zojuist had gemaakt, verifieerde dat de CSV correct werd gedownload, merkte op dat de datumopmaak in één kolom verkeerd was, ging terug en repareerde de code, en testte opnieuw. Allemaal zonder dat ik iets aanraakte.
Laat me eerlijk zijn over de huidige stand: het is indrukwekkend maar niet productierijp voor complexe testworkflows. Het model handelt rechttoe-rechtaan UI-interacties goed af — formulieren invullen, knoppen klikken, navigeren. Maar het worstelt met applicaties die sterk afhankelijk zijn van hover-states, drag-and-drop of complexe animatietiming. Ik liet het een Kanban-boardfunctie testen en het kon niet betrouwbaar kaarten tussen kolommen slepen. Het wist wat het wilde doen. De motoriek was er nog niet.
Waar computer use al uitblinkt, is in de feedbackloop die het creëert. Traditioneel gaat de AI-codingworkflow als volgt: code schrijven → handmatig testen → problemen rapporteren aan de AI → itereren. Die middelste stap — het handmatig testen — is waar het meeste tijd naartoe gaat. Niet omdat testen moeilijk is, maar omdat het vertalen van visuele resultaten naar tekstbeschrijvingen voor de AI traag is en informatie verliest. "De knop is er maar staat verkeerd gepositioneerd" verliest informatie vergeleken met het model dat de knop daadwerkelijk ziet.
GPT 5.4's computer use vouwt die loop samen. Het model schrijft, test, ziet het resultaat en itereert — allemaal binnen één interactie. Voor eenvoudige functies reduceert dit de ontwikkelcyclus van vier stappen naar één. Ik bouwde en testte een compleet contactformulier — validatie, foutstatus, succesbericht, e-mail verzenden — in één enkele prompt. Het model doorliep drie iteraties op eigen houtje voordat het de definitieve versie presenteerde. Elke iteratie repareerde echte problemen die het ontdekte door het formulier daadwerkelijk te gebruiken.
Ik verwacht dat deze mogelijkheid snel zal verbeteren. Het onderliggende visiemodel is sterk. De interactielaag heeft alleen nog wat verfijning nodig. Over zes maanden vermoed ik dat computer use standaard zal zijn voor AI-programmeermodellen. GPT 5.4 was er het eerst, en zelfs in zijn huidige vorm heeft het veranderd hoe ik over de testfase van ontwikkeling denk.
De redeneermodussen die er echt toe doen
GPT 5.4 wordt geleverd met selecteerbare redeneermodussen — "high" en "ultra-high" — en mijn eerste reactie was scepsis. Redeneermodussen voelden als een marketingcheckbox. "Ons model denkt harder als je het vriendelijk vraagt." Maar na uitgebreid gebruik van beide modussen ben ik van gedachten veranderd. Het verschil is echt, meetbaar en de moeite waard om te begrijpen.
High reasoning modus is wat je wilt voor 80% van de programmeertaken. Functies schrijven, code refactoren, tests genereren, complexe logica uitleggen. Het is snel, nauwkeurig en betrouwbaar. De responstijden zijn vergelijkbaar met wat ik heb ervaren bij andere topmodellen — je zit niet te wachten.
Ultra-high reasoning modus is voor de problemen die je ertoe brengen je laptop dicht te klappen en een wandeling te maken. Architectuurbeslissingen met doorwerkende gevolgen. Debuggen van race conditions in concurrente systemen. Analyseren van beveiligingskwetsbaarheden door een hele codebase. Prestatie-optimalisatie waar de bottleneck niet voor de hand ligt. Dit zijn problemen waar "harder nadenken" daadwerkelijk andere — en betere — antwoorden oplevert.
Ik voerde een directe vergelijking uit op een echt probleem: het optimaliseren van een databasequery die 14 seconden duurde op een tabel met 2,3 miljoen rijen. In high modus stelde GPT 5.4 voor om een index toe te voegen en een subquery als JOIN te herschrijven. Standaard optimalisatieadvies. Correct, maar dat had ik al geprobeerd. In ultra-high modus analyseerde hetzelfde model het query-uitvoeringsplan, identificeerde dat de optimizer een hash join koos waar een merge join sneller zou zijn gezien de datadistributie, stelde een query hint voor om de merge join af te dwingen, adviseerde een partiële index op de gefilterde kolom, en wees erop dat mijn WHERE-clausule indexgebruik verhinderde vanwege een impliciete typeconversie die ik niet had opgemerkt. De ultra-high respons duurde ongeveer twaalf seconden langer. Het bespaarde me ongeveer drie uur handmatige queryanalyse.
De les die ik hieruit heb getrokken: gebruik ultra-high niet standaard. Begin met high. Escaleer wanneer je vastloopt of wanneer het probleem oprecht diepere analyse vereist. Ultra-high modus verbruikt meer tokens en kost meer tijd — het is een gereedschap, geen instelling om permanent ingeschakeld te laten. Maar wanneer je het nodig hebt, is het verschil tussen "goede suggestie" en "dat is precies het inzicht dat me ontbrak" het wachten waard.
GPT 5.4 vs Opus 4.6: de eerlijke vergelijking die niemand wil maken
Ik gebruik beide. Dagelijks. Ik ga niet doen alsof één categorisch beter is dan de ander, want dat zou oneerlijk en onbehulpzaam zijn. Hier is wat ik heb gevonden na weken waarin ik beide modellen op dezelfde projecten heb ingezet.
GPT 5.4 wint op backend-complexiteit. Voor grote codebases, complex debuggen, multi-service-architecturen en taken die vereisen dat je enorme hoeveelheden context tegelijkertijd vasthoudt, is GPT 5.4 momenteel het sterkere model. Het contextvenster van een miljoen tokens is het voor de hand liggende voordeel, maar het gaat niet alleen om capaciteit. Het vermogen van het model om te redeneren over verre delen van een codebase — een databaseschema-wijziging verbinden met de doorwerking door een API-laag, een frontend state management-systeem en een testsuite — voelt kwalitatief anders dan wat ik van andere modellen krijg.
Opus 4.6 wint op frontend- en UI-werk. Dit verraste me eerlijk gezegd. Ik verwachtte dat GPT 5.4 over de hele linie zou domineren. Maar wanneer ik React-componenten bouw, layouts ontwerp, met CSS-animaties werk of itereer op visueel ontwerp, levert Opus 4.6 consistent betere resultaten. De componenten zien er gepolijster uit. De CSS is schoner. Het designgevoel — en ik besef dat ik esthetisch oordeel toeschrijf aan een AI-model — voelt verfijnder. Ik heb dit meerdere keren getest, wisselend tussen modellen voor dezelfde UI-taak, en het patroon houdt stand.
Beide modellen behandelen standaard ontwikkelwerk even goed. Voor de dagelijkse taken — CRUD-endpoints, databasemigraties, unit tests, documentatie, code reviews — kan ik oprecht geen betekenisvol verschil zien. Kies welk model past bij je bestaande workflow.
Hier is mijn huidige setup, voor het geval het helpt: ik gebruik GPT 5.4 via Cursor voor backendwerk en complexe debugsessies. Ik blijf in Claude Code met Opus 4.6 voor frontendontwikkeling, agent-gebaseerde workflows en alles wat baat heeft bij het uitstekende projectcontextbeheer van Claude Code. Wanneer ik begin aan een nieuwe functie die zowel frontend als backend omvat, begin ik doorgaans met GPT 5.4 voor de architectuur en API-laag, en schakel dan over naar Opus 4.6 voor de UI-implementatie.
Is dit optimaal? Waarschijnlijk niet. Ga ik uiteindelijk consolideren naar één model? Misschien. Maar op dit moment zijn de sterktes van elk model anders genoeg dat het gebruik van beide beter werk oplevert dan exclusief kiezen voor één van beide.
Matt Shumer — CEO van HyperWrite en iemand wiens technische beoordelingen ik over het algemeen vertrouw — noemde GPT 5.4 "in wezen foutloos" en zei dat programmeren "opgelost" is. Ik denk dat dat voor ruwweg 70% klopt. Het model is verbazingwekkend capabel. Maar "opgelost" impliceert dat er niets meer te verbeteren valt, en ik kan minstens een dozijn interacties van deze week aanwijzen waar het model subtiel foutieve code produceerde, een beperking verkeerd begreep, of meerdere iteraties nodig had om iets goed te krijgen. Het is het beste beschikbare AI-programmeermodel. Het is niet perfect. De kloof tussen "best beschikbaar" en "foutloos" is nog steeds reëel, en dat doet ertoe wanneer je productiecode uitbrengt.
Aan de slag zonder je eerste twee uur te verspillen
Ik verspilde mijn eerste sessie met GPT 5.4 omdat ik het toolinglandschap niet begreep. Laat me je die tijd besparen.
Stap 1: Kies je interface. Je hebt op dit moment drie primaire opties.
De Codex app is OpenAI's dedicated coding-interface. Ondanks de naam gebruikt de app niet langer een apart "Codex"-model — je selecteert GPT 5.4 uit een dropdownmenu binnen de app. Dit verwardde me aanvankelijk omdat ik bleef zoeken naar een dedicated Codex-modeloptie die niet meer bestaat. De app verbindt direct met je GitHub-repositories, wat betekent dat je je codebase kunt binnenhalen zonder handmatige downloads. Voor projectniveau-werk — architectuurreviews, grote refactors, functieplanning — is de Codex app waarschijnlijk je beste startpunt.
Cursor is waar ik het meeste van mijn GPT 5.4-werk doe. Als je al een Cursor-gebruiker bent, is de integratie naadloos — GPT 5.4 verschijnt als modeloptie in de modelselector. De kracht van Cursor is inline codeerassistentie: je schrijft code, markeert een blok, stelt een vraag en krijgt een antwoord in context. De snelheid en nauwkeurigheid van GPT 5.4 maken deze flow bijzonder soepel. Als je overstapt van VS Code met Copilot, is Cursor met GPT 5.4 een betekenisvolle upgrade.
De API direct is de derde optie, en het is wat ik gebruik voor geautomatiseerde workflows. Ik heb scripts die GPT 5.4 draaien voor code review op pull requests, automatische testgeneratie voor nieuwe bestanden, en documentatie-updates wanneer API's veranderen. De API geeft je volledige controle over contextbeheer, systeemprompts en outputformattering. Het is meer werk om op te zetten, maar de flexibiliteit is ongeëvenaard.
Stap 2: Maak je codebase klaar. Als je code op GitHub staat, kunnen zowel de Codex app als Cursor direct verbinden. Voor Cursor open je gewoon je lokale projectmap. Voor de Codex app verbind je je GitHub-account en selecteer je de repository. Als je geen GitHub gebruikt, download je codebase als ZIP, pak het lokaal uit en open het in Cursor. Ik raad aan om hoe dan ook een schone, up-to-date lokale kopie te hebben.
Stap 3: Begin met high reasoning modus. Spring niet meteen naar ultra-high. High modus behandelt 80% van de programmeertaken efficiënt en je krijgt snellere reacties. Bewaar ultra-high voor wanneer je echt vastzit bij een complex probleem — je weet wanneer je het nodig hebt omdat de suggesties van high modus je werkelijke probleem niet oplossen.
Stap 4: Test met een echte taak, niet een speelgoedvoorbeeld. De slechtste manier om GPT 5.4 te evalueren is het vragen om een todo-app te schrijven of een string om te draaien. Die taken oefenen niet zijn werkelijke sterktes. Neem in plaats daarvan een echte bug die je hebt uitgesteld, of een functie die wijzigingen in meerdere bestanden vereist, of een prestatieprobleem dat je niet hebt onderzocht. Daar verdient GPT 5.4 zijn reputatie.
Protip: Als je migreert van een andere AI-codingtool, probeer dan niet je exacte workflow te repliceren. Het contextvenster van GPT 5.4 is zo veel groter dan waar je aan gewend bent, dat je oude gewoonten — zorgvuldig cureren welke bestanden je opneemt, gedetailleerde samenvattingen schrijven van je architectuur — onnodige overhead zijn. Laat het model alles zien. Laat het uitzoeken wat relevant is. Dit voelt in het begin ongemakkelijk, alsof je het stuur loslaat. Maar het model navigeert beter met de volledige kaart dan jij met een uitgestippelde route.
De eerlijke beperkingen waar niemand over praat
Ik ben enthousiast geweest over GPT 5.4 in dit hele artikel. Bewust, want het model verdient het. Maar ik zou je een slechte dienst bewijzen als ik niet zou bespreken wat nog steeds kapot, beperkt of frustrerend is.
Frontend-designkwaliteit is er nog niet. Ik noemde dit in de Opus-vergelijking, maar het verdient herhaling omdat zoveel mensen all-in gaan op GPT 5.4 voor alles. Als je gebruikersinterfaces bouwt — vooral alles wat er gepolijst uit moet zien, responsief moet aanvoelen en randgevallen in layout elegant moet afhandelen — geeft GPT 5.4 je functionele maar visueel middelmatige resultaten. De CSS die het genereert werkt. De componenten renderen correct. Maar de ontwerpkeuzes zijn veilig, generiek en ongeïnspireerd. Opus 4.6 is hier merkbaar beter, en gespecialiseerde UI-tools zoals Figma-to-code workflows produceren nog steeds superieure visuele resultaten.
Het venster van een miljoen tokens heeft een kostenprobleem. Ik zinspeelde hier eerder op, maar laat me expliciet zijn: 500K+ tokens aan context laden bij elke interactie is duur. Tijdens een bijzonder intensieve debugsessie verbrandde ik naar schatting $15-20 aan API-tegoed over ongeveer drie uur. Dat is prima voor mij — de bug die ik fixte had me zonder het model een hele dag gekost. Maar als je een solo-ontwikkelaar bent die op kosten let, heb je een strategie nodig voor wanneer je volledige context gebruikt en wanneer je selectief bent.
Hallucinaties zijn niet verdwenen. Ze komen minder vaak voor met GPT 5.4 dan bij elk model dat ik eerder heb gebruikt, maar ze gebeuren nog steeds. Afgelopen dinsdag vertelde het model me vol vertrouwen dat Laravel 12 een Model::withoutTimestamps() methode had geïntroduceerd voor bulkoperaties. Dat was niet zo. De methode bestaat niet. De suggestie was plausibel genoeg dat ik vijftien minuten besteedde aan het zoeken ernaar in de documentatie voordat ik besefte dat het model het had verzonnen. Altijd verifiëren. Vertrouw maar verifieer. Het model is slimmer dan elke vorige versie, maar het is nog steeds in staat tot creatieve fictie wanneer het gaten tegenkomt in zijn trainingsdata.
Langlopende taken kunnen afdwalen. In langdurige sessies — denk aan twee uur continu heen-en-weer over een complexe functie — heb ik gemerkt dat het model af en toe beslissingen kwijtraakt die eerder in het gesprek zijn genomen. Het stelt een aanpak voor die tegenspreekt met iets waarover we al hadden vastgesteld dat het fout was. Het venster van een miljoen tokens helpt omdat het technisch de eerdere discussie kan "zien," maar aandacht over zeer lange contexten is niet uniform. Belangrijke beslissingen vroeg in een lange sessie kunnen minder gewicht krijgen dan recente berichten. Mijn workaround: voor kritieke architectuurbeslissingen formuleer ik ze expliciet als beperkingen aan het begin van elke grote fase van het werk. "We hebben besloten X. Dat gaan we niet herzien. Laten we nu aan Y werken."
Nog geen Anti-Gravity-integratie. Als je in het Anthropic-ecosysteem zit en Anti-Gravity gebruikt voor het orkestreren van multi-model workflows, is GPT 5.4 daar nog niet beschikbaar. Dit kan veranderen — het AI-toolinglandschap beweegt snel — maar op dit moment betekent het gebruik van GPT 5.4 dat je buiten de Anthropic-toolchain stapt voor die specifieke taken. Voor mij betekent dit het onderhouden van twee aparte workflows, wat frictie toevoegt.
Ik noem deze beperkingen niet om het model te ondermijnen, maar omdat ik online te veel "GPT 5.4 is perfect, programmeren is opgelost"-takes heb gezien. Het is het beste beschikbare AI-programmeermodel op dit moment. Het is ook een gereedschap met echte beperkingen die je moet begrijpen voordat je je workflow eromheen bouwt.
Wat dit betekent voor de komende zes maanden
Ik bouw al met AI-codingtools sinds de eerste GPT-4 API-preview. Elke paar maanden is er een model dat me dwingt mijn mentale model bij te stellen van wat mogelijk is. GPT 5.4 is zo'n moment.
De combinatie van een contextvenster van een miljoen tokens, computer use-mogelijkheden en oprecht verbeterd redeneren creëert iets dat kwalitatief anders voelt dan wat ervoor kwam. Het is niet zomaar een betere autocomplete. Het komt dichter bij een junior ontwikkelaar die je hele codebase kan lezen, zijn eigen werk kan testen en zijn redenering kan uitleggen wanneer je ernaar vraagt.
Hier is mijn voorspelling, en ik zal er over zes maanden op terugkomen: de volgende golf AI-codingtools zal niet concurreren op alleen modelkwaliteit. GPT 5.4 en Opus 4.6 hebben bewezen dat meerdere organisaties wereldklasse programmeermodellen kunnen produceren. De onderscheidende factor zal tooling zijn — hoe het model integreert in je workflow, hoe het context beheert, hoe het meerstapstaken afhandelt, en hoe het herstelt van fouten. Het model is de motor. De ontwikkelervaring is de auto. Op dit moment hebben we geweldige motoren in middelmatige auto's.
De ontwikkelaars die het meest van GPT 5.4 zullen profiteren, zijn niet degenen die het gebruiken als snellere autocomplete. Het zijn degenen die hun workflows herstructureren om de werkelijke sterktes te benutten: full-codebase redeneren, autonoom testen en diepgaande analyse van complexe problemen. Dat vereist het veranderen van gewoonten. Het vereist het model dingen laten doen die je gewend bent handmatig te doen. Het vereist een niveau van vertrouwen dat tijd kost om op te bouwen — en zou tijd moeten kosten om op te bouwen, want blind vertrouwen in elk gereedschap is een recept voor het uitbrengen van bugs.
Als je op het hek hebt gezeten over AI-codingtools, is GPT 5.4 het model dat je eraf moet duwen. Niet omdat het perfect is. Maar omdat het goed genoeg is dat het niet gebruiken je op meetbaar nadeel zet ten opzichte van ontwikkelaars die dat wel doen.
En die race condition in mijn queue worker? Degene waar ik twee weken handmatig op heb gedebugged? De fix van GPT 5.4 draait al vijf dagen in productie. Nul incidenten. Nul mislukte jobs. De advisory lock-aanpak was schoner dan wat ik zelf zou hebben geschreven, en het kostte het model negentig seconden om een oplossing te vinden die mij veertien dagen had ontgaan.
Ik weet niet zeker of dat me briljant doet voelen omdat ik het juiste gereedschap heb gebruikt, of nederig omdat het gereedschap beter is in mijn werk dan ik. Waarschijnlijk allebei. Zeker allebei.
Laten we samenwerken
Wil je AI-systemen bouwen, workflows automatiseren of je technische 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
