Reduced defects by 40% (recapturing 2+ sprints per quarter previously lost to reactive fixes) by consolidating legacy Xebra dependencies into a unified iSuite architecture.
40%
Reduction in platform defects
The platform carried deep dependencies on Xebra, a legacy system that created architectural debt across identity, access control, and financial workflows. Misaligned systems produced defects at the seams: billing errors, access inconsistencies, and audit failures that were expensive to diagnose and fix.
Legacy rationalization is one of the most politically and technically complex initiatives a product manager can lead. The systems that need to be rationalized are usually the ones most deeply embedded in the organization's operations -- they have undocumented dependencies, tribal knowledge, and a history of "don't touch it, it works" decision-making that has accumulated over years.
Xebra was exactly this kind of system. It had been built incrementally over years as iPROMOTEu's primary operational platform, and while iSuite had been introduced as the modern front end, the underlying logic and data remained tightly coupled to Xebra's servers. The result was a hybrid architecture where neither system was fully authoritative -- iSuite presented the interface, but Xebra held the state.
This created a specific class of defects that were nearly impossible to prevent: defects at the seams between systems. When iSuite updated a user's role, Xebra might not reflect the change immediately. When Xebra processed a billing event, iSuite might not update the account status correctly. These weren't bugs in either system -- they were bugs in the relationship between systems.
My strategic framing was critical: this was not a bug-fixing initiative. It was a system alignment initiative. The goal was not to fix the symptoms (individual defects) but to eliminate the structural cause (misaligned systems). That distinction changed the scope, the stakeholder alignment, and the success metrics.
A systematic rationalization of Xebra dependencies, aligning identity, role-based access, and NetSuite billing workflows into a unified iSuite architecture. This wasn't a migration -- it was a consolidation that eliminated the structural causes of defects rather than patching symptoms.
I mapped all Xebra dependencies across identity, access control, and financial workflows to identify the highest-defect-generating seams
I defined a consolidation strategy that prioritized defect-generating seams first, delivering immediate reliability improvements
I aligned identity and role-based access into iSuite's unified model, eliminating the primary source of access inconsistencies
Synchronized NetSuite billing workflows to eliminate financial reconciliation errors and audit findings
I established shared validation logic and clear data contracts between iSuite and Xebra services during the transition period
Defects reduced by 40%. Material audit findings eliminated. Identity, access, and billing workflows aligned into a single coherent system. Platform reliability improved significantly across all three domains. Engineering time spent on reactive fixes decreased substantially.
Legacy rationalization is often deferred because the pain is distributed and the ROI is invisible -- until it isn't. Consolidating Xebra dependencies didn't just reduce defects; it made the platform auditable, trustworthy, and ready to scale. The 40% defect reduction was the visible outcome. The invisible outcome was a platform that engineers could reason about and trust.
The Xebra platform would have continued accumulating technical debt, with each new feature requiring dual maintenance across two systems.
Data inconsistencies between the legacy and new platform would have compounded, making reliable reporting impossible.
The migration would have been forced eventually by a critical failure rather than executed strategically -- at significantly higher cost and risk.
I didn't fix bugs. I fixed the system that was creating them. The distinction matters because it changes the intervention: fixing bugs is reactive and infinite; fixing the system is proactive and finite. The key was convincing stakeholders that the investment in system alignment would pay off in reduced engineering overhead -- and then delivering that outcome.
"I wasn't fixing bugs -- I was eliminating the structural inconsistency that was generating them"
"Xebra and iSuite each had their own version of the user, and they disagreed constantly"
"The 40% defect reduction was the outcome. The real achievement was making the platform auditable."
What the data says
“Companies with structured onboarding experience a 63% year-over-year increase in customer satisfaction.”
Platform reliability is a prerequisite for structured onboarding. Defects in identity and access workflows directly degrade the onboarding experience -- the Xebra rationalization removed this class of degradation.
SourceWhite Paper Thread: The Decision Layer
The Xebra rationalization illustrates the white paper's argument about system coherence: that decision systems require a single source of truth. When two systems maintain conflicting state, every decision that depends on that state is potentially wrong. Rationalization is not a technical exercise -- it is the prerequisite for reliable decision-making at scale.
Read the White Paper →Connective Tissue
The identity decision system and the Xebra rationalization were parallel workstreams. The identity layer required consistent state across systems; the rationalization delivered that consistency.
Read case study
The payment portal required aligned billing workflows in iSuite. The Xebra rationalization was the prerequisite -- without consistent financial state, the direct payment model would have created reconciliation failures.
Read case study
Both cases address the same architectural problem: fragmented data sources that prevent reliable, scalable operations. Xebra rationalization addressed internal system fragmentation; PromoStandards addressed external vendor fragmentation.
Read case study
See the prototype built from this experience
This work informed a real product
The Operating System
ibuildsystems.io
Four frameworks. One repeatable system. Applied across banking, fintech, government, and B2B SaaS to turn broken workflows into scalable revenue engines.