Raith Rovers Football Club
Raith Rovers Scouting Platform
22s → 3-4s
Result: deep-filter operations dropped to roughly 3-4 seconds, making the product usable under real scouting pressure.
Read the case studyWeb App Rescue & Refactoring for SaaS Products That Got Too Hard to Change
I help founders clean up slow, fragile web applications without gambling the whole product on a risky rewrite.
If every new feature feels expensive, your roadmap may not be the problem.
The codebase may be fighting the product.
Technical debt triage, performance optimization, architecture cleanup, and refactoring for existing SaaS products, dashboards, and internal tools.
Signs your web app needs rescue, not another rushed feature
Most codebases do not suddenly become bad. They rot one shortcut at a time.
- Feature releases that used to take days now take weeks
- Every small change risks breaking something unrelated
- Performance is getting worse as data, users, or workflows grow
- New developers struggle to understand the product flow
- The team avoids useful features because the implementation feels scary
What I help fix
- —Slow dashboards, SaaS products, and internal tools that no longer feel smooth
- —Technical debt that makes every feature more expensive than it should be
- —Frontend and backend architecture that nobody wants to touch
- —Messy APIs, duplicated logic, unclear data flow, and feature code glued into the wrong places
- —Database queries, indexing, caching, and performance bottlenecks users actually feel
The goal is not to polish code for its own sake. The goal is to remove the parts of the system that are making product decisions slower, riskier, and more expensive than they should be.
Most of this work sits in modern JavaScript stacks: Next.js, Angular, Node.js, TypeScript, MongoDB, and the usual mess around them.
How I clean up the mess without blowing up the product
Rescue work needs judgment. Moving too fast can make the mess worse. Moving too slowly lets the product keep bleeding.
- —Map the real product problems before touching code
- —Audit the risky areas: architecture, data model, APIs, performance, and deployment flow
- —Separate urgent fixes from deeper refactors
- —Refactor in controlled steps so the product can keep running
- —Leave the codebase easier to change, test, and hand over
Real rescue work: 22s filters cut to 3-4s
On the Raith Rovers scouting platform, deep player filters were taking around 22 seconds. The fix was not a rewrite. It was targeted engineering: query analysis, MongoDB indexes, lean query paths, caching, and precomputed scoring where it made sense.
This is not for every messy codebase
- —Some products should be rebuilt.
- —Some products are too early for rescue work.
- —Some codebases are messy but not actually blocking the business.
The right move depends on the product, the users, the team, and where the pain really is.
I am not interested in refactoring for sport. If the mess is not slowing the product down, it can wait. If it is slowing the product down, we fix the parts that matter first.
You may not need a rewrite
Rewrites are sometimes necessary.
But they are also expensive, risky, and usually underestimated by people who have not been burned by one. In many products, the better move is focused triage.
- —The product has users and revenue, but the codebase is slowing decisions down
- —The main problem is unclear structure, duplicated logic, or performance hotspots
- —The team needs stability while improving the system underneath
- —A full rebuild would pause the business for months without proving enough upside
What a rescued codebase should make possible
- —Faster feature delivery
- —Less fear around releases
- —Clearer architecture for the next developer
- —Better performance where users actually feel it
- —A product that can keep moving without a full rewrite
Is your product getting harder to improve every month?
I can help you find what is actually slowing the system down, clean up the parts that matter, and get the product moving again without pretending every problem needs a rewrite.