--- title: "Introductie" date: 2026-04-17T23:18:00.000Z updated: 2026-04-28T18:36:03.356Z canonical: https://ninokroesen.nl/blog/introductie lang: nl author: "Nino Kroesen" --- # Introductie Dit is de eerste post op ninokroesen.com en ninokroesen.nl, en het is de enige plek op de site waar ik de zaak uitleg in plaats van hem gewoon te doen. Volgende posts duiken meteen in het probleem zelf — een productiesysteem dat zich misdraagt, een onderzoeksrun die met iets interessants terugkwam, of een onafhankelijk project dat een eerlijk verslag verdient. Deze post is de index: wie er schrijft, waar ik daadwerkelijk aan werk, en wat de blog gaat behandelen zodra de inhoudelijke posts beginnen te landen. De invalshoek is operator-developer. Ik bouw software, ik houd de infrastructuur eromheen draaiende, daarnaast doe ik langerlopend onderzoek, en ik ship kleine onafhankelijke experimenten van mezelf. Die hybride positie is de reden dat de posts hier anders lezen dan pure engineering-blogs of pure foundercontent. De tradeoffs in elke post komen voort uit het feit dat ik meer dan één van die dingen tegelijk moet doen, niet uit een focus op slechts één ervan. Eerlijk gezegd is de andere reden dat deze site bestaat dat het schrijven van posts als deze het meest nuttige reflectie-instrument is dat ik voor mijn eigen werk heb gevonden. Het schrijven van deze introductie heeft me al gedwongen om opnieuw te graven in wat er op elk van deze projecten daadwerkelijk heeft gewerkt, wat niet, en waar ik me als volgende op zou moeten richten — het soort eerlijke evaluatie dat makkelijk over te slaan is als je met je neus diep in het volgende ding op de stapel zit. Daar is deze blog deels voor. Veel van de posts die nog komen lezen meer als hardop nadenken op papier dan als een afgeronde mening, en dat is bewust en niet per ongeluk. ## Wie dit schrijft ![1.00](https://media.ninokroesen.com/uploads/2026/04/fa90829a078eac47b7ba/_1280.jpeg) Ik ben Nino Kroesen. Ik woon in de Achterhoek, Nederlands is mijn moedertaal, en ik schrijf in beide talen. Posts op deze site worden eerst in het Engels geschreven en daarna naar het Nederlands vertaald, zodat de `.com`- en `.nl`-versies van de site synchroon blijven in plaats van twee gescheiden redactionele stromen te draaien. Mijn rol in mijn hoofdbaan is Lead Developer bij WorkWear4All B.V., een landelijk Nederlands werkkledingbedrijf dat een multi-store Magento 2 stack draait over meerdere Europese markten. Het systematische tradingwerk op deze blog staat los van die hoofdbaan — persoonlijk onderzoek dat ik in mijn eigen tijd doe, buiten WorkWear4All om, en de posts erover worden vanuit die hoek geschreven. Ik werk voornamelijk op een MacBook Air, en voor de dagelijkse ontwikkeling op elk hieronder genoemd project leun ik zwaar op agentic coding tools. Ik probeer wisselend uit wat er op dat moment beschikbaar is in plaats van me aan één tool vast te leggen, en ik kijk actief uit naar nieuwe tools die de workflow daadwerkelijk verbeteren in plaats van in de weg zitten. Voor alles wat rekenintensief is — en een flink deel van het AI-onderzoek plus een flink stuk van het tradingwerk valt in die categorie — is de laptop het verkeerde gereedschap, dus huur ik rekenkracht in de cloud in plaats van te proberen de zware runs lokaal te draaien. Mijn leveranciers op dit moment zijn Netcup voor algemeen VPS- en serverwerk, Runpod voor on-demand GPU-huur als een AI-experiment een kaart nodig heeft die groter is dan wat er in mijn eigen machine zit, en Google Colab voor Jupyter notebooks die een rekenintensieve kernel nodig hebben zonder dat ik er een hele omgeving omheen wil opzetten. Die splitsing — lokaal voor ontwikkeling, cloud voor de rekenintensieve runs — is hoe de opstelling eruitziet, en hij gaat de posts kleuren waar rekenkracht zelf de bottleneck is. ## Waar ik op dit moment aan werk Een paar dingen parallel. Ik lijst ze hier op zodat latere posts kunnen terugverwijzen naar "de stack van het tradingonderzoek" of "het Magento-cluster van WorkWear4All" zonder elk project elke keer opnieuw te hoeven introduceren. ### WorkWear4All WorkWear4All is een multi-store Magento 2 e-commercebedrijf — meerdere storefronts (workwear4all.nl, workwear4all.be, workwear4all.de, workwear4all.com, workwear4all.pl en nog een aantal meer gespecialiseerde sub-stores) die één backend delen, draaiend op Apache + Varnish + PHP-FPM + Redis. De keuze voor Apache is een vroege beslissing die door een externe developer is gemaakt voordat ik in beeld kwam, en achteraf is het er een waar ik spijt van heb — we lopen tegen genoeg wrijving op de performance aan dat een migratie naar Nginx al op de roadmap staat. Ik ben lead developer op het platform, en ik coach ook de juniors en stagiairs aan de engineeringkant. De interessante delen, vanuit schrijfperspectief, zijn de operationele. De `_cl` changelogtabellen die in de achtergrond stilletjes opzwellen totdat er iets in de indexeringspipeline kapotgaat. De indexer cron groups waarvan het gedocumenteerde gedrag en het echte gedrag op subtiele manieren verschillen. De meerlandige `MAGE_RUN_CODE` plus locale plus Varnish VCL-coördinatie die over al deze storefronts heen correct moet blijven zonder dat er iemand op een willekeurige dag bewust over nadenkt. Breder gezien past het Magento-ecosysteem niet goed bij moderne webontwikkeling, en dat kleurt een hoop van de operationele inhoud op deze blog. De problemen waar we tegenaan lopen zijn vaak het soort dat lastig te diagnosticeren is zonder in aangrenzende componenten van de stack te duiken om ze uit te sluiten, en één ding fixen betekent vaak begrijpen wat de drie andere dingen aan het doen waren die allemaal dachten dat zij verantwoordelijk waren voor hetzelfde gedrag. De posts die uit dit deel van het werk voortkomen, komen vanuit deze stoel — niet uit het lezen van de documentatie, maar uit tegen de randen ervan aanlopen in productie. Als een module de moeite van het installeren waard is, zal ik dat zeggen en waarom; als hij dat niet is, zeg ik dat ook. ### Hourly Hourly is een gratis menubalk-tijdregistratie voor macOS die ik in SwiftUI aan het bouwen ben. De projectpagina staat op `/hourly`, met ondersteuning op `/hourly/support`. De bewuste positionering is: geen paywall, geen in-app purchases, geen abonnement, geen account, geen cloud — opslag is lokaal op je Mac en blijft daar. De marktreferenties zijn WorkingHours, Toggl, en Timery, en al die drie zitten op de Mac App Store achter een of andere vorm van paywall. Het punt waarop Hourly afwijkt is dat hij geen verdienmodel heeft dat je uiteindelijk om je creditcard vraagt. De minder voor de hand liggende reden dat Hourly bestaat, is dat ik hem als experiment gebruik. Generatieve AI heeft het oprecht triviaal gemaakt om het soort functieset te shippen waar een kleine SaaS vroeger een maandelijks abonnement voor vroeg, en ik wil — empirisch — uitvinden hoeveel van een bedreiging dat daadwerkelijk is voor de SaaS-aanbieders die op dit moment een categorie als deze in handen hebben. Dus ik lanceer Hourly zo minimaal als maar kan: geen marketingbudget, geen groeiteam, geen retentiemachinerie, alleen een gratis app die het werk goed doet en een schone projectpagina op deze site. Wat ik daadwerkelijk meet, is of een fatsoenlijke gratis tool, gebouwd in een fractie van de tijd die het twee jaar geleden zou hebben gekost, een merkbaar effect kan hebben op installaties en aandacht in een categorie waarin elke gevestigde speler geld vraagt. Wat er over Hourly in schrijfwerk uitkomt, gaat over het experiment zelf — de productbeslissingen achter het gratis en lokaal blijven, wat ik bewust niet heb gebouwd en waarom, en de adoptiecijfers zodra die er zijn en de moeite waard zijn om over te praten. ### Systematisch tradingonderzoek Naast mijn hoofdbaan draai ik systematisch tradingonderzoek als persoonlijk project in mijn eigen tijd. De huidige iteratie is een systematische forex-strategie die via een Node.js broker bridge met MetaTrader 5 praat. Hij zit in paper-tradingvalidatie, niet in live capital. Er zit zinnige paper-trading-risicobeheersing in — een circuit breaker die gekalibreerd is tegen de backtested drawdown zodat live volatiliteit een hard plafond heeft voordat de strategie zichzelf op pauze zet voor evaluatie. Verder houd ik de inhoud over dit systeem zwaar geredigeerd: geen gepubliceerde performance-cijfers, geen parameterwaarden, geen specifieke instrumentlijsten, niks waarmee een lezer de strategie kan reverse-engineeren uit wat ik op deze blog schrijf. Dat is een bewuste redactionele regel, geen bescheidenheid. De grootste uitdaging op dit project is niet het tradingdeel — het is het onderzoeksdeel. De pipeline is rekenintensief, en een betekenisvolle dataset genereren op één enkele strategievariant duurt ongeveer een week voordat hij terugkomt. Dat is een lange feedback loop vergeleken met elk ander softwarewerk dat ik doe, waar ik gewend ben iets te veranderen en het effect in seconden of hooguit minuten te zien. Een week tussen hypothese en resultaat zitten is de moeilijkste aanpassing van het hele project geweest, en het bepaalt mede welke experimenten ik überhaupt bereid ben te draaien — dure runs krijgen minder pogingen, en er is een serieuze discipline nodig om niet halverwege een run dingen te blijven bijstellen terwijl de data nog binnenkomt. Wat er uit dit deel van het werk in schrijfwerk komt, is engineering-eerst: het ontwerp van de onderzoeksharness, de broker-integratie, en het statistische denkwerk dat het echte werk doet om een echt voordeel te onderscheiden van een geluks-backtest. Ik schrijf geen "ik heb $X verdiend vorige maand"-posts, ik publiceer geen live P\&L, ik verkoop geen signalen, en ik geef geen financieel advies. ### AI-agent-experimenten Ik besteed ook tijd aan routed-model agentic systems, met gemengde gevoelens over de resultaten tot nu toe. De architectuur waar ik op aan het itereren ben, gebruikt een klein redeneermodel (Nanbeige4-3B) als orchestrator die afhankelijk van de taakcomplexiteit doorschakelt naar grotere modellen — DeepSeek V3.2 voor zwaarder redeneerwerk, een lokale R1-32B voor werklasten die ik privé wil houden, en Claude Sonnet voor Nederlandstalige klanttekst. De eerlijke conclusie is dat ik mezelf tijdens het bouwen van het framework keer op keer betrapte op het curve-fitten van de scaffolding om een specifiek antwoord te produceren in plaats van het hardere werk te doen om het systeem daadwerkelijk door de taak heen te laten redeneren. Dat is geen prettige plek om te landen. Daarnaast was de operationele wrijving reëel — ``-block-bloat die context windows opvreet op lange sessies, routinglatency op de kleine orchestrator als die in het hot path zat, en de fragiele context-engineering die nodig was om de stack coherent te houden over een taak met meerdere stappen. En de kosten hielpen ook geen van beide kanten van de opstelling. Voor gevoelige werklasten viel ik terug op commerciële LLM-API's die per miljoen tokens werden afgerekend en direct werden betaald; voor middelgrote self-hosted modellen probeerde ik te huren op Runpod en de rekening liep sneller op dan de onderzoeksopbrengst rechtvaardigde. Geen van beide uiteinden van het spectrum was houdbaar, en het project staat als gevolg daarvan op het tweede plan. Ik denk nog steeds dat dit ecosysteem uiteindelijk naar kleine modellen toe moet. De rekenkosten van de huidige frontier-LLM's zijn geen houdbare basis om software op te bouwen, en de recente verbeteringen in de capaciteit van kleine modellen zijn genoeg geweest dat ik van plan ben het project te herstarten. Als ik dat doe, verschuift de focus: minder "een model dat op eigen houtje redeneert," meer "goede tools bouwen die een LLM kan gebruiken." Dat is een ander probleem dan orchestratie — het zit dichter bij traditionele software engineering met een LLM als één van de aanroepers — en uit wat ik tot nu toe gezien heb, is het een veel productiever kader dan proberen een routed stack zelfstandig een lange taak te laten dragen. Wat er uit dit project in schrijfwerk komt, gaat precies over die verschuiving — wat ik probeerde, wat niet werkte, en waar de tweede poging op gebouwd is. ## Waar ik hier over ga schrijven Drie inhoudelijke pijlers. Alles op deze site wordt eerst in het Engels geschreven en daarna naar het Nederlands vertaald, dus elke post die op `.com` landt krijgt een gekoppelde Nederlandse versie op `.nl`. Er is geen aparte Nederlandstalige redactionele stroom en geen onderwerp dat op één van de twee domeinen leeft en op het andere niet. De pijlers gaan niet over specifieke projecten, want projecten komen en gaan op een site als deze. Ze beschrijven de drie werkmodi die daadwerkelijk inhoud opleveren die het opschrijven waard is. De eerste pijler is **het onderhouden en uitbouwen van productiesystemen**. De vorm van mijn hoofdbaan: een draaiend platform met echte gebruikers, echte data, en een lange lijst operationele randgevallen die pas opduiken zodra het systeem een tijdje in gebruik is. Posts in deze pijler gaan over de realiteit op infrastructuurniveau van zoiets in leven houden en laten doorgroeien — achtergrondmigraties, index- en cache-valkuilen, performance-schuld die je hebt geërfd van eerdere beslissingen, evaluaties van extensies of dependencies met eerlijke tradeoffs, en de architectuurkeuzes die je vandaag anders zou maken als je vanaf nul zou beginnen. Op dit moment wordt deze pijler voornamelijk gevoed door de Magento-stack bij WorkWear4All, maar het kader is algemener; elk draaiend systeem met echte gebruikers is geldig terrein. De tweede pijler is **ideeën onderzoeken met data-science-methoden**. Trager werk, langere feedback loops, meer geduld. Het tradingonderzoek is het huidige voorbeeld, maar de pijler dekt elk project waarin de loop is: een hypothese vormen, een harness bouwen om hem te testen, het experiment draaien, en de output eerlijk interpreteren. Posts hier gaan over de engineering van onderzoek — hoe je een harness bouwt die niet stilletjes tegen je liegt, hoe je nadenkt over steekproefgroottes en statistische significantie, hoe je experimenten ontwerpt als één enkele run dagen nodig heeft om terug te komen, en hoe je een signaal van een fit onderscheidt. Geen rijk-worden-verhalen. Geen signalen verkopen. Waar het onderliggende werk commercieel gevoelig is, worden de posts zwaar geredigeerd op alles waarmee een lezer een specifieke strategie kan reverse-engineeren. De derde pijler is **het shippen en evalueren van onafhankelijke software-experimenten**. Kleine producten gelanceerd op een bewuste hypothese, met eerlijke verslagen van wat er is gebeurd — inclusief de producten die niets zijn geworden. Op dit moment wordt deze pijler gevoed door Hourly (zelf opgezet als experiment op wat generatieve AI doet met een paywalled SaaS-categorie), een geplande post-mortem op de webshop die ik heb gelanceerd en heb stopgezet, en waar de herstart van de AI-agent ook in uitmondt. De rode draad: ship het ding, meet het resultaat, schrijf het zonder opsmuk op, en ga door. Geen lanceerdag-hype op iets wat in werkelijkheid nog niet is gebruikt. Bewust buiten scope voor deze site: algemene AI- en LLM-opiniestukken, persoonlijk financieel advies voor niet-ondernemers, consumentenproductreviews, politieke commentaren, en meta-posts over bloggen zelf. Dat is een bewuste scope-keuze, zodat de site niet wegzakt in wat er op enig moment populair is. Als een onderwerp hier staat, dan is dat omdat ik het doe, niet omdat ik er een mening over heb. ## Hoe je dit kunt volgen ![1.00](https://media.ninokroesen.com/uploads/2026/04/d0c43653888860d81d12/_1280.jpeg) De site draait op twee domeinen: ninokroesen.com voor Engels, ninokroesen.nl voor Nederlands — dezelfde auteur, dezelfde backend, gekoppeld via hreflang. Posts worden in het Engels geschreven en naar het Nederlands vertaald, dus de twee domeinen blijven synchroon; wat op het ene domein verschijnt, heeft een tegenhanger op het andere. Mijn code staat op github.com/vultwo, dat is waar een deel van de tooling en libraries waar ik in posts naar verwijs gepubliceerd worden. RSS-autodiscovery zit in de layout ingebouwd, dus elke moderne reader pikt de feed op zonder extra werk aan jouw kant. Ik voeg later misschien ook een opt-in e-mailnieuwsbrief toe voor lezers die liever e-mail dan RSS hebben; als ik dat doe, wordt hij laagfrequent, en er komt geen modal omhoog die om je adres vraagt voordat je überhaupt iets gelezen hebt. Als één van de hierboven beschreven dingen overlapt met iets dat jij aan het bouwen bent, of als er een interessant project of vraag is waar het de moeite waard is om over te sparren, dan staan mijn contactgegevens op de about-pagina. Ik lees wat er binnenkomt. ```widget type: newsletter variant: inline ```