Zoia Baletska

You know you need to move to the cloud. But you're terrified: What if we lose data? How long will this take? What if it costs more than staying on-premises? Are we picking the right provider?

In recent years, we've migrated 8 production systems to AWS, Azure, and Google Cloud. Here's what we've learned: most cloud migrations succeed. The ones that fail usually fail because of poor planning, not bad execution.

Je weet dat je naar de cloud moet. Maar je ziet ertegenop: wat als we data kwijtraken? Hoe lang gaat dit duren? Wat als het duurder uitpakt dan on-premise blijven? Kiezen we wel de juiste provider?

De afgelopen jaren hebben we 8 productiesystemen gemigreerd naar AWS, Azure en Google Cloud. Wat we daarvan geleerd hebben: de meeste cloudmigraties slagen gewoon. De migraties die misgaan, gaan mis door slechte planning — niet door slechte uitvoering.

If you have already built React applications, Progressive Web Apps are probably less intimidating than they sound.

The term still carries some early-2019 energy. Back then, PWAs were pitched as “websites that behave like native apps” and somehow promised to replace app stores entirely. That prediction aged… unevenly.

Heb je al React-applicaties gebouwd, dan valt een Progressive Web App waarschijnlijk reuze mee.

De term heeft nog altijd iets van 2019 over zich. PWA's werden toen aangeprezen als “websites die zich gedragen als native apps” en zouden en passant de app stores overbodig maken. Die voorspelling is… wisselend oud geworden.

A small SaaS company with around 50 employees approached us with a concern that had begun to surface in budget discussions. Their product was stable, usage was growing steadily, but cloud costs were no longer behaving predictably. Monthly infrastructure spend was roughly €10,000. It wasn’t extreme, but it was drifting upward without a clear explanation. For a company of their size, even a few thousand euros of inefficiency per month was becoming noticeable.

Een klein SaaS-bedrijf van zo'n 50 medewerkers klopte bij ons aan met een zorg die in de budgetbesprekingen was komen bovendrijven. Hun product was stabiel, het gebruik groeide gestaag, maar de cloudkosten gedroegen zich niet langer voorspelbaar. De infrastructuur kostte ongeveer €10.000 per maand. Niet extreem, maar het kroop omhoog zonder duidelijke verklaring. Voor een bedrijf van die omvang wordt zelfs een paar duizend euro verspilling per maand merkbaar.

A lot of SEO advice still sounds like it came from 2014. Endless keyword checklists, “content is king,” and obsessing over density scores nobody cares about anymore. Meanwhile, plenty of technically decent websites still struggle to rank because they ignore the things search engines have quietly become very good at evaluating: structure, clarity, speed, and whether a site feels maintained by people who know what they’re doing.

Veel SEO-advies klinkt nog altijd alsof het uit 2014 komt. Eindeloze keywordlijstjes, “content is king”, en gepieker over dichtheidsscores waar niemand meer naar omkijkt. Ondertussen komen genoeg technisch prima websites niet van hun plek, omdat ze precies datgene negeren waar zoekmachines stilletjes heel goed in zijn geworden: structuur, duidelijkheid, snelheid, en of een site het gevoel geeft dat er mensen achter zitten die weten wat ze doen.

Ask someone where cloud risk lives, and you’ll usually get the same answers: exposed databases, misconfigured storage buckets, maybe a server left open to the internet. Those are the things people screenshot, write postmortems about, and use in security presentations. They’re also not where most of the interesting problems come from.

Vraag iemand waar het risico in de cloud zit, en je krijgt meestal dezelfde antwoorden: blootgestelde databases, verkeerd ingestelde storage buckets, misschien een server die open aan het internet hangt. Dat zijn de dingen waar mensen screenshots van maken, postmortems over schrijven en securitypresentaties mee vullen. Het is alleen niet waar de meeste interessante problemen vandaan komen.

