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.

Energy Management Beats Time Management in Engineering

Thu, 20 Nov 2025 00:00:00 +0000

If you look at a standard burn-down chart or a timesheet, software development looks deceptively linear. One hour of coding equals one unit of output. If a project is falling behind, the “logical” management solution is to add more hours, ask the team to stay late, work a weekend, or squeeze in “just one more ticket” before the sprint closes. Or if you have the payroll, add more engineers.

But anyone who has actually written code knows this is a lie.

Ship Fast

Tue, 18 Nov 2025 00:00:00 +0000

We’ve all felt the itch. You open a file to make a small change, and you’re immediately confronted with a mess. Maybe it’s legacy code that has overstayed its welcome, or an architectural pattern that creates friction every time you try to add a feature.

The instinct is to fix it. To overhaul the system until it is clean, modern, and “right.”

While this conscientiousness is a vital trait for senior engineers, there is a dangerous trap that lies between the urge to fix and the execution of that fix: The Big Bang Refactor.

Excellence is a Habit: Why Shipping Software Beats Perfection

Mon, 17 Nov 2025 00:00:00 +0000

The urge to “rewrite it all” is often disguised as a pursuit of excellence.

We’ve all seen the pattern. An engineer opens a file and becomes allergic to what they see. Maybe it’s messy legacy code, a “temporary” hack that is now celebrating its third birthday, or an architectural pattern that no longer fits the scale of the application.

The instinct is to fix it. To overhaul it. To make it clean, modern, and “right.” This is a good instinct! We should seek to improve things as we go, and developing that conscientiousness is vital for any senior engineer.

"Why Is Everything So Slow?", and how to fix it with Lead Time

Tue, 11 Nov 2025 00:00:00 +0000

Everything feels…slow. You have an idea, or a critical feature, or an urgent bug fix, but it takes forever to send it through the process. Half the time it feels like it’s not even going through the process, it just dies on someone’s desk. Vanishing into the black box for weeks or months is a silent killer, and it’s both frustrating and disrespectful for anyone who’s making requests/demands on an engineering team.

Why's Everything So Slow?

Tue, 11 Nov 2025 00:00:00 +0000

Does this feel familiar?

Everything feels… slow. You have a critical feature or an urgent bug fix, but it takes forever to get it through the process. Your engineering team feels crushed under a mountain of work, their calendars are full, their velocity charts look good, and they are busy.

But where are the results?

This disconnect, where “busy” doesn’t equal “delivery,” is one of the most frustrating and costly problems in software development. It’s a sign your company’s “ship” has a lot of little leaks.

Debt or Slop?

Fri, 11 Jul 2025 00:00:00 +0000

I once worked with a guy named Ev, who is quite possibly one of the most prolific yet worst programmers I’ve ever worked with. During a review of something he implemented, another guy on the team asked “Who is benefitting from all of this code? Are we trying to please the gods of programming by offering them a sacrifice of so many lines of code?”

Following up after him was demoralizing. His implementations were often done out of band and just sort of wedged into production. Most of his work had to be completely rewritten, and the replacement process took far longer than just doing it correctly the first time. Nearly everything else had to be decommissioned, often with apologies to the internal stakeholders and clients.

Tall Poppies and Rockstars

Mon, 07 Jul 2025 00:00:00 +0000

We’ve all heard the term “rockstar developer.” For many, it conjures images of a reckless “cowboy coder”, a lone wolf who moves fast, breaks things, and leaves a trail of messy, unmaintainable code for the rest of the team to clean up.

The tech industry narrative has soured on this archetype, painting them as a short-term gain for a long-term headache. Many have even concluded that the true 10x developer is a myth, a cynical recruiting buzzword with no basis in reality.

Taste: In Defense of the Rockstar Programmer

Sun, 06 Jul 2025 00:00:00 +0000

Back in the early 2000s, tech recruiters got their talons on a new phrase: the “rockstar developer”. They’d heard of this mythical creature: the one who ships features at a dizzying pace, who can solve impossible problems overnight, who know exactly what to do.

