

Official logo of Basque Country's public health care service: Osak

256_cta-background.webp

384_cta-background.webp

640_cta-background.webp

750_cta-background.webp

828_cta-background.webp

thumbnail_cta-background.webp

osakidetza-logo

Daar hebben wij de oplossing voor

Wilt u efficiënter werken? 



Atmosphere of azure electric sky, with water, slope,

1080_background.webp

1200_background.webp

256_background.webp

384_background.webp

640_background.webp

750_background.webp

828_background.webp

thumbnail_background.webp

atmosphere-water-sky-azure-electricity-astronomical-object-slope-electric-blue

1080_zen-logo-white.webp

1200_zen-logo-white.webp

256_zen-logo-white.webp

384_zen-logo-white.webp

640_zen-logo-white.webp

750_zen-logo-white.webp

828_zen-logo-white.webp

thumbnail_zen-logo-white.webp

zen-logo-white.webp

ZEN Software

1080_zen-logo-black.webp

1200_zen-logo-black.webp

256_zen-logo-black.webp

384_zen-logo-black.webp

640_zen-logo-black.webp

750_zen-logo-black.webp

828_zen-logo-black.webp

thumbnail_zen-logo-black.webp

západoslovenská energetika-logo

Agile Analytics

Websites & Apps Development

Tech Consultancy

ZEN DevOps Accelerator

Content and Commerce at any scale

ZEN Cloud Landing Zone

What We Do

About us

News

Contact