There’s a quiet contradiction in how people talk about AI in software development. On one side, there’s excitement about replacing junior work. Boilerplate, simple features, small bug fixes—things that used to be entry points are now increasingly handled by AI. The argument is that this frees up time, reduces costs, and lets teams move faster. That part is hard to argue with. But it leaves an uncomfortable question hanging in the background: if fewer people start at the junior level, where do senior developers come from later?

Er zit een stille tegenstrijdigheid in hoe we over AI in softwareontwikkeling praten.

Aan de ene kant is er enthousiasme over het vervangen van juniorwerk. Boilerplate, simpele features, kleine bugfixes — precies het werk dat vroeger je instap was, wordt nu steeds vaker door AI gedaan. Dat scheelt tijd, drukt de kosten en laat teams sneller werken, zo gaat het argument. Daar valt weinig tegenin te brengen.

The difference between monitoring and observability only really shows up when something goes wrong, and the usual tools don’t help you understand why. That’s when the gap becomes obvious.

Het verschil tussen monitoring en observability merk je pas echt wanneer er iets misgaat en je gebruikelijke tools je niet helpen begrijpen waarom. Dan pas wordt het gat zichtbaar.

Every new wave of tooling in software development comes with the same split reaction. Some people see leverage. Others see risk.

Claude Mythos sits right in that space. It’s not just another coding assistant. It can read large codebases, identify vulnerabilities, and in some cases go a step further—figuring out how those weaknesses could actually be exploited.

That combination is what makes it interesting, and also what makes it uncomfortable to reason about.

Elke nieuwe golf tooling in softwareontwikkeling roept dezelfde tweedeling op. De een ziet hefboomwerking. De ander ziet risico.

Claude Mythos zit precies op die grens. Het is niet zomaar weer een coding assistant. Het leest omvangrijke codebases, vindt kwetsbaarheden, en gaat soms nog een stap verder — door uit te zoeken hoe die zwakke plekken daadwerkelijk misbruikt zouden kunnen worden.

Most teams build their systems expecting small failures.

A container crashes. A node disappears. Maybe an availability zone has had issues for a while. These are the scenarios architecture diagrams usually prepare you for, and most platforms handle them well enough that you barely notice.

De meeste teams bouwen hun systemen op kleine storingen.

Een container crasht. Een node verdwijnt. Misschien heeft een availability zone een tijdje last. Dat zijn de scenario's waar architectuurplaten je op voorbereiden, en de meeste platformen vangen ze goed genoeg op dat je het nauwelijks merkt.

Cloud security is often framed as a shared responsibility. In practice, that usually translates to something like: “the platform handles most of it.” That assumption is where problems start.

Modern cloud providers do a good job securing infrastructure — physical hardware, networking layers, and managed services. But the moment you start building on top of that, responsibility shifts quickly. Misconfigurations, overly broad permissions, and implicit trust between services remain among the most common causes of incidents.

Cloudsecurity wordt vaak gepresenteerd als een gedeelde verantwoordelijkheid. In de praktijk vertaalt zich dat meestal naar iets als: “het platform regelt het grootste deel wel”. Precies bij die aanname beginnen de problemen.

Moderne cloudproviders doen hun werk goed als het om infrastructuur gaat — fysieke hardware, netwerklagen en managed services. Maar zodra jij daarbovenop begint te bouwen, verschuift de verantwoordelijkheid razendsnel.

If you’ve been working with React for a while, your stack is probably already in a good place. You’re not looking for yet another state library or a new way to style buttons. Most of the common problems are already solved, and the ecosystem has settled around a handful of reliable defaults.

What tends to change at this stage is not what you use, but where the friction shows up. It’s no longer about getting things to work. It’s about reducing the amount of coordination between layers, avoiding performance work that feels repetitive, and keeping systems understandable as they grow.

Werk je al een tijd met React, dan zit je stack waarschijnlijk prima in elkaar. Je zoekt niet nog een state-library of weer een nieuwe manier om knoppen te stylen. De meeste gangbare problemen zijn opgelost, en het ecosysteem heeft zich gesetteld rond een handvol betrouwbare keuzes.