Like most industry terms, it got twisted, overused, and turned into corporate-speak for someone who we all hate. Painting with a broad brush, you can conjure up images of the lone wolf, a “cowboy coder” who writes messy, unmaintainable code, disregards the team, and leaves a trail of technical debt in their wake. Nowadays, the narrative is that these developers are brilliant but reckless, a short-term gain for a long-term, high-interest loan you’ll be paying off for years. Or more often, people believe that it’s just hype and that the rockstar doesn’t exist, or is a liar.

Stay Focused, King

Sat, 07 Jun 2025 00:00:00 +0000

Focus is hard.

Building software is usually really intricate, but also fairly tedious. There are a lot of tools to help get past the tedium nowadays, but we tend to lose sight of the fundamentals in favor of what we feel like we should do. We copy what we see other admirable companies doing in the hope that their success will rub off onto our own process and we’ll see similar results.

You Aren't Gonna Need The Chaos Monkey

Sat, 07 Jun 2025 00:00:00 +0000

Years ago, Netflix, in a brilliant move of engineering resilience, created a tool that would deliberately and randomly shut down their own production servers, create havok in their network, and otherwise try to destabilize their infrastructure. The idea was simple, yet profound: if you know chaos is coming, you’re forced to build systems that can withstand it. They wrote a blog post about it, released the open-source code, and almost overnight, a new legend was born in the tech world.

Do You Need To Streamline Your Software?

Tue, 25 Mar 2025 00:00:00 +0000

Your wife has a dream…

She wants to move to the country, away from the hustle and bustle of the city. After all, your kids need trees to climb, grass to roll around in, and dirt to throw in each other’s eyes.

You study Zillow like a textbook before a final exam. Finally, you find the perfect property: a three bedroom, two bath house on an acre of land. Offer made, offer accepted.

About Jordan Ambra

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

I’m Jordan Ambra, founder of Serenity.

Over the last 25 years, I’ve worked across 350+ software teams as a coder, CTO, and founder.

I bridge the gap between “Business Needs” and “Developer Reality” because I speak both languages fluently. I tell founders and executives the uncomfortable truths hiding in their teams and software products, and I connect engineering teams with the business to deliver the best possible product.

How It Started

Age 12. I’m visiting my aunt. She brings me to the bookstore and says “Jordan, pick a book and I’ll buy it for you.” So naturally, I picked out a 600-page HTML book and read it three times.

Before You Fund the Rewrite

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

Staring at a large rewrite quote? An Engineering Audit tells you what to rebuild, what to fix in place, and what to stop. One client’s $5M plan became a $500K project.

Discuss an Engineering Audit

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

Engineering Advisory for Investors

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

Get Your Team Unstuck

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

Your team works hard and little ships. An Engineering Audit tells the founder what is in the way and which decisions come next.

Launchpad

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

I love building software. It’s fun, creative, and rewarding not just for its own sake, but because you can reach and help so many others.

The software I’ve written has been used by many millions of people, perhaps even you.

I’ve founded 15 startups, so I’ve seen the entrepreneurial “hit rate” up close. It’s something like 5%. You never really know when something is going to take off, and it’s often not what you expect. Launching a second product after a successful first is also much more likely to be successful, probably because you know where to put your time (marketing and distribution).

Privacy Policy

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

Effective date: May 8, 2026

Serenity Software (“we”, “us”, “our”) offers a variety of applications and services. This policy describes how we collect, use, and protect your information across all of our applications and the serenity.software website (collectively, the “Services”). Your use of the Services is also governed by our Terms of Service.

Information We Collect

Account Information

When you create an account for any of our applications, we collect your email address and a securely hashed password. We do not store plaintext passwords.

Resources

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

Terms of Service

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

Effective date: May 8, 2026

These terms govern use of the applications and services operated by Serenity Software (“we”, “us”, “our”), including the serenity.software website (collectively, the “Services”). By using any of our Services, you agree to these terms.

Account Registration

You must provide a valid email address and password to create an account. You are responsible for keeping your credentials secure and for all activity that occurs under your account.

The Engineering Audit

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