Recently, I reviewed the Technical Debt of an Enterprise’s Salesforce Instance.
We’ll clean it up after go-live. or let’s add it to the backlog.
I’ve heard this on almost every enterprise Salesforce project I’ve been part of.
It sounds reasonable. The pressure is real — timelines are tight, stakeholders are watching, and the business wants to go live. Cleaning up feels like a luxury.
But here’s the problem: technical debt in Salesforce doesn’t sit quietly in the corner waiting for you to come back to it. It compounds.
Every new feature you build on top of it inherits the problem. Every new developer who joins the org inherits the confusion. Every release cycle gets slower, riskier, and more expensive – not because the new work is hard, but because the old work is fragile.
And the worst part? Nobody can see it. Even if they see, they will ignore it.
Unlike a broken flow or a failed deployment, technical debt is invisible. It doesn’t throw errors. It doesn’t alert anyone. It just quietly makes everything harder, costlier, and slower – until one day, it breaks something important at the worst possible time.
So I decided to stop talking about technical debt and start mapping it.
Below is a Technical Debt Scoring Matrix – a framework for making the invisible visible, prioritizing what actually matters, and giving you a defensible way to have the conversation with stakeholders who don’t want to hear about “cleaning things up.”
The Problem With How Most Teams Handle Technical Debt
Most Salesforce teams handle technical debt in one of two ways.
The first way: ignore it entirely. New features take priority. The backlog grows. The org gets slower. Nobody connects the dots between the debt they accumulated three years ago and the deployment that failed last week.
The second way: do a “big cleanup sprint.” Someone raises the alarm, a sprint gets allocated, the team spends two weeks fixing things, and six months later the debt is back — because nothing changed about how decisions were being made.
Both approaches fail for the same reason.
They treat technical debt as a one-time problem instead of a permanent architectural reality.
Technical debt is not a bug. It’s a natural byproduct of building software under real-world constraints. The organisations that manage it well don’t eliminate it – they govern it. They have a way to see it, score it, and make explicit decisions about it instead of letting it accumulate in the dark.
That’s what the matrix is for.
The Technical Debt Scoring Matrix
The matrix scores technical debt items across two dimensions:
Business Impact – How badly does this debt affect the business right now? Does it slow users down, introduce risk, cause errors, or block future features?
Remediation Effort – How hard is it to fix? How much time, skill, and risk does it introduce to address it?
Each item gets scored 1–3 on each dimension. The combination places it in one of four quadrants – each with a clear, actionable response.
Here’s the matrix:
Quadrant 1: Fix Now (High Impact, Low Effort) These are your quick wins. High business pain, low cost to fix. These should never sit in a backlog. If something scores here and it’s not being addressed in the current sprint, you need to ask why.
Examples: Recursive flow, permission sets that grant far more access than needed, hardcoded IDs in Apex.
Quadrant 2: Plan and Fund (High Impact, High Effort) These are your architectural debts. Significant business risk, but expensive to fix. They need a proper business case, dedicated capacity, and executive awareness. These don’t get fixed in a cleanup sprint – they get funded as proper projects.
Examples: A legacy Apex trigger framework that blocks modern automation adoption, a point-to-point integration architecture that needs to be rebuilt with platform events or MuleSoft, a data model designed for 50,000 records that now holds 5 million.
Quadrant 3: Batch Later (Low Impact, Low Effort) Real but not urgent. Schedule these in maintenance windows or quiet sprints. Don’t let them distract from higher-priority work, but don’t ignore them indefinitely either. They’re the broken windows of your org – small things that, left unaddressed, signal to the team that standards don’t matter.
Examples: unused fields and page layouts, redundant reports nobody runs, outdated picklist values, deprecated API versions in callouts that haven’t broken yet.
Quadrant 4: Accept or Retire (Low Impact, High Effort) The most important quadrant for honest conversations. If something scores here – low business impact, high effort to fix – the right answer is often not to fix it at all. Accept it as a known limitation, document it clearly, and move on. Or retire the feature entirely if it’s no longer needed.
This is where ego gets in the way. Architects don’t like leaving things imperfect. But spending six weeks refactoring something that isn’t causing problems – while high-impact debt accumulates is a failure of prioritisation, not a sign of quality.
The Conversation the Matrix Enables
Here’s the real value of this exercise — and it’s not technical.
When you walk into a steering committee meeting with a list of “technical issues to fix,” you get nodded at and ignored. When you walk in with a matrix showing eight Q1 items that represent active business risk including a security vulnerability and two governor limit time bombs and a funded proposal for six Q2 items that would reduce release risk by an estimated 40%, the conversation is different.
The matrix transforms a technical conversation into a business conversation.
It answers the questions stakeholders actually care about:
“What happens if we don’t fix it?” → The impact score tells you.
“How much will it cost?” → The effort score tells you.
“What should we do first?” → The quadrant tells you.
“What can we live with?” → Quadrant 4 tells you, and gives you permission to say no to low-value work.
This is what separates architects who get things done from architects who write good documents that nobody reads.
The Flywheel Nobody Talks About
Here’s the insight that only became visible after mapping everything.
Technical debt accumulates faster than most teams realise – not because teams are careless, but because every sprint that doesn’t address debt makes the next sprint slightly slower. Slightly riskier. Slightly more complex.
That slowdown is invisible until it isn’t.
But the reverse is also true.
Every Q1 item you fix makes the next sprint slightly faster. Every Q2 item you fund and complete removes a category of risk from every future release. Every piece of documentation you write reduces the cost of the next developer onboarding.
The flywheel runs in both directions.
Debt compounds. So does quality.
The matrix is how you decide which direction you’re running.
The One Thing
If you take nothing else from this post, take this:
You cannot govern what you cannot see.
Most Salesforce orgs carry significant technical debt, not because the teams building them were careless, but because there was never a structured way to see it, score it, and make explicit decisions about it.
The matrix gives you that structure.
Run it on your org. Even a rough pass across the four quadrants above will surface more than you expect – and give you a defensible, business-ready way to act on what you find.
Because “we’ll clean it up after go-live” is how the debt starts.
A scoring matrix is how it stops.
_________________________________________________________________________________
What’s the biggest source of technical debt you’ve seen in enterprise Salesforce orgs? Drop it in the comments.
CloudShetra 
Leave a comment