BILL
End-to-End Platform Modernization
BILL's top FY26 priority is modernizing an 18-year-old product ecosystem held back by legacy tech, fragmented UX, and slow delivery.
BILL's top FY26 priority is modernizing an 18-year-old product ecosystem held back by legacy tech, fragmented UX, and slow delivery.
Overview
BILL’s product had been built over nearly two decades, and it showed. What looked like inconsistency on the surface was really a deeper systems problem underneath: multiple frameworks, isolated repos, competing component libraries, and years of local decisions that never added up to one coherent product experience.
By FY26, the cost of that fragmentation was obvious. The product felt dated. Rollouts were slow and fragile. Page performance lagged. Teams were solving similar problems in completely different ways, and customers could feel the seams.
Modernization became the company’s attempt to fix that without doing a full rebuild. As design lead, my job was to help define the modern standard, drive adoption of the platform, and build the process and quality bar needed to scale that change across the product.
The problem(s)
Deeply fragmented UX, legacy architecture, slow delivery, poor performance, and eroding customer trust.
My role
Design Lead
The mod squad
3 Directors, 3 Leads, 2 Data Scientists, 1 Project Manager
“I feel like I have to apologize for BILL… It looks very sort of WEB 1.0, enterprise-y. It doesn't look like modern software.”
-Top AC console user
Constraints
BILL leadership was not open to invest in a 0-1 redesign of the product using ai-native workflows.
BILL's internal Trinity Design system had to be used as the proprietary platform driving modernization.
The company is not willing to commit to a single engineering framework.
Resourcing, staffing, and roadmap planning had to be extremely calculated.
Leadership dictated that engineering orgs were greenlit to migrate without design references.
Modernization Strategy
The initiative only worked because modernization was framed as experience, system, and platform consolidation happening in parallel, rather than as isolated fixes.
Ratification of core IA experiences was critical to establish the standard to evolve to. The Trinity Template Library was leveraged as the sublevel workstream to accomplish this.
Used modernization as the leadership-backed forcing function to migrate 63 squads on to a single system and deprecate independent libraries that were fragmenting the experience for our end users.
5→1
Design system migration
The web platform team used Modernization as the opportunity to consolidate the 7 NG repos that were shipping the BILL experience into a single mono repo architecture for more robust rollouts, improve performance, and enforce org-level QA processes.
7→1
Repos consolidated
Workstream 01
In order to migrate the entire product to a unified experience, we first needed to identify what that north star vision of that experience was. The work to do so involved months of deep org-wide collaboration and research that you can learn more about in detail in the Trinity Template Library case study.
By defining the core UX architecture and establishing that through pattern level components, we were laying the groundwork for a consistent and predictable experience that could be propagated at scale throughout the product by way of incremental adoption.
The foundational layout for all primary product views. Defines the relationship between the UI shell, page header, and canvas content area.
Data grid is the cornerstone of the BILL product experience. Structures dense tabular data with inline actions, sorting, filtering, and pagination.
A popover container to serve single or multistep workflows that guide users through tasks like creating payments, onboarding, or completing approvals.
Contextual overlays that slide in from the right to show detail views, edit forms, or secondary workflows without losing page context.
Focused interruption for confirmations, destructive actions, or compact task completion that demands user attention.
Workstream 02
A cornerstone of the modernization initiative is the enterprise-wide migration to the platform design system — deprecating four legacy component libraries and unifying thousands of component tags under a single, governed architecture. This is an ongoing effort targeting 100% adoption by end of FY26, with the core repo already showing significant traction as shown in the adoption curve. Massive shoutout to staff lead engineer Daniel Tupa and design systems architect David Cai for building the component migration pipeline with Copilot and scaling it across all squads.
Deprecating 4 libraries
BDC
Legacy BILL component library
Web Components
Framework-agnostic custom elements
Angular Material
Third-party component library
Hardcoded Custom
One-off inline implementations
Trinity Angular
Unified design system — single source of truth
Adoption over time — Core repo
Workstream 03
One of the biggest political opportunities that Modernization presented was escalating the consolidation BILL's isolated Angular repositories into a single monorepo as a dependency for Modernization as a program. Each repo carried its own build process, library versions, test suites, and deployment pipelines — creating significant bottlenecks in development velocity, deployment stability, and page performance. Repo migration has had exponential impact on performance and deployment.
Outcomes
Modernization created measurable progress across system adoption, delivery speed, page performance, and cross-product UX quality, all while de-risking how the company ships change.
93%
Adoption up from 12%
On to the unified platform design system
50%
Faster Delivery
Reduction in average development cycle times ranged from 30%-50% for adopting teams of new platform infrastructure.
44%
Faster LCP
Average improvement across top 10 traffic pages
The most important outcome was not any one percentage point. It was that the product began to behave more like a coordinated platform and less like a portfolio of isolated histories. That showed up in how teams shipped, how pages loaded, and how customers perceived overall quality.
The adoption curve also mattered strategically. Moving from roughly 12% to 63% meant the company finally had enough shared infrastructure to make consistency and speed feel compounding rather than aspirational.
We were not just delivering a visual refresh. We were changing the cost structure of product development: fewer duplicate systems to maintain, fewer bespoke decisions to make, and a stronger shared bar for quality before release.
That is what made the initiative feel like modernization instead of migration. The product got better for customers, and the organization got better at making the product.
Reflections
The strongest choice we made was framing modernization as one strategic program instead of splitting UX, system adoption, performance, and engineering quality into separate initiatives. That alignment gave the work leverage.
Once customers, PMs, designers, and engineers could all see their problem in the same modernization story, prioritization became much easier.
Incremental modernization is inherently less elegant than a rebuild. Legacy realities, framework divergence, and active roadmap pressure constantly push against ideal architectural choices.
A large part of the work was managing those compromises without letting the initiative collapse back into local optimization.
The deepest lesson was that modernization succeeds when customer trust, system adoption, visual refresh, and engineering velocity are treated as one problem. Separating them may simplify org charts, but it weakens outcomes.
The design lead role in a program like this is not just craft stewardship. It is strategic integration: keeping the whole platform pointed at a more coherent future.
