The situation
The product ran on a legacy licensed system, hosted on VPS servers. The company was paying to run a platform it did not own, and the product could only move as fast as someone else's software allowed.
This is one of three outcomes from the same company: a cybersecurity awareness SaaS business where I spent about seven years, from systems developer to technical lead to CTO. That matters. I was not a consultant who designed something and left. I lived with every decision on this page for years afterwards, and so did the customers.
What I did
I rebuilt the platform as a cloud-native, proprietary SaaS on AWS, running in Docker containers.
Proprietary meant the company owned its core product outright, instead of renting it. Cloud-native meant the platform was designed for the cloud from the start, rather than lifted onto it and left to run up a bill.
The rebuild was judged on money as much as on engineering. The question was never only whether the new platform worked. It was whether it paid for itself, and kept customers safe while it did.
The result
- lower infrastructure cost: the new platform ran for 4% of the old bill
- 96%lower infrastructure cost: the new platform ran for 4% of the old bill
- downtime over three years, with 100% SLA adherence
- 0downtime over three years, with 100% SLA adherence
Those two numbers belong together. Cheap and fragile is easy. Cheap and boringly reliable is the job.
What it means for you
If your product runs on something you license, rent or inherited from a previous developer, its cost and its risk tend to grow quietly until a big customer asks a question you cannot answer.
That is the kind of problem I take on as a fractional CTO who ties technology spend to revenue: work out what your platform really costs, what it should cost, and whether rebuilding is worth it at all. Sometimes it is not, and I will tell you so.