Cloud platforms have become incredibly fast. You can spin up infrastructure in minutes, scale on demand, and deploy globally without much effort. And yet, getting a simple code change into production can still take far longer than expected.

Cloudplatformen zijn razendsnel geworden. Je zet in minuten infrastructuur neer, schaalt op aanvraag en rolt wereldwijd uit zonder al te veel moeite. En toch duurt het vaak veel langer dan verwacht om een simpele codewijziging in productie te krijgen.

Cloud migration often starts with confidence. The plan sounds simple: move existing systems to the cloud, reduce infrastructure overhead, gain scalability, and modernise the stack. In presentations and strategy documents, the path usually looks straightforward.

Reality tends to look different.

Een cloudmigratie begint meestal vol vertrouwen. Het plan klinkt simpel: bestaande systemen naar de cloud, minder gedoe met infrastructuur, beter kunnen schalen en de stack moderniseren. In presentaties en strategiestukken oogt het pad meestal kaarsrecht.

De werkelijkheid ziet er doorgaans anders uit.

Bug fixing has changed.

Not because bugs are different. They’re still null references, race conditions, broken assumptions, and unexpected edge cases. The difference is that now, when something breaks, you’re no longer alone with the stack trace.

Bugs fixen is veranderd.

Niet omdat bugs anders zijn. Het zijn nog steeds null references, race conditions, aannames die niet kloppen en randgevallen die je niet zag aankomen. Het verschil is dat je nu, als er iets breekt, niet langer alleen bent met die stack trace.

There’s a familiar pattern among developers who have spent any time with AI-assisted tools: initial curiosity, followed by a period of regular use, and then — surprisingly — weariness. Many engineers report a sense of exhaustion, irritation, or even dread at the idea of interacting with AI daily. For teams that expected AI to save time and reduce toil, this is a disorienting experience.

It’s not that the tools are inherently bad. It’s that interacting with AI changes how developers think, work, and maintain focus — and those changes can be draining in subtle ways that traditional productivity metrics don’t capture.

Er zit een herkenbaar patroon in developers die een tijdje met AI-tools werken: eerst nieuwsgierigheid, dan een periode van dagelijks gebruik, en vervolgens — verrassend genoeg — vermoeidheid. Veel engineers melden uitputting, irritatie of zelfs lichte weerzin bij het idee dagelijks met AI te moeten werken. Voor teams die verwachtten dat AI tijd zou besparen, is dat een verwarrende ervaring.

In distributed engineering teams, merge conflicts are a recurring headache. They slow down development, frustrate engineers, and introduce subtle bugs that sometimes go unnoticed until deployment. While traditional local development environments work well for small teams, scaling to remote or multi-location teams demands a more robust approach. Enter remote cloud sandboxes—isolated, cloud-based environments that can transform collaboration and reduce friction in distributed software development.

In verspreide engineeringteams zijn merge conflicts een terugkerende hoofdpijn. Ze vertragen de ontwikkeling, frustreren engineers en introduceren subtiele bugs die soms pas bij de deploy opvallen. Voor kleine teams werken klassieke lokale ontwikkelomgevingen prima, maar zodra je opschaalt naar remote of over meerdere locaties, is er iets steviger nodig.

If you’ve ever felt like your CI/CD pipeline is working against you rather than for you, you’re not alone. The promise of continuous integration and continuous delivery was supposed to be freedom: faster feedback, automated testing, reliable deployments, and more time for coding. In reality, for many teams, CI/CD has become a second full-time job.

Heb je weleens het gevoel dat je CI/CD-pipeline eerder tégen je werkt dan vóór je? Je bent niet de enige. De belofte van continuous integration en continuous delivery was vrijheid: snellere feedback, geautomatiseerd testen, betrouwbare deployments en meer tijd om te coderen. In de praktijk is CI/CD voor veel teams een tweede fulltime baan geworden.

Moving to the cloud is deceptively easy.