Success! You`ve been added to our email list.

Subscribe to our email list and we will keep you updated on DevOps and ZEN Software News and Trends

Subscribe to ZEN Software's  newsletter

1080_Zen-software-kantoor-9.webp

1200_Zen-software-kantoor-9.webp

1920_Zen-software-kantoor-9.webp

2048_Zen-software-kantoor-9.webp

256_Zen-software-kantoor-9.webp

384_Zen-software-kantoor-9.webp

3840_Zen-software-kantoor-9.webp

640_Zen-software-kantoor-9.webp

750_Zen-software-kantoor-9.webp

828_Zen-software-kantoor-9.webp

thumbnail_Zen-software-kantoor-9.webp

Zen-software-kantoor-9.webp

New Software Project / Modernisation

1080_Frame 30 (3).webp

1200_Frame 30 (3).webp

256_Frame 30 (3).webp

384_Frame 30 (3).webp

640_Frame 30 (3).webp

750_Frame 30 (3).webp

828_Frame 30 (3).webp

thumbnail_Frame 30 (3).webp

Frame 30 (3).webp

- Need a working solution fast? We deliver software that is ready to use.

- Everything included: from functional documentation through to team training.

- Built Agile, with the freedom to change course every sprint.

Turn-Key Software Development

Software, Development



A computer and peripheral setup on a desk with the "WHER LLC

256_computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

384_computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

thumbnail_computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

computer-personal-computer-furniture-peripheral-computer-keyboard-computer-monitor-table-computer-desk

- Keep software and infrastructure current, secure and ready for what comes next.

- Clear out accumulated legacy and put a robust architecture in its place.

- Secure DevOps integration with security built in from the start.

Application Management & Renewal

Application, Management

1080_Frame 30 (2).webp

1200_Frame 30 (2).webp

256_Frame 30 (2).webp

384_Frame 30 (2).webp

640_Frame 30 (2).webp

750_Frame 30 (2).webp

828_Frame 30 (2).webp

thumbnail_Frame 30 (2).webp

Frame 30 (2).webp

- **OnlyCloud:** speed and scalability for your content platform or e-commerce environment.

- **Secure Cloud:** secure-by-design landing zones on AWS and GCP.

- **European Cloud:** fully EU-hosted and compliant with GDPR, NIS2 and DORA.

Cloud & Data Security

Cloud, Security

1080_Frame 31 (1).webp

1200_Frame 31 (1).webp

256_Frame 31 (1).webp

384_Frame 31 (1).webp

640_Frame 31 (1).webp

750_Frame 31 (1).webp

828_Frame 31 (1).webp

thumbnail_Frame 31 (1).webp

Frame 31 (1).webp

- Your invisible AI colleague, clearing technical debt before it turns into a problem.

- Automatic logging and test coverage, for lower maintenance costs.

The Software Mechanic (AI maintenance)

Software, Mechanic

Building a PWA in 2026: What a Regular React Developer Actually Needs to Learn

ChatGPT Image May 28, 2026, 01_51_40 PM.webp

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.

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.
     
But PWAs quietly became useful.
     
For internal business tools, customer portals, ecommerce experiences, booking flows, field-service apps, dashboards, and products where “installability” matters more than App Store prestige, they’re often a practical middle ground between a website and a mobile app.
    
The good news: if you’re already comfortable with React, Next.js, Vite, or modern frontend tooling, you’re probably closer than you think.
     
The bad news: there are a few concepts web developers tend to underestimate.

First: A PWA Is Not Just “Add a Manifest”

Many tutorials make PWA development look suspiciously simple.
     
Add a ```manifest.json```. Register a service worker. Show install prompt. Done.
     
Technically, yes.
     
But the difficult part is thinking through offline behaviour, caching, updates, and user expectations.
     
Users forgive websites for reloading. They do not forgive apps for behaving unpredictably. That changes the standard a bit.
     
If your installed app randomly shows stale data, breaks after deploys, or refuses to update because of an aggressive cache, people stop treating it like a website and start treating it like broken software.
      
Which, to be fair, it is.


1. You Need to Understand Service Workers (Even If You Hate Them)

This is the biggest mental shift.
       
Service workers are effectively a network layer that sits between your app and the browser. They decide what gets cached, when requests are intercepted, and what should happen when the internet disappears.
       
You don’t need to become a browser internals expert, but you do need to understand:
      
- Cache-first vs network-first strategies
     
- Asset caching vs API caching
     
- Offline fallbacks
     
- Update lifecycle issues
      
- Background sync basics
     
The annoying part is that service workers can fail in very confusing ways.
     
You deploy a fix. Users still see the old version. You clear the cache. Still broken. You question reality for a while.
      
Eventually, you discover the service worker politely serving stale assets because it thinks it’s helping.
     
This is a rite of passage.

- ```Workbox```
      
- ```vite-plugin-pwa```
     
- ```next-pwa``` (if you’re still on Next.js and need a shortcut)
      
You can absolutely write service workers manually. Most teams eventually decide life is too short.

Regular web apps can get away with sloppy assumptions, like “reload fixes things”. PWAs remove that safety net.
      
Once installability enters the picture, the caching strategy matters much more than people expect. Static assets, API responses, images, and fonts — each behaves differently. The temptation is to cache everything aggressively because performance feels amazing. Then your users keep seeing outdated product data for three hours.
      
Or worse: the app breaks after deployment because cached assets no longer match the new build.
     
There’s a balancing act here:  fast enough to feel app-like, fresh enough to remain trustworthy.
      
That sounds simple until real users show up.

- Browser DevTools Application tab
      
- Chrome Lighthouse PWA audits
     
- Cache Storage debugging
     
You will spend time staring at cached requests, wondering why reality no longer matches production. This is normal.

3. Offline UX Matters More Than Offline Capability

A lot of developers obsess over “offline mode,” but very few think about what happens when offline actually occurs. Most apps do not need full offline support; they need graceful failure. There’s a difference.
        
Sometimes users just need:
       
- Previously loaded content
     
- Draft saving
      
- Retry mechanisms
     
- Clear status indicators
     
The worst experience is pretending everything still works until users discover it doesn’t. A small “You’re offline — changes will sync later” message often does more for usability than complicated sync logic. The more app-like the experience becomes, the more predictable it has to feel.

4. Push Notifications Sound Cool Until You Build Them

Every developer eventually thinks: “We should add push notifications.” Then reality arrives.
     
Browser support varies. Permissions are fragile. UX can get annoying fast. Users decline prompts aggressively if timing feels wrong.
     
And if the notification strategy turns into random marketing spam, congratulations — you reinvented the reason people disable notifications.
     
Still, for some products, they’re genuinely valuable:
     
- Task reminders
      
- Status updates
     
- Operational alerts
      
- Workflow approvals

- Web Push API
      
- Firebase Cloud Messaging (FCM)
      
- Notification permission strategies
       
The technical side is manageable. The product thinking matters more.

5. You Need to Think About Updates Differently

This one catches React developers off guard. On the web, deploys are easy. Ship code, refresh page, everyone gets updates. PWAs behave differently because cached versions stick around. That means you need a strategy:
     
- Should updates happen silently?
      
- Should users see an “Update available” toast?
     
- Should critical fixes force a refresh?
      
Bad update handling creates bizarre bugs where users unknowingly run different versions of the app.

Support conversations become strange:
     
*“Can you reproduce this?”
“No.”
“Are you on the latest version?”
“Yes.”*

They are not.

- Service worker lifecycle management
     
- Background updates
    
- Update prompting patterns
     
This sounds boring until it ruins a release.

PWAs raise expectations. Users compare them less to websites and more to apps. That means slow startup, janky transitions and heavy bundles feel worse. Fortunately, modern React tooling already helps.
     
If you’re comfortable with Vite, code splitting, lazy loading, image optimisation, and performance profiling, you already have a head start. Still, it’s worth paying more attention to:
     
- Initial bundle size
      
- Route-based loading
       
- Memory usage on mobile
     
- Rendering performance on lower-end devices
     
You may not notice it on your MacBook, but older Android devices tend to reveal uncomfortable truths.

If you’re already a React developer, the learning curve is smaller than people think. You do not need to become a mobile engineer overnight. But you should get comfortable with:
      
**Core concepts**
      
- Service workers
     
- Caching strategies
     
- Installability
     
- Offline UX
     
- Update handling
      
**Useful tools**
      
- Workbox
      
- vite-plugin-pwa
      
- Lighthouse
      
- Chrome DevTools (Application tab)
      
- Firebase Cloud Messaging
      
And maybe most importantly: start treating the browser less like a document renderer and more like an application runtime. That mindset shift is usually the real transition. The React part you probably already know. The weirdness mostly starts once caching decides it knows better than you.

5 Things to Consider When Building a Website That Actually Ranks Well

arri3p.webp

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.

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.
       
Good rankings usually come from a combination of strong technical foundations and content that doesn’t feel manufactured purely for search engines. The number of websites that still publish lifeless, over-optimised pages suggests otherwise.

1. Your Website Structure Matters More Than Most SEO Plugins

Search engines are surprisingly good at understanding relationships between pages, but they still rely heavily on structure. If your navigation is chaotic, URLs are inconsistent, and related topics are scattered randomly across the site, you make indexing harder than it needs to be.
       
A clean structure also changes how people behave once they land on the site. If visitors can naturally move deeper into related content, engagement improves without needing artificial tricks. That matters more than squeezing another keyword variation into a heading.
       
A useful rule: if a human struggles to understand how your site is organised, search engines probably won’t love it either.

Modern frontend stacks sometimes feel designed to impress developers more than users. Giant bundles, unnecessary animations, hydration everywhere, third-party scripts multiplying like bacteria. Then everyone acts surprised when the page takes six seconds to become interactive.
      
Performance affects rankings, but the bigger issue is behavioural. People leave slow sites. They don’t explore. They don’t convert. Search engines notice that over time.
       
This becomes especially painful on content-heavy websites where every article loads an entire JavaScript ecosystem just to display text and two images.
      
You do not need a small operating system running in the browser to render a blog post.

3. Generic AI Content Is Already Becoming Background Noise

There’s a growing layer of internet content that technically answers questions while saying almost nothing memorable. You can recognise it instantly because every article sounds interchangeable. Same rhythm. Same phrasing. Same conclusions.
      
Search engines are getting better at distinguishing useful expertise from polished filler. Even when generic AI-written pages rank temporarily, they tend to have weak long-term engagement because people don’t actually trust or remember them.
       
That doesn’t mean you shouldn’t use AI tools. Most teams already do. But editing matters. Perspective matters. Real experience matters. Websites that still sound like humans built them have started standing out again simply because so much content now feels synthetic.

A surprising number of websites publish good content and then basically orphan it.
      
Internal linking is not glamorous, which is probably why people ignore it. But it remains one of the easiest ways to help both users and search engines understand relationships between topics across your site.
       
Good internal linking also extends the lifespan of older content. Instead of treating blog posts like disposable social media updates, you turn them into connected pieces of a larger knowledge base.
      
Most websites don’t have a content problem. They have a discoverability problem inside their own domain.

5. Search Engines Prefer Websites That Look Alive

One thing that rarely gets discussed openly: stale websites gradually lose trust.
      
Not because Google has a secret “inactive company” penalty, but because neglected sites develop patterns associated with low quality. Outdated information, broken links, abandoned blogs, inconsistent publishing, old screenshots, expired copyright dates. Individually, these things seem minor. Together, they create the impression that nobody is paying attention anymore.
      
Websites that rank well over long periods tend to feel maintained. Content evolves. Technical issues get fixed. New pages connect to old ones. The site behaves like an active product rather than a static brochure that was launched three years ago and forgotten.
      
That consistency matters more than most growth hacks people chase.

The frustrating reality of SEO is that there’s rarely a magic fix. Rankings are often the side effect of doing a lot of foundational things reasonably well for a long time.
      
Clear structure. Fast pages. Useful content. Strong topical connections. A website that feels actively maintained.
      
Not particularly exciting advice. Still more effective than most “10x SEO strategies” floating around LinkedIn right now.

5 Tools Experienced React Developers Should Try in 2026

i-have-finally-become-a-senior-v0-atsdhmg8by811 (1).webp

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.

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.
       
The tools worth exploring now tend to focus on those edges. They don’t replace React, but they reshape the parts around it that still feel heavier than they should.

Routing often starts simple and gradually turns into something harder to reason about. Once data fetching, loading states, and error handling enter the picture, the router becomes more than just a mapping between paths and components.
     
TanStack Router leans into that complexity instead of hiding it. Routes are treated as structured units that can define their own data requirements, loading states, and boundaries. The result feels closer to how backend routing works, where a route describes not just where you go, but what needs to happen before you get there.
     
One thing that stands out is how naturally it integrates with data fetching. Instead of scattering logic across hooks and components, data can be tied directly to routes, which makes transitions easier to reason about. Type safety also plays a bigger role here, especially in larger applications where navigation and data dependencies tend to drift apart over time.
     
It’s not necessarily a drop-in replacement for every project, but in applications where routing logic has become tangled, it offers a cleaner mental model.

[TanStack Router](https://www.npmjs.com/package/@tanstack/react-router)

The boundary between frontend and backend has always been a source of duplication. Types get redefined, API contracts drift, and even well-structured systems require some level of synchronisation across layers.
      
tRPC takes a more direct approach by removing that boundary altogether. Instead of defining endpoints and then consuming them, you call backend procedures as if they were local functions, with full type inference across the entire stack.
      
What makes this approach compelling is not just the reduction in boilerplate, but the way it changes development flow. You no longer think in terms of “API shape first, then client integration.” The two evolve together. For teams already working in TypeScript across the stack, this can simplify a surprising amount of everyday work.
      
There are trade-offs, especially in systems that need strict separation between services or public APIs. But in internal tools, dashboards, and full-stack apps owned by a single team, it can remove a layer that often feels heavier than it needs to be.
     
[tRPC](https://www.npmjs.com/package/@trpc/react-query)

Tooling tends to accumulate quietly. ESLint, Prettier, plugins, configs, overrides — it all works, but it rarely feels simple. Keeping everything aligned across projects can take more effort than expected, especially when rules conflict or performance starts to lag in larger codebases.
      
Biome takes a different approach by collapsing several responsibilities into a single tool. Linting and formatting live in one place, with a focus on speed and minimal configuration. The experience is noticeably faster, particularly in larger repositories where traditional setups can slow down both editors and CI pipelines.
      
What makes it worth exploring isn’t just consolidation, but consistency. With fewer moving parts, there’s less room for drift between projects or environments. Teams don’t have to spend as much time maintaining tooling, which tends to become more valuable as the codebase grows.
      
Adopting it doesn’t require a full rewrite of your setup either. It can be introduced gradually, replacing parts of an existing toolchain without forcing a complete switch on day one.
      
It’s a small shift on the surface, but it addresses a category of friction that most teams simply get used to — and rarely question.
      
[Biome](https://www.npmjs.com/package/@biomejs/biome)

why‑did‑you‑render (and other rendering analysis tools)

Most React applications never hit serious rendering limits, but when they do, the usual advice starts to feel repetitive: memoise more, virtualise lists, avoid unnecessary state updates. These techniques work, but they don’t fundamentally change how rendering behaves — and it’s easy to waste time optimising the wrong things.
      
Why-did-you-render takes a different angle. Instead of introducing a new rendering layer or bypassing React’s reconciliation, it helps you **detect when components render unnecessarily**. It hooks into React (via a dev‑only setup) and logs detailed information about hooks, props, and state changes that cause re‑renders. That makes it incredibly useful for identifying actual performance problems instead of guessing where they might be.
     
What makes it valuable isn’t that it magically speeds up rendering, but that it helps you focus your optimisation efforts where they truly matter — reducing wasted work instead of blindly applying memoisation or abstraction patterns.
      
It works with plain React components, doesn’t require a custom reconciler or compiler, and can be dropped into existing codebases with minimal configuration. For teams struggling to understand render behaviour in large trees, the insights it provides can yield performance improvements far greater than micro-optimisations.
      
It’s not something you ship to production — it’s a diagnostic tool — but by making unnecessary work visible, it gives you a new handle on performance without changing how React fundamentally works.
      
[why-did-you-render](https://www.npmjs.com/package/@welldone-software/why-did-you-render)


As projects grow, the challenges tend to move away from individual components and toward the structure of the codebase itself. Multiple applications, shared libraries, and internal tooling start to interact in ways that are difficult to manage without some form of organisation.
      
Nx addresses this by making relationships between parts of the system explicit. Instead of treating the repository as a flat collection of projects, it understands dependencies and uses that information to optimise builds, tests, and development workflows.
      
One of the more practical benefits is how it reduces unnecessary work. When only a small part of the system changes, only the affected pieces need to be rebuilt or tested. In larger codebases, that can make a noticeable difference in both local development and CI/CD pipelines.
       
There’s also a structural aspect to it. Nx encourages a way of organising code that makes boundaries clearer, which tends to pay off as teams grow and projects evolve.
       
[Nx](https://www.npmjs.com/package/nx)

 



None of these tools is essential in the way that a framework or a build tool might be. You can build and ship applications without them. The reason they’re worth exploring is that they address areas where experienced developers tend to feel friction after the basics are already in place.
      
They reflect a broader shift in the ecosystem. Instead of adding more layers, there’s a growing effort to remove unnecessary ones, or at least make them less visible. Routing becomes part of the data flow. APIs feel closer to function calls. Performance optimisation moves into the compiler. Build systems become aware of what actually changed.
      
Individually, each tool solves a specific problem. Together, they point toward a way of working where less time is spent managing the glue between parts of the system, and more time goes into the parts that actually matter.
      
That shift tends to have a bigger impact than any single library choice.

New Software Project / Modernisation

Turn-KeySoftwareDevelopment

ApplicationManagement&Renewal

Cloud&DataSecurity

TheSoftwareMechanic(AImaintenance)

Related News & Articles

Building a PWA in 2026: What a Regular React Developer Actually Needs to Learn

5 Things to Consider When Building a Website That Actually Ranks Well

5 Tools Experienced React Developers Should Try in 2026