Hi everyone, I’m looking for clarification regarding the AI Mentor’s Technical Debt analysis, specifically the metric “% High Tech Debt” shown in the dashboard (example: 45% High Tech Debt — image attached). I have a few questions: How risky is it when AI Mentor shows a high percentage of Technical Debt? What kind of impact can this have on application performance, maintainability, and future scalability?
What is considered a normal or acceptable Technical Debt percentage in typical OutSystems applications?
Is there any recommended threshold or benchmark from OutSystems?
At what point should I worry and take action to reduce it?
Any guidance or best practices from your experience would be really helpful.
Thanks!
In OutSystems AI Mentor Studio, the “% High Tech Debt” metric is a weighted calculation of how much "risk" or "rework effort" exists in your factory compared to the platform's best practices
1. How risky is a high percentage?
A high percentage indicates that a significant portion of your technical debt comes from High or Highest impact patterns.
If your percentage is high, it means you have many "red" findings (e.g., SQL injections, circular dependencies, or heavy logic in loops). These aren't just cosmetic; they are structural flaws that can lead to system crashes, data breaches, or "deployment deadlocks" where you cannot update one app without breaking five others.
2. Impact on Performance, Maintainability, and Scalability
Performance: High debt in the "Performance" category usually means your database is working 10x harder than it needs to (e.g., fetching 100 columns when you only need 2).
Maintainability: High debt makes the code "brittle." A simple change that should take 2 hours might take 2 days because developers have to navigate a "spaghetti" of dependencies.
Scalability: Poor architecture (like upward references) prevents you from scaling. You won't be able to move a module to a different server or split a monolithic app into microservices without a total rewrite.
3. What is "Normal" or "Acceptable"?
There is no "official" universal number because every factory is different, but based on industry standards and OutSystems partner benchmarks:
Healthy: 0% – 10%
Excellent. You are likely following the Layer Canvas and performing regular refactoring.
Manageable 11% – 20%
Typical for high-velocity teams. While technical debt is accumulating, it has not yet reached a level that significantly impacts delivery speed
Warning 21% – 40%
Significant friction. Developers will start complaining that "the code is messy" and deployments will get slower.
Critical > 40%
High risk of failure. You are likely experiencing "Software Erosion" where fixing one bug creates two new ones.
4.You should start taking action when you see these three "Red Flags":
1. The Trend Line is Upward: If your debt grows every week, your team is prioritizing speed over quality in a way that is unsustainable.
2. Security/Architecture "Red" Findings: Any finding in the Security or Architecture category with a "Highest" weight should be fixed in the next sprint, regardless of the overall percentage.
3. The "Yellow/Red" Heatmap: In the Apps Canvas, if your core business apps are turning red, they are becoming "Black Boxes" that nobody wants to touch.
Hi @Ajit Kurane ,
1.Inspect What Makes Up That 45%-
Are they: Performance issues? -Architecture violations?- Security warnings?- Large action complexity?
The composition matters more than the number.
2.Prioritize Like This: Security->Performance->Architecture->Maintainability
Check these documentations as well:
Code Analysis Patterns and Manage Technical debt.
Thanks,
Dhanasingh Dennison T