You create an account, spin up a few services, deploy your first workload, and everything works. At least at first. The problems usually don’t appear when you’re experimenting — they show up when the platform starts to grow, when more people touch it, and when real business data and compliance requirements enter the picture.

This is the point where many teams realise they’ve been “using the cloud,” but not really operating in it. That’s where the idea of a Cloud Landing Zone becomes critical.

Naar de cloud gaan is bedrieglijk eenvoudig.

Je maakt een account aan, zet een paar services op, rolt je eerste workload uit, en alles werkt. In het begin dan. De problemen duiken meestal niet op terwijl je aan het experimenteren bent — ze komen zodra het platform groeit, zodra meer mensen eraan zitten, en zodra echte bedrijfsdata en compliance-eisen in beeld komen.

As frontend developers, we tend to talk in binaries: X killed Y, this is the future, that’s dead. The past years' rise of React Router Framework mode (v7+), born from the Remix merge, triggered exactly that kind of debate — especially when developers started claiming it felt cleaner and faster than Next.js for real-world SPAs.

Als frontend-developers praten we graag in absolute termen: X heeft Y om zeep geholpen, dit is de toekomst, dat is dood. De opkomst van React Router Framework mode (v7+) — voortgekomen uit de samenvoeging met Remix — leverde precies dat soort discussie op, zeker toen developers begonnen te roepen dat het schoner en sneller voelde dan Next.js voor echte SPA's.

In modern software development, security cannot be an afterthought. Vulnerabilities discovered post-release can cost companies millions and damage reputations. A Secure SDLC integrates security practices into each phase of the development lifecycle, ensuring your software is robust, compliant, and resilient from the very start.

In moderne softwareontwikkeling kan security geen bijzaak meer zijn. Kwetsbaarheden die je na de release ontdekt, kosten bedrijven miljoenen en beschadigen hun reputatie. Een Secure SDLC verweeft securitypraktijken in elke fase van je ontwikkelproces, zodat je software vanaf het begin robuust, compliant en veerkrachtig is.

January is when many teams open their cloud invoice, blink twice, and wonder what exactly happened in December.

Holiday traffic spikes, paused projects, temporary experiments, and “we’ll clean this up later” resources all tend to collide at the end of the year. The result? A cloud bill that feels higher than expected — and harder to explain.

The good news: January is the perfect time to regain control. With a structured review, you can quickly identify waste, lock in savings, and set better cost discipline for the year ahead.

Januari is de maand waarin veel teams hun cloudfactuur openen, twee keer knipperen en zich afvragen wat er in december precies gebeurd is.

Feestdagenverkeer, stilgelegde projecten, tijdelijke experimenten en resources uit de categorie “dat ruimen we later wel op” komen aan het eind van het jaar allemaal samen.

Every January, developers across the world make the same promises: “I’ll finally learn Rust.” “I’ll rewrite everything properly.” “I’ll never ship messy code again.”

And by February… reality wins.

The problem isn’t motivation — it’s that most resolutions are too big, too vague, or disconnected from day-to-day work. Good developer resolutions should fit naturally into your existing workflow and make your job easier, not harder.

Here are 10 realistic, practical New Year’s resolutions that developers actually stick to — because they improve daily work instead of fighting it.

Elke januari doen developers over de hele wereld dezelfde beloftes: “Dit jaar leer ik eindelijk Rust.” “Ik ga alles netjes herschrijven.” “Ik lever nooit meer rommelige code op.”

En in februari… wint de werkelijkheid.

Het probleem is niet je motivatie — het is dat de meeste voornemens te groot en te vaag zijn, of losstaan van je dagelijks werk.

By 2025, cloud computing had transformed beyond mere hosting: it became the foundation of AI, hybrid infrastructure, edge-to-cloud pipelines, and sustainable, high-scale digital operations. For many teams and businesses, “cloud” now means more than VMs and storage — it’s a full ecosystem for computing power, data, real-time processing, compliance, and innovation.

