Fourteen years, one server at a time
Most infrastructure work never makes it into a portfolio. It's a firewall rule at 2 a.m., a backup that restores cleanly because someone tested it in advance, a migration nobody notices because nothing broke. That's most of what this journey is made of — not a single big launch, but fourteen years of the unglamorous work that keeps other people's businesses online.
I didn't start with a five-year plan to run a managed infrastructure company. I started by administering shared hosting and VPS environments for small businesses that needed someone to keep their sites up, and kept saying yes to the next environment, the next stack, the next country's timezone. There was no single moment where "sysadmin doing hourly work" turned into "company operating infrastructure for agencies on three continents." It happened the way most real capability does — one environment that had to survive, then another, then a pattern emerging from environments that had nothing in common except that someone was depending on them staying up.
What follows is the honest version of how that turned into MatrixKloud — not a highlight reel, but the actual sequence: what broke, what scaled, what had to change before it could, and what a decade and a half of doing this for other people's businesses actually teaches you about the job. Most of it happened before AI-assisted tooling existed to help write a playbook or generate a script — the debugging, the runbooks, the migrations at 200-plus servers deep, all of it done by hand, the way the whole industry did it until very recently.
The Growth99 years: where "at scale" stopped being a slide
I hold a master's degree in mathematics, not computer science — which meant the systems side of this work was self-taught, built from the same instinct for structure and pattern that the degree trained in the first place. That background is where the infrastructure years started: in 2016, as a Linux System Administrator for Growth99, a Salt Lake City-based agency serving medical aesthetics and dental practices, invoiced project by project even as the role settled into an ongoing one. Over the eight years that followed I managed the server layer behind more than 1,000 medical spa and dental websites: WHM and cPanel account provisioning, AWS EC2 and Lightsail instances, DNS, SSL, malware response, and the daily maintenance that a portfolio that size generates whether or not anyone's watching.
"At scale" is easy to say and hard to live inside. When you're running one WordPress site, a plugin update is a five-minute task. When you're running past a thousand, across hundreds of individually provisioned WHM accounts, the same task is a queue — and the queue never empties, because a fifth of the portfolio needs updating again by the time you've cleared the first fifth. I spent years inside that queue: firewall rules, DNS cutovers to Cloudflare, SPF and DMARC records, malware sweeps across shared servers, site migrations that had to finish inside a maintenance window, and enough small day-to-day fires that the real skill stopped being "can you fix this" and became "how do you stop fixing the same thing twice."
That's the part that doesn't show up in a case study: the shift from reactive firefighting to systems that don't need you standing over them. Scripts that collected server information faster than a human checking dashboards. Runbooks other team members could follow without escalating to me first. A malware-detection pipeline instead of a manual scan. None of it was glamorous. All of it was the actual work of operating infrastructure at a scale where manual effort stops being a strategy.
Retiring WHM: the platform migration that mattered most
By the time I left, the stack looked nothing like where it started. WHM and cPanel — the platform that carried the first several years of that portfolio — had been retired in favor of GridPane running on UpCloud, with OpenLiteSpeed handling the web layer and Cloudflare managing DNS. Ansible tied server configuration together so that "consistent" didn't depend on someone remembering the steps. By the end, that operation covered more than 200 servers.
The reason that migration mattered isn't the tooling itself — GridPane and OpenLiteSpeed aren't magic, they're just a better fit for running WordPress at real scale than raw WHM ever was. The reason it mattered is what it taught me about infrastructure decisions in general: the platform that gets you from zero to a hundred sites is rarely the platform that should still be running you at a thousand. Recognizing that gap — and having the operational discipline to migrate a live, revenue-generating portfolio without an outage — is a different skill than knowing how to configure a server in the first place. It's the skill this whole business is now built around.
Running more than one system at once
Two years into the Growth99 role, in December 2018, I took on a second ongoing engagement: Ryan Ho Limited, a Hong Kong-based digital agency, needed the same discipline applied to a completely different portfolio. For years afterward I was running both operations at once — not a transition from one job to the next, but two production infrastructures, on two continents, in overlapping timezones, held to the same standard simultaneously. If there's a single fact that best explains how the rest of this happened, it's that: the habits that let you run one portfolio well are the same habits that let you run two, then a hundred short engagements alongside them, without any of them slipping.
Leaving a defined-term role for fully independent work is still a different kind of risk than adding a second client — there's no ramp-up period, no existing team to lean on, and a new client doesn't care how many WordPress sites you've kept alive elsewhere, only whether their own environment is going to be fine tomorrow. But by the time that step happened, the pattern was already proven: document everything, automate what repeats, treat every environment like it might need to survive a handover to someone else. That discipline is what turned parallel engagements into something that could eventually call itself a company, rather than staying a string of unrelated jobs.
The long tail: a hundred small engagements
Not every relationship becomes a five-year retainer, and it would be dishonest to write this as if it did. Alongside Growth99 and RH Office, most of the rest of the work over those years ran through freelance platforms as one-off engagements — a migration here, a security incident there, a server that needed rescuing before a launch date that wasn't moving. More than a hundred discrete engagements, spanning health-tech, insurance, professional services, real estate, and general small-business hosting, most of them a few days to a few weeks long, most of them for a client I never spoke to again after the invoice cleared.
That long tail matters more than it looks like it should. A five-year retainer teaches you one environment deeply. A hundred short engagements teach you what's actually common across environments — which WordPress misconfigurations show up regardless of industry, which DNS mistakes get made the same way by unrelated teams, which "quick fix" requests are actually a symptom of a deeper architecture problem the client hasn't named yet. It's the same reason a doctor who's only ever treated one patient, however well, knows less than one who's seen a thousand different presentations of the same handful of underlying problems. The short jobs are where the pattern recognition gets built. The long relationships are where it gets applied properly, with the time to do it right instead of just patching the symptom before the invoice is due.
Most of those hundred-plus engagements never turn into a long relationship. A few did, and those few are where the rest of this story lives.
Hong Kong: operating an agency's infrastructure as if it were one system
RH Office, a Hong Kong-based digital agency, is that second engagement from December 2018 — still running today. Their client base spans hospitality, food and beverage, real estate, and professional services across Hong Kong and the wider APAC region, and by the nature of agency work, that meant inheriting infrastructure built by whoever came before: inconsistent hosting choices, DNS spread across providers, WordPress environments in varying states of neglect.
The job wasn't to rebuild everything at once — it was to bring more than a hundred client domains under one standardized operating model without disrupting live client sites in the process. That meant consolidating hosting onto AWS Lightsail and EasyEngine, unifying DNS management, and building the kind of maintenance rhythm where a plugin vulnerability gets patched across the whole portfolio in hours, not discovered site by site after something breaks. Today that operation covers more than 107 client domains with a measured 80% drop in ongoing maintenance overhead compared to how it ran before — the clearest evidence I have that a standardized operating model beats a talented person doing everything manually, every time.
Switzerland: from a WordPress brochure site to a patient-management platform
Gojadental, a dental practice in Switzerland, is a different kind of story — not scale, but transformation. Their original web presence was a self-hosted WordPress marketing site running on an AWS server with OpenLiteSpeed and Docker: functional, but a brochure, nothing more. The practice needed something closer to actual software — a real patient-management system with separate portals for staff and patients, not another marketing refresh.
That meant rebuilding the platform category, not just the site: a Next.js and TypeScript application with distinct Admin and Patient portals, deployed on Vercel, backed by Supabase for a proper Postgres database instead of a WordPress content model stretched past its purpose, SendGrid for transactional email, and S3 for document storage. It's the clearest example in this whole journey of a client outgrowing the platform they started on — and of why "modernization" sometimes means a full rebuild rather than an upgrade.
Besarta Kabashi — operating as KABATEX — is a related but separate relationship: a Swiss real-estate and interior-design client group running five connected properties. IMMOKABA handles real-estate listings on Next.js and Vercel. Interior Elements is a Vite and React storefront for interior design work. VitalInvest covers real-estate investment. ArtKab is a delivered Vercel property with its own Microsoft 365 mail setup. Grolimund is an in-progress WordPress modernization. Running five related properties for one client family means the job extends past hosting into the kind of operational admin — mail licensing, cross-property consistency, coordinated releases — that a single-site engagement never requires.
The habits that scale, and the ones that don't
Somewhere in the middle of the Growth99 years, I learned the difference between a habit that scales and one that just feels productive. Answering every alert personally feels productive right up until the portfolio doubles and you're the bottleneck on every incident. Writing a runbook so someone else can answer that same alert feels like overhead right up until it's 3 a.m. in your timezone and it isn't your problem anymore because it didn't need to be.
A few of those habits carried forward into every engagement since, regardless of the client's size or industry. Infrastructure as code, so an environment can be rebuilt from a specification instead of from memory of what was clicked in a control panel two years ago. Monitoring and alerting from day one of an engagement, not bolted on after the first outage — because the fastest way to lose a client's trust is for them to find out about downtime before you do. Recovery rehearsed before it's needed, not improvised during an incident, because the first time you test a backup should never be the first time you need it. And documentation written for a stranger, not for future-me, because the whole point of operating someone else's infrastructure well is that it should survive you being unreachable for a week.
None of that is unique or clever. It's the same operational discipline every serious infrastructure practice eventually converges on, because the alternative — heroics, tribal knowledge, one person who has to be online for anything to get fixed — doesn't survive contact with real scale. What's specific to this journey is where those habits got tested: across WHM servers holding a thousand medical spa sites, across a Hong Kong agency's inherited patchwork of client hosting, across a Swiss dental practice's jump from brochure site to real software, across a transportation platform where the infrastructure and the growth engine had to work as one system. Different industries, different stacks, same underlying question every time — what happens to this client's business the day I'm not available, and have I actually made that day a non-event.
Limo Network: infrastructure, application, and growth in one stack
Limo Network is a USA-based transportation technology business, and the most complete picture of what a modern MatrixKloud engagement looks like end to end. It isn't one website — it's a booking and dispatch platform spanning a marketing site, a React-based booking application, and a Laravel dispatch system with its own operator dashboard, running across more than 44 limo and taxi service domains since 2018.
The infrastructure side means an OpenLiteSpeed and Docker server alongside an EasyEngine and Nginx server, DNS migrated from Route 53 to Cloudflare, Wasabi S3 for per-site backups, and Ansible managing domain and server configuration consistently across the fleet. But the engagement doesn't stop at keeping servers up — it extends into the growth tooling behind the business itself: lead generation, cold-outreach sequences, automated audit reporting, and n8n workflow automation tying it together. It's the engagement that best represents where this work has ended up: not just "keep the servers running," but understanding the whole system a business depends on, from the database to the DNS to the workflow that turns a lead into a client.
What all of this adds up to
Read end to end, the pattern across fourteen years is consistent even though the technology underneath it changed completely: WHM and cPanel gave way to GridPane and modern managed WordPress hosting; raw EC2 instances gave way to Lightsail, then UpCloud, then in some cases no traditional server at all — just Vercel, Supabase, and a serverless deployment pipeline. What didn't change is the actual job: understand a system well enough that its owner stops having to think about it, document it well enough that someone else could take it over, and treat every migration like the business depends on it being boring.
That's the whole premise MatrixKloud is built on now — applying that same discipline to AWS platform engineering and AI inference infrastructure for digital agencies and tech founders who've outgrown ad-hoc sysadmin support but aren't ready for (or don't want) a full in-house DevOps hire. The scale is different from a thousand WordPress sites on shared WHM boxes, and the tools have moved on to GPU capacity planning and inference cost control. The underlying work hasn't changed at all: keep it running, keep it recoverable, and be the person who already fixed this problem the last three times it came up somewhere else.
What fourteen years actually teaches you
Ask a client what they remember about a good infrastructure partner and it's rarely a specific migration or a clever piece of automation. It's the absence of things: the outage that didn't happen, the renewal that didn't lapse, the incident that got resolved before they even heard about it. Good infrastructure work is invisible by design, which is exactly why it's so easy for a business to underinvest in it until something breaks in a way that isn't invisible anymore.
The clearest lesson across all of it — the WHM years, the hundred short freelance jobs, Hong Kong, Switzerland, the US transportation stack — is that the technology is never really the hard part. Configuring a server, writing an Ansible playbook, standing up a Next.js application: none of that is the scarce skill. The scarce skill is judgment about what actually needs to change, in what order, with how much risk, for a system that a real business depends on today, not a system you get to rebuild from scratch in a lab. Every migration in this story — WHM to GridPane, WordPress to a custom Next.js patient portal, Route 53 to Cloudflare — happened on a live system, for a client who needed it to keep working the whole time. That constraint, more than any specific technology, is what fourteen years of doing this actually trains.
Where it's going
The interesting problems have shifted from "how do you keep a thousand WordPress sites patched" to "how do you size and operate GPU capacity for a client's AI features without the bill or the downtime surprising anyone." Same discipline, newer questions. If there's a throughline across Growth99's server queues, RH Office's hundred-plus domains, Gojadental's rebuild, the Kabashi family's five properties, and Limo Network's full stack — it's that infrastructure work is never really finished, only handed off well or handed off badly. MatrixKloud exists to make sure it's the former, for whoever's environment comes next.