A Platform That Runs Without Its Engineer: 10,000 Tests, One Stack
Executive Summary: A multi-tenant platform lost its engineering team until one engineer remained. Instead of patching a fragile Rails + Vue.js application, I treated quality as a floor rather than a bet: the test suite grew from roughly 450 to 10,000 tests, the UI collapsed into a single stack, and the critical paths were rewritten under test. Revenue grew several times over in under a year. Years after I left, the product was still running and earning in the state I left it, with almost no code changes.
Context
I returned to the company full-time after an earlier six-month contract. The test suite stood at roughly 450 tests, barely above the ~400 I had written during that contract. There was no testing culture in the team.
Then the other developers left. Eventually I was the only technical person, next to two in operations. The application was a Rails backend with a Vue.js frontend, and it was fragile: every change risked a regression, and nobody else could catch one.
The constraint was simple. One engineer had to make the product safe to change, safe to hand over, and able to grow.
Decision
Quality as a floor, not an insurance policy Over about two years I raised the test count from ~450 to 10,000. I did not do this to hedge against a specific risk. It was the right way to engineer the product: if I left, a sound product would remain; if the team grew, newcomers could join without breaking things.
About a quarter of the growth happened while the team was still there, as I pushed them toward writing tests alongside their features; the rest I wrote alone after they left.
One stack instead of two I replaced the Vue.js frontend with Stimulus. The reasoning was practical:
- Stimulus lives inside Rails, so there was no second stack to learn, maintain, or debug.
- The product was mostly forms, and users want a solid form, not a client-side application.
- One stack meant one test strategy and one deployment path.
Rewrite the critical paths under test With the safety net in place, I rewrote the critical parts of the application from scratch instead of patching them.
Build from the customers’ needs I talked to the tenants directly, learned what they needed, and built those features myself. The infrastructure was managed with Terraform, and I arranged AWS credits to keep costs down.
Consequences
- Positive: Revenue grew several times over in under a year. On the engineering side, the chain was: a stable application built tenant trust, tenants spent more on advertising to their own customers, that brought in new end users, and our commission income grew with them. The platform also won one or two large new customers.
- Positive: The company became self-sufficient. Years after I left, the product was still running and earning in the state I left it, with almost no code changes. The test suite was the foundation it kept running on.
- Negative / Cost: The suite was a long investment. About two years of steady work passed before it paid off fully, and that was time not spent on features.
- Negative / Cost: Stimulus trades away Vue.js’s component ecosystem and client-side state model, which was acceptable for a forms-driven product.
When to revisit
If the product needs highly interactive client-side state (real-time dashboards, drag-and-drop builders, offline support), Stimulus starts to strain. At that point, isolated Vue.js or React components inside the Rails application should be evaluated, without a return to a full SPA.
This case note is an anonymized Architecture Decision Record (ADR) from a real-world engagement.