In this article, we look at the defining characteristics of cloud in 2025, why it evolved this way, and what that evolution meant for companies (like those we help at ZEN) building or migrating to the cloud.

In 2025 was cloud computing veel meer geworden dan hosting: het werd het fundament onder AI, hybride infrastructuur, edge-to-cloud-pijplijnen en duurzame digitale operaties op grote schaal. Voor veel teams en bedrijven betekent “cloud” inmiddels meer dan VM's en opslag.

Cloud adoption today isn’t optional — it’s a competitive accelerant. But here’s the truth: many teams quietly discover the hard way that the cloud only pays off if you use it well. Misconfigurations, runaway costs, slow delivery pipelines, and architectural bottlenecks often reveal that a team needs help… not more cloud credits.

If you feel like your cloud setup isn’t quite “working for you,” here are the five unmistakable signs it’s time to bring in cloud experts who can turn your infrastructure from reactive to resilient.

De cloud is tegenwoordig geen keuze meer — het is een versneller. Maar de waarheid is: veel teams ontdekken op de harde manier dat de cloud zich alleen terugbetaalt als je hem goed gebruikt. Verkeerde instellingen, ontspoorde kosten, trage pipelines en architectonische flessenhalzen wijzen er meestal op dat een team hulp nodig heeft… en niet meer cloudtegoed.

LLMs and “AI-assisted coding” are rapidly reshaping how we develop software. Auto-complete, boilerplate generation, refactoring — many teams already rely on these tools daily. But does that mean we can trust LLMs to handle complex, real-world tasks the way experienced engineers do?

LLM's en “AI-ondersteund programmeren” veranderen in hoog tempo hoe we software maken. Autocomplete, boilerplate genereren, refactoren — veel teams leunen er dagelijks op. Maar betekent dat ook dat we LLM's complexe taken uit de echte wereld kunnen toevertrouwen, zoals ervaren engineers dat doen?

The cloud is no longer just infrastructure — it’s a core capability for modern engineering teams. Whether you’re a software developer, DevOps engineer, data specialist, or tech lead, strengthening your Google Cloud skills has become a strategic investment. But with dozens of services and rapid innovation cycles, it’s easy to feel overwhelmed. This guide breaks down the most effective, real-world ways to build and accelerate your Google Cloud expertise — without wasting time on scattered tutorials or outdated content.

De cloud is allang geen infrastructuur meer alleen — het is een kernvaardigheid voor moderne engineeringteams. Of je nu softwareontwikkelaar, DevOps-engineer, dataspecialist of tech lead bent: je Google Cloud-kennis versterken is een strategische investering geworden. Maar met tientallen diensten en snelle vernieuwing raak je het overzicht zo kwijt.

At ZEN, we keep a close eye on emerging research that affects how engineering teams build, ship, and maintain software. Recently, we came across a new study — “The Impact of Large Language Models (LLMs) on Code Review Process” — that analyses more than 25,000 GitHub pull requests to understand how GPT-style models influence code review speed and collaboration. The findings are both promising and highly relevant for modern engineering teams working in cloud-native, agile, or distributed environments. Below is our breakdown of the study — and what we think teams can take away from it.

Bij ZEN houden we onderzoek in de gaten dat raakt aan hoe engineeringteams software bouwen, opleveren en onderhouden. Onlangs stuitten we op een nieuwe studie — “The Impact of Large Language Models (LLMs) on Code Review Process” — waarin meer dan 25.000 GitHub pull requests zijn geanalyseerd om te zien hoe GPT-achtige modellen de snelheid en samenwerking bij code reviews beïnvloeden.

On November 18 2025, Cloudflare, a major content-delivery and internet-infrastructure provider handling roughly 1 in 5 web requests globally, experienced a large-scale network failure. The result: dozens of high-profile services such as ChatGPT, X (formerly Twitter), and other applications were rendered partially or fully unavailable for hours. In this article, we cover the lessons we’ve distilled from the incident, and talk through how you can apply them when designing or revisiting your cloud architecture.

