Exsited - Subscription billing platform

Challenge

Subscription billing platforms have brutal regression surface - invoicing edges, proration math, pricing-plan changes, mid-cycle upgrades, dunning flows. Every release touched at least one of those, and the existing test suite mixed end-to-end UI tests with unit-style assertions in ways that made failures hard to triage. The team wanted faster, more confident releases without growing the QA headcount linearly with the feature set.

Approach

Restructured the automation around two layers: a Playwright + TypeScript framework with reusable fixtures for the high-value web flows (subscription lifecycle, invoice generation, payment retries), and a separate API-test harness for the billing core where the source of truth lives. Adopted the page-object pattern with strongly-typed locators so refactors caught breakages at compile time. Added CI gates so flake-prone tests couldn’t quietly degrade - anything failing twice in a row got auto-quarantined and surfaced for triage, instead of being silently re-run until green.

Outcome

Regression suite became something the team trusted enough to gate releases on, rather than a sanity check after the fact. Time spent reproducing intermittent failures dropped substantially as the framework’s locator strategy and waits became more reliable. The team picked up the patterns quickly - the goal was always for the automation to outlive me on the project.

What I’d do differently

Started the API harness too late. The billing API has fewer flake sources than the web app and tests run an order of magnitude faster - should have been the first thing built, with UI tests layered on for the journeys that genuinely need the browser.