Case Studies on Serenity Software

The $5M rewrite, delivered for $500K

Mon, 01 Jan 0001 00:00:00 +0000

The situation. An established platform that everyone was afraid to touch. Releases were slow and risky, delivery had ground to a crawl, and the plan on the table was a full rewrite: $5 million and years of parallel work while the old system kept running.

What I found. The $5 million wasn’t the price of what the business needed. It was the price of rebuilding everything, including features nobody had opened in years. When we listed what the business actually used and made money from, it was a much smaller system than anyone assumed.

From MVP to production-grade in 4 months, not 2 years

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A funded startup with a working MVP and paying customers. The product was breaking under real usage, and the plan to fix it properly was a two-year rebuild. They didn’t have two years. Nobody at that stage does.

What I found. Most of the plan was building for scale they didn’t have yet. New infrastructure, new abstractions, rewrites of things that already worked. Meanwhile the actual complaints came from a handful of places: a few unstable features, deploys everyone was scared of, and bugs that customers found before the team did.

From WordPress to a real platform: 3x the business in 18 months

Mon, 01 Jan 0001 00:00:00 +0000

The situation. An education company running on WordPress. The site had carried them from idea to a real business, and now it was the thing holding them back. Errors were constant, new features took months, and bigger customers were asking for a white-label product the site had no way to offer.

What I found. WordPress wasn’t the villain. The product had simply outgrown it: years of plugins and custom code stacked on top of each other, where every change broke something else and every error was hard to trace. The business they’d become needed an architecture the original site was never going to grow into.

The legacy rebuild that doubled revenue in 2 years

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A mature membership business on a website that had been cobbled together over many years. Processes held together with duct tape, an architecture that failed in a new way every month, and pages that took multiple seconds to load. The team spent its energy keeping the thing alive instead of making it better.

What I found. No single disaster, just years of shortcuts that had compounded. Every part of the system worked slightly differently, nothing trusted anything else, and the slowness and the breakage came from the same root: nobody had ever unified how things got built and shipped.

The two-person team that outran bigger competitors

Mon, 01 Jan 0001 00:00:00 +0000

The situation. Two founders with a good product and a backlog they were never going to finish. Every week went into grinding through development work, and the backlog got longer anyway. Competitors with far bigger teams were shipping faster than they could.

What I found. They didn’t need more people. A big share of their development process was repetitive work that a machine should have been doing, and the two of them were spending founder hours on things that didn’t need a founder.

An IoT refactor done in 2 months, not 2 years

Mon, 01 Jan 0001 00:00:00 +0000

The situation. An IoT platform on a microservices architecture that had grown hard to live with. Performance problems, fragile services, and data nobody fully trusted: flaky sensors, third-party feeds that sent odd values, and code that was risky to change. The internal estimate for fixing it properly was two years.

What I found. The architecture didn’t need to be thrown out. It needed fewer moving parts, clearer boundaries, and a serious stance on data quality. Most of the firefighting traced back to bad data getting deep into the system before anyone noticed it was bad.

Terabytes a day through an architecture that just works

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A client that needed to ingest and process serious volumes of streaming data, terabytes every day, and needed an architecture that could handle it reliably without an army to keep it running.

What I found. This is one of the few problems where microservices genuinely earn their keep. Most teams reach for them for the wrong reasons and pay for it in operational pain. Here the shape of the problem actually matched the shape of the solution: independent stages, very different scaling needs, and clear boundaries between them.

From $0 to $15M ARR in 18 months

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A funded B2B SaaS company with a market waiting and a prototype straining to become a product. The early version proved the idea. It also didn’t work very well, and every week of building on it made that worse. I came in to reset the foundations: rearchitect the product, help build the real version, and build out the engineering team around it.

What I found. Prototypes are supposed to be thrown away, and this one had quietly become the plan. There was no architecture underneath it, just accumulation. The team was working hard; the work just had nothing solid to compound on. The move wasn’t to polish the prototype. It was to keep what it had proven and rebuild what it stood on.

From 60 hours of downtime a year to zero

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A healthcare software company losing about 60 hours a year to downtime. Every hour down cost thousands of dollars, and the money was the smaller half of it: every outage buried the support team in grief and chipped away at customer trust, in an industry where trust is the product.

What I found. The outages weren’t bad luck, and they weren’t one bad system. The infrastructure was fragile, almost nothing was monitored, and underneath both of those, quality had quietly become optional: nothing in how the team worked pushed back on a cut corner, so corners got cut, and the downtime was the bill arriving.

The product they couldn't hire for

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A large automotive company needed a new product built and launched, and the role it required was the kind that barely exists on the market: deep enough technically to build the thing, product-minded enough to know what to build, and business-minded enough to make it earn its keep. They had been trying to hire it. I came in instead.

What I found. The team wasn’t the problem. What was missing was the hybrid at the center: someone who could make the technical calls and the product calls as one decision instead of two meetings. Without that person, every choice needed a translator, and translated decisions are slow ones.

From 10,000 errors a day to zero

Mon, 01 Jan 0001 00:00:00 +0000

The situation. A software product in the pharmaceutical industry throwing about 10,000 errors a day. It worked when everything went exactly right, and almost never otherwise: bad input, unexpected paths, and anyone probing for weaknesses all landed in the same unguarded place. In an industry that does not forgive sloppy software, this was a product running on luck.

What I found. The product had been built for the happy path only. No real validation at the edges, no plan for failure, and nothing standing between a curious attacker and the inside. The 10,000 daily errors weren’t 10,000 separate problems; they were the same handful of root causes, echoing thousands of times a day because nothing existed to catch, resolve, or prevent them.