Op 18 november 2025 kreeg Cloudflare — een grote leverancier van content delivery en internetinfrastructuur die ruwweg 1 op de 5 webverzoeken wereldwijd afhandelt — te maken met een omvangrijke netwerkstoring. Het gevolg: tientallen bekende diensten zoals ChatGPT en X waren urenlang geheel of gedeeltelijk onbereikbaar.

When companies move to the cloud, they often assume that the provider — whether AWS, Azure, or Google Cloud — takes care of all the security. After all, it’s their data centre, their servers, and their infrastructure.

But the reality is more nuanced. Cloud security operates on a shared responsibility model — meaning that while cloud providers secure the underlying infrastructure, you (the customer) are still responsible for securing what you put in it.

Als bedrijven naar de cloud verhuizen, gaan ze er vaak van uit dat de provider — AWS, Azure of Google Cloud — de security wel regelt. Het is tenslotte hun datacenter, hun servers, hun infrastructuur.

De werkelijkheid ligt genuanceerder. Cloudsecurity draait om een model van gedeelde verantwoordelijkheid.

Security best practices often tell us to “rotate secrets regularly,” but when your application is running in production, that’s easier said than done. API keys, database passwords, and tokens are often baked into live systems—and rotating them can feel like defusing a bomb. The good news? With modern DevOps and cloud tooling, you can implement seamless secrets rotation without causing downtime.

Goede securitypraktijk zegt: “roteer je secrets regelmatig”. Maar draait je applicatie in productie, dan is dat makkelijker gezegd dan gedaan. API-keys, databasewachtwoorden en tokens zitten vaak diep in levende systemen — en ze vervangen voelt als een bom demonteren.

The way we work has changed dramatically. Remote and hybrid models have shifted software development and IT operations from centralised offices to globally distributed teams. While this brings flexibility and broader talent pools, it also introduces new challenges for disaster recovery (DR). Traditional DR strategies assumed co-located teams, centralised data, and on-premises infrastructure. Today, companies need strategies that support remote-first operations, ensure business continuity, and protect critical data across multiple locations and cloud environments.

De manier waarop we werken is ingrijpend veranderd. Remote en hybride modellen hebben softwareontwikkeling en IT-beheer verplaatst van centrale kantoren naar teams over de hele wereld. Dat levert flexibiliteit en een grotere vijver aan talent op, maar het brengt ook nieuwe uitdagingen mee voor disaster recovery.

Code reviews are supposed to make us better developers — not frustrated ones. Yet, in many teams, they end up feeling like gatekeeping or nitpicking sessions rather than opportunities to grow. The difference between a painful and productive review usually comes down to culture and process, not just tooling. Let’s look at what makes code reviews actually teach — not torture.

Code reviews horen ons betere developers te maken — niet gefrustreerde. Toch voelen ze in veel teams eerder als een poortwachter of een muggenzifterij dan als een kans om te groeien. Het verschil tussen een pijnlijke en een productieve review zit meestal in je cultuur en je proces, niet in je tooling.

For over a decade, the global cloud market has been dominated by US hyperscalers — AWS, Microsoft Azure, and Google Cloud. These giants defined what “the cloud” means for most organisations: scalable infrastructure, global reach, and near-limitless services. Yet in recent years, a counter-movement has emerged in Europe, where concerns about digital sovereignty, data protection, and geopolitical independence are reshaping how cloud is perceived and consumed.

Ruim tien jaar lang werd de wereldwijde cloudmarkt gedomineerd door Amerikaanse hyperscalers — AWS, Microsoft Azure en Google Cloud. Deze reuzen bepaalden wat “de cloud” voor de meeste organisaties betekent: schaalbare infrastructuur, wereldwijd bereik en een schier eindeloos aanbod aan diensten.

Frontend hosting has evolved dramatically in the past decade. We’ve gone from uploading static HTML files to FTP servers to deploying full-stack applications at the edge with just a single command. With frameworks like Next.js, Remix, Gatsby, and Vite pushing the boundaries of what a “frontend” even means, hosting providers are racing to keep up.

