Ben Newton - Commerce Frontend Specialist
Engineering leadership

Technical debt is a leadership problem. Not an engineering one.

Your engineers know the debt exists. They have been telling you for months. The problem is not awareness — it is that leadership has not created the system to address it without stopping feature delivery.

30 years of watching teams drown in debt they did not choose to take on. I fix the leadership system that creates it.

Free 30-min auditPrioritized debt inventoryShip while you fix
30 years experienceEnterprise-scale fixesAI-accelerated migrationShip while fixing

Debt does not accumulate because engineers are lazy.

It accumulates because leadership optimizes for features without budgeting for quality. Every sprint that ships features without addressing debt is a leadership choice.

"We will fix it later" — later never comes because the next sprint has features too
New features take 3x longer because every change fights the existing codebase
Velocity declining every quarter while the team grows — more people, less output
Senior engineers leaving because they are tired of fighting the codebase instead of building
Competitors shipping faster with smaller teams because their foundation is cleaner
The rewrite conversation keeps coming up — but nobody has a plan that does not stop the business

The fix is not “stop and rewrite.” It is systematic debt reduction while shipping.

Debt taxonomy

Not all debt is the same. The strategy depends on the type.

I audit your codebase and categorize debt by type, compound rate, and business impact.

Architecture debt

Monolithic frontends, missing abstraction layers, tightly coupled systems. Decisions that were right at 10 users but break at 10,000.

Symptom: Every feature touches everything

Documentation debt

Architecture decisions live in one person's head. New developers take weeks to onboard. Offshore teams cannot function independently.

Symptom: Nobody knows why it was built this way

Process debt

No code review standards. No testing gates. No deployment automation. The team is moving fast but leaving a trail of inconsistency.

Symptom: Quality depends on who wrote it

Dependency debt

Outdated frameworks, unmaintained libraries, version conflicts. The longer you wait, the bigger the migration when something breaks.

Symptom: Fear of updating anything

Security debt

Authentication shortcuts, missing tenant isolation, unvalidated inputs. Technical debt that becomes a liability disclosure.

Symptom: You hope nobody looks closely

Performance debt

Bundle sizes growing unchecked, unoptimized queries, missing caching. Death by a thousand small regressions.

Symptom: The site gets slower every sprint

How I fix technical debt without stopping the business.

Incremental strategy. Not a rewrite.

01

Audit and prioritize

Map every category of debt. Rank by compound rate and business impact. Build a prioritized inventory that speaks the language of revenue, not refactoring.

1-2 weeks
02

Design the reduction strategy

Debt budgets per sprint, strangler fig patterns for architecture, automated quality gates that prevent new debt. A plan that ships features and reduces debt simultaneously.

1 week
03

Execute with AI leverage

AI agents handle the repetitive migration work — pattern updates, type annotations, test generation. Humans focus on architecture decisions. Ship while you fix.

Ongoing

I have watched debt kill projects. I have fixed it in others.

In 30 years, I have seen the full spectrum — from Fortune 500 commerce platforms drowning in legacy code to startups that accumulated a year of debt in 3 months. The pattern is always the same: leadership did not build a system for quality.

I fix the system. Automated quality gates, debt budgets, architecture decision records, and the cultural shift that makes quality everyone's job — not a backlog item that never gets prioritized.

30
Years fixing debt
84%
Bundle size reduced
0
Successful rewrites recommended
Weeks
To first improvements

Common questions

What leaders ask about technical debt strategy.

How do I convince leadership to invest in debt reduction?

Stop calling it "technical debt" — call it what it costs. "Our checkout takes 8 seconds because of architecture decisions we deferred. That is losing us $X per month in abandoned carts." Leadership responds to business impact, not engineering terminology. I help you translate debt into dollars.

Should we stop feature work to address tech debt?

Almost never. The "stop everything and rewrite" approach fails because the business cannot stop. Instead, I design incremental strategies — the strangler fig pattern for architecture, debt budgets per sprint, and automated quality gates that prevent new debt. You improve while you ship.

How do you prioritize which debt to tackle first?

By compound interest. Which debt is getting worse the fastest? Which debt blocks the most feature work? Which debt carries the highest risk (security, performance, compliance)? I build a prioritized debt inventory ranked by business impact, not engineering preference.

Our team says everything is tech debt. How do we know what is real?

Real tech debt slows you down measurably. If a developer says "this is tech debt" but cannot explain how it impacts velocity, reliability, or maintainability in concrete terms, it is a preference, not a debt. I help teams distinguish between actual debt and desired refactoring.

How does AI help with technical debt?

AI agents can automate the tedious parts of debt reduction — migrating API patterns, updating deprecated syntax, adding type annotations, generating tests for untested code. The human focuses on architecture strategy; the AI handles the repetitive execution. I design workflows that make this structured and trackable.

What about just rewriting from scratch?

In 30 years, I have seen exactly two successful ground-up rewrites. The rest failed, were abandoned, or shipped late with the same problems. Incremental migration — the strangler fig pattern — is almost always the right answer. You replace pieces while keeping the system running.

How long does a debt reduction engagement take?

The audit and strategy typically takes 2-3 weeks. Implementation depends on scope — quick wins appear in the first sprint, structural improvements take 2-3 months. I usually stay engaged through the first structural milestone to ensure the patterns stick.

Can you help if we already have a rewrite in progress?

Yes. I can assess whether the rewrite is on track, identify risks early, and help course-correct before it is too late. If the rewrite needs to be abandoned, I help design the incremental migration path that should have been chosen initially.

Find out what your technical debt is actually costing.

A 30-minute audit covering your codebase health, velocity trends, and a prioritized breakdown of which debt to tackle first — ranked by business impact, not engineering preference.

You will leave with a prioritized debt inventory and a reduction strategy that does not stop feature delivery.

Fix Your Debt Strategy

Free 30-minute audit. Prioritized inventory. Incremental strategy.

Technical Debt Is a Leadership Problem — Not an Engineering One | Ben Newton