03 · Quality & delivery
QA is often seen as the team that says no at the end. Done properly, it's the reason you can ship faster, because problems are caught early and decisions are made on evidence. I've built QA functions from nothing, led a 2-million-customer migration, and made the calls on when to ship and when not to.
Sound familiar?
Bugs regularly reach customers, and you find out from complaints.
Every release feels risky, so releases are slow or get delayed.
You have testers but no strategy, or a strategy nobody follows.
A big launch or migration is coming and you need someone who's done it before.
What you get
Roles, career paths, hiring, standards and the rules that hold the line, like mandatory sign-off before major releases. Built so it keeps running without me.
The right tests at the right layers, from unit and contract tests to end-to-end, with Playwright, Appium and visual regression running in your pipeline.
Moving customers in groups, with clear rules for who moves when, written go/no-go decisions, and data checks before anyone looks at the screens.
Monitoring and dashboards that show where customer journeys fail, so you fix issues before they turn into complaints.
Proof
Two high-risk programmes run as one: moving customers group by group while switching off the old app. I set the rules for who moved when, and ran two testing approaches side by side to bring the timeline forward by weeks.
Career paths, hiring, standards and a leadership layer underneath me, so the function grew without depending on one person. QA went from being seen as a blocker to being trusted in the room where decisions get made.
Under pressure to ship new login security before the busiest period of the year, I ran an evidence-based readiness check. It found real regressions that could have locked customers out, and the release was paused with interim protections in place.
I brought in a new monitoring tool, used it to find exactly where logins were failing, then led the fix across design, engineering and QA. The improvement showed up in the numbers straight after release.
Questions
Yes. Interim leadership while you hire is common, with a handover plan agreed from the start.
Where it helps: drafting test scenarios, reviewing pull requests and sorting failures. People still decide, and customer data stays out of prompts.
No. The scale changes, not the principles. For a small team it might be a two-week review and a lightweight test strategy.
Contact
Thirty minutes to talk through what you’re trying to fix. If I’m not the right fit, I’ll say so, and point you to someone who is.