So, what does the future of frontend hosting look like in 2025 and beyond? Let’s explore the key trends, opportunities, and trade-offs.

Frontend hosting is het afgelopen decennium ingrijpend veranderd. We zijn gegaan van statische HTML-bestanden naar een FTP-server slepen, naar full-stack applicaties aan de edge uitrollen met één commando. Met frameworks als Next.js, Remix, Gatsby en Vite die oprekken wat een “frontend” eigenlijk is, rennen hostingpartijen zich uit de naad om bij te blijven.

This article breaks down best practices for cloud backup and disaster recovery in a remote-first world — with a practical focus on what actually works, tools you can use, and the trade-offs to consider.

Dit artikel zet op een rij hoe je cloud back-up en disaster recovery aanpakt in een remote-first wereld — met de nadruk op wat er werkelijk werkt, welke tools je kunt inzetten en welke afwegingen erbij komen kijken.

Modern applications often combine a React-based frontend (built with Vite, Next.js, Remix, etc.) and a backend API (Node.js, Python, Java, etc.). In production, the cleanest architecture is usually to deploy frontend and backend as separate services.

But sometimes you want the simplicity of hosting them together in one container.

Moderne applicaties combineren vaak een React-frontend (gebouwd met Vite, Next.js, Remix) en een backend-API (Node.js, Python, Java). In productie is het meestal het schoonst om frontend en backend als aparte diensten uit te rollen.

Maar soms wil je gewoon het gemak van allebei in één container.

Think moving to the cloud makes your business sustainable? Not always. Discover the hidden CO2 costs of cloud computing and simple optimisation strategies to cut emissions and save money.

Denk je dat naar de cloud gaan je bedrijf duurzaam maakt? Niet altijd. Ontdek de verborgen CO2-kosten van cloud computing en de eenvoudige optimalisaties waarmee je zowel uitstoot als kosten terugdringt.

Google Analytics 4 (GA4) reporting has received some criticism and feedback from users since its release. Despite GA4 offering an array of reporting tools, users may face confusion regarding the location of certain reports or the type of data in the interface. In this article, we delve into common reporting queries and where to locate them in GA4.

Backstage is an open platform for building developer portals – locations where companies can engage in technical outreach and education. These portals enable the provision of software documentation, example code, tools, and knowledge bases to enhance communication and functional collaboration. From a developer's perspective, a developer portal simplifies API management.

Feature flags, also known as feature toggles or feature switches, are a powerful tool in software development that allows developers to enable or disable specific features or functionalities in an application. In the dynamic landscape of front-end development, the integration of feature flags has emerged as an indispensable strategy, unlocking a realm of possibilities for developers seeking agility, flexibility, and enhanced control over their projects.

In this article, we explore the key differences between Agile Analytics and Traditional Analytics to help organisations make informed decisions about their analytical strategies.

Ever wondered how fast your code goes from "I got an idea" to "Boom, it's live"? That's where Lead Time for Changes comes in – it's like your code's speedometer. Wanna know if your code changes are speedy like The Flash or just taking a stroll? In coding, finding the perfect rhythm is the key!

Have you ever wondered why some software applications perform better than others? The answer is simple: they have well-defined Service Level Objectives (SLOs).

As the saying goes, "You can't manage what you can't measure." This is especially true in software development, where the success of a project hinges on the performance of the development team. But fear not! Machine learning is here to help.

Creating a search feature on your website can significantly improve the user experience. A well-designed search bar can be a powerful tool for increasing engagement and conversion. In this article, we will focus on adding an easily implemented and fast search feature to your website with the help of Google's Custom Search API.

Having a good SEO is critical for your website. An increasingly important part of that means having good meta tags for pages and articles on your site. We have an extremely scalable setup at ZEN Software using a headless CMS, Cloud Platform and a world-class content delivery network. Adding good SEO to a CaaS setup in 5 easy steps!