The observation
I spent a week understanding the platform before writing code. The fix was in the client channel: caching, local storage and prefetching cut the server load.
A multi-year greenfield rewrite had failed. I didn't identify the need - but once it had failed, I mapped the full system and built the automation inside the existing one, against its constraints. It removed ~10,000 person-days of manual work a year.
I called around 200 dealers and most said no. I asked each one why, rebuilt the marketplace around their reasons and added the dealer CRM they asked for. Twenty signed.
Different industries. Different decades. Different entry points. Same shape: the problem was unclear, misunderstood, or being solved wrong - and the method made it visible.
The pattern
The shape had five parts. I saw them again and again.
Before touching anything, question the problem statement. Most problems are symptoms of deeper problems. Most teams skip this step entirely - they start building before they know what they're building.
Different people know different pieces of the problem. Nobody has the full map. Scope is where the pieces connect - and where the gaps everyone assumed were filled become visible.
Architecture and process as one system. The monitoring, the rollback plan, the process changes - all part of the deliverable. A good solution in a bad process still fails.
Not training. Working side by side. Soft handoff, not hard cutover. The "why" document, not just the "how" runbook. The person who takes over was part of the solution from the start.
The real test: did it hold after you left? At one company, the automation became the platform default - teams must opt out. At another, people freed up from the automation expanded into entirely new business areas. The best lift isn't just "it still works." It's "it changed what the organization does by default."
What gets skipped
Every step that gets skipped has a cost.
Build the wrong thing. A team spent months solving a problem that wasn't the real problem.
Miss critical dependencies. A change that looked simple touched more systems than anyone had mapped.
Create debt that compounds. A performance fix without monitoring means the next failure is invisible.
Solution dies when you leave. A brilliant redesign only one person understands is a single point of failure.
No lasting impact. Just a line on your CV and a system that decays. The people didn't grow. The next problem is just as hard.
Two industries. Same method.
Enterprise SaaS, event payments
The client base doubled and data volume grew fivefold, and the critical paths had to keep up. I owned their performance from analysis to implementation: asynchronous communication, eventual consistency for the non-critical paths, in-memory caching and materialised views. Then I made it stick: performance rules every implementation passed through in review, and a guardrail that flagged unfiltered database calls before code review. It became the team standard.
Prize-flow audit, gaming operator
The client knew there were losses. Not how much. Not where. Internal tooling couldn't tell either. I was brought in to find it. I scoped the full chain: verification, payout, ATM reconciliation, cash flow, audit trail. Built observability and audit tooling that made the losses visible for the first time. The answer: ~€20,000 per day (~€7M/year), and now they knew exactly where. Built both business and technical processes. The platform runs without me.
Different entry points. Different problems. Same five steps. Same shape.
What QSAIL is not
Origin
I formalized QSAIL after two decades of noticing this same shape. Across smart TVs, scientific instruments, enterprise SaaS, fintech, automotive, and cash operations.
The method came from both doing AND learning. Practice since 2005, across 10+ industries, and the MIT Sloan Advanced Certificate for Executives in Management, Innovation, and Technology. Both matter. Practice alone is habit. Education alone is theory.
At some point I realized: I'm not following someone else's method. I built my own.
Have a problem where a step was skipped?
Most teams discover they skipped a step only after the project fails. If you already see it - that's the right time to talk.