Case study · 2026 Q1
Five sites on one WordPress install, more than two million visits a month. They crashed every time the national team played, and the previous agency had spent months treating it as a hosting problem. I took over the work, found what was actually causing it, and migrated the network to Kinsta.
Before: Down on every Denmark match, and the owner had no direct access to his own servers.
The stakes
Every time Denmark played, the sites went down. Visitors waited five or six seconds for a page to load, the writers couldn't publish, and the traffic went to other outlets at the moment it mattered most. This happened during every game of the Men's EHF EURO 2026. The previous agency had been treating it as a hosting problem for months.
The insight
The crashes weren't the servers. They were in the code.
Three things in the theme were wiping the entire page cache every five minutes. One was the "most popular news" widget, which regenerated on a timer and cleared the whole cache each time it ran. So almost nothing stayed cached, and the server built most pages from scratch on every visit. On a normal day that was just slow. On a match day, with about two thousand people arriving at once, it ran out of capacity and went down. A bigger server would only have delayed the next crash.
What I did
I moved the codebase off the agency's servers and into the client's own GitHub, so they owned it from then on. I changed how the caching worked so pages could actually stay cached, took out the plugins and extra code that were loading the server for no reason, and added a missing database index. Then I migrated the network to Kinsta, scheduled for a low-traffic window ahead of the tournament's closing weekend, with the editors kept in the loop and nothing lost.
The result
The match-day crashes stopped, and the sites stayed up for the rest of the championship. In the first ten days they served 4.3 million requests, at an average response time around 0.13 seconds and no thread saturation. During matches, single articles were read 16,000 to 35,000 times. The client also came out of it owning both the code and the hosting, and could close the contract with the previous agency.
Most problems like this are in the code, not the hardware. The real work is finding where, and fixing it without breaking what's around it.
Dealing with something similar? Let's talk it through.
Book a callCase study · 2026 Q1
Five sites on one WordPress install, more than two million visits a month. They crashed every time the national team played, and the previous agency had spent months treating it as a hosting problem. I took over the work, found what was actually causing it, and migrated the network to Kinsta.
Before: Down on every Denmark match, and the owner had no direct access to his own servers.
The stakes
Every time Denmark played, the sites went down. Visitors waited five or six seconds for a page to load, the writers couldn't publish, and the traffic went to other outlets at the moment it mattered most. This happened during every game of the Men's EHF EURO 2026. The previous agency had been treating it as a hosting problem for months.
The insight
The crashes weren't the servers. They were in the code.
Three things in the theme were wiping the entire page cache every five minutes. One was the "most popular news" widget, which regenerated on a timer and cleared the whole cache each time it ran. So almost nothing stayed cached, and the server built most pages from scratch on every visit. On a normal day that was just slow. On a match day, with about two thousand people arriving at once, it ran out of capacity and went down. A bigger server would only have delayed the next crash.
What I did
I moved the codebase off the agency's servers and into the client's own GitHub, so they owned it from then on. I changed how the caching worked so pages could actually stay cached, took out the plugins and extra code that were loading the server for no reason, and added a missing database index. Then I migrated the network to Kinsta, scheduled for a low-traffic window ahead of the tournament's closing weekend, with the editors kept in the loop and nothing lost.
The result
The match-day crashes stopped, and the sites stayed up for the rest of the championship. In the first ten days they served 4.3 million requests, at an average response time around 0.13 seconds and no thread saturation. During matches, single articles were read 16,000 to 35,000 times. The client also came out of it owning both the code and the hosting, and could close the contract with the previous agency.
Most problems like this are in the code, not the hardware. The real work is finding where, and fixing it without breaking what's around it.
Dealing with something similar? Let's talk it through.
Book a callWhat stands out about Nerijus is that he's not only excellent technically; he's a T-shaped developer with a breadth of marketing knowledge who can converse with marketing leadership about decisions that will impact revenue.
There are many developers out there, but very few that are as trustworthy and on top of things as Nerijus. Our agency continues to turn to him for help, and he always delivers. On top of his sharp skill set, he is an absolute pleasure to work with.
Working with Nerijus as an agency has made our process and workflow unbelievable. He is incredibly talented developer but what really makes him stand out is his work ethic and steady approach. I highly recommend Nerijus.
Happy to talk through whatever you're working on, whether you're building something or stuck on something. Book a time below.
Book a Time