A multi-tenant SaaS platform serving B2B, B2C, and internal operations. The application itself wasn’t the interesting part: running many instances of it without turning every new tenant into another infrastructure project was.

Creating a tenant meant touching a surprisingly long list of things: namespaces, secrets, databases, deployments, storage, monitoring, error tracking, translations, Git configuration, and a handful of other pieces that nobody remembers until something is missing.

So I started turning that whole process into a repeatable, orchestrated workflow. Infrastructure and application configuration became visible and traceable, deployments became easier to follow, and spinning up a new instance became something the platform could handle instead of something an engineer had to remember step by step.

The bigger goal was simple: make a growing platform manageable without needing someone who remembers how it was built.

And, of course, keep it fast. Because apparently “it’s an ERP” is not an acceptable excuse for making people wait.

A live-streaming platform with enough traffic to introduce me to traffic spikes, overloaded servers, configuration mistakes, angry alerts, and the beautiful sound of everyone asking why the site is down.

At the time, everything lived on VMs. Multiple services, manual deployments, manual patching, configuration changes, and rollbacks that were much easier to describe than to actually perform. I was still figuring a lot of it out: tuning servers, understanding PHP-FPM and caching, chasing logs across services, and learning that one bad configuration can have a surprisingly large blast radius.

And yes, the site went down on the first day. :D

Not exactly the launch I would recommend.

But that project probably taught me more than anything else at that stage. Every incident made the next release a little better, every failure made me look a little deeper, and every “we should probably fix this” eventually became something I actually fixed.

If I could go back and do that project again with everything I know now? I’d still do it. Just with a much better rollback plan.

The client cared about latency, and the extra overhead wasn’t meeting the numbers we needed. So I moved the latency-sensitive parts back to VMs while keeping some of the platform on Kubernetes, eventually landing on a hybrid setup that made more sense for the actual workload.

It also taught me that deployment isn’t just about getting the new version out. Deploying during peak hours, breaking something, and then explaining what happened is a remarkably effective way to learn why timing and communication matter.

So I worked on making deployments predictable: knowing what was changing, when it was changing, who needed to know, and making sure we weren’t turning peak traffic into a live debugging session.

Along the way came things like image optimisation, caching, and a growing obsession with shaving unnecessary milliseconds wherever I could.

But the bigger question stayed with me:

What belongs on-premise, what belongs in the cloud, and what should live in both?

Not just from a technology perspective, but from the perspective of latency, infrastructure cost, reliability, and operational overhead.

That’s a question I still find interesting enough that I wouldn’t mind turning the whole thing into a thesis someday.