Six months ago we stood in front of product and executive leadership and asked for time to build a new web platform. Our frontend was like an archaeological site. Four design systems layered on top of each other like strata, each one added with good intentions, none fully removed. Dig into any component and you weren’t sure what design system you’d hit. Three different state management technologies from three different eras of React thinking. Cross-feature work meant tying together technologies that were never meant to work together. Pages took too long to load and weren’t reactive. Our head of sales told us we’d lost two million dollars in deals over the past year because of the UI.
It was too much to fix incrementally. We needed to start fresh. Nobody wanted to hear the word “rewrite” but we needed a new web platform.
We got the green light (twice). The team came up with and executed an ambitious plan. Three months later we entered private preview with paying customers. Five months later we launched public preview to every customer. Here’s what we learned.
Tech debt suppresses innovation you can’t measure
The obvious cost of our legacy frontend was slow load times and an outdated UI. But the real cost was harder to see.
Explorer is where most of our customers spend their time. It’s the most important page in the product. And our engineers were reluctant to touch it at every turn. Nobody rejected features. Nobody seriously proposed them either. Side-by-side comparison. Showing usage alongside cost. Multi-dimensional grouping. These weren’t hard ideas. They were feature requests that quietly died because of fear of the complexity underneath. You’d propose something and someone would say “well, we’d really need to update the data layer first, and that’s precariously perched on our bootstrapping and nobody’s going to give us the time for that,” and the conversation would wind down until the idea was dead. It wasn’t a “no.” It was a slow suffocation.
That’s the thing about tech debt at this scale. Your inability to do something becomes tribal knowledge. It’s not a decision anyone makes. People just stop imagining what’s possible.
We’ve already shipped Usage data and multi-dimensional grouping in the new platform.
Let the team write the plan
Our frontend engineers had been agitating for a chance at this for a while. What they needed was help framing it in business terms. What does the company get if we go off and do this? How does it connect to deals, to velocity, to the roadmap?
Once we had that framing, we got the green light, but not to build. To plan. The team got several days of self-guided discovery to evaluate technologies, make decisions, and build a detailed timeline. They picked the stack. They estimated the work. They designed the migration path. All self-led by the engineers who would actually be doing it.
Letting the team write the plan doesn’t mean carte blanche. We still aligned on scope and milestones together. The first plan connected CzNext to Classic with shared navigation. I pushed to drop it. We were a small team, and smooth navigation between the two platforms meant retrofitting Classic — investing engineering time in the exact codebase we were trying to leave behind.
When you write your own plan, you own the outcome. You’re bought in. You understand the tradeoffs because you made them, and you want to see the plan through. Executive product leadership approved the plan, and the team executed it on time.
Top-down can fail because the people doing the work don’t believe in the plan. Let them write it.
Lift and shift is a strategy, not a compromise
This was the hardest discipline of the entire project. When you’re rewriting everything, the temptation to improve everything is almost unbearable. Every component you pick up and move to the new platform, you can see exactly what’s wrong with it. Our design team didn’t design the original. Product had a wish list. Internal stakeholders had opinions. Budgets, connections, telemetry, everyone had something they wanted reimagined.
We said no. Repeatedly. The platform was the deliverable. Get on the new tech stack, get on the single design system, get the performance wins. That’s the project. If we started redesigning every feature we touched, scope would have ballooned by an order of magnitude and we never would have shipped.
The temptation was strongest in the beginning. Multiple times a week someone would look at a component and say “we can’t just pick it up and move it like this.” But once we established the discipline, it got easier. The team internalized that we must get on the new platform so we can build great stuff on it. In that order. Not the other way around.
The fact that the new platform shipped with a few new features and immediately looked better was almost a bonus. We now have a modern foundation to innovate on instead of fighting our own codebase. That’s what CzNext was always supposed to unlock.
Put customers in the build, not after it
Customers saw early mockups and prototypes as far back as re:Invent in December, before a line of migration code was written. Our head of customer success held a customer advisory board where customers told us what they most wanted to see. Dark mode came up as a top request. So early on, CzNext had dark mode baked in.
Dark mode was embarrassingly difficult on the old platform. Multiple design systems, inconsistent theming, no single source of truth. On the new platform with a single design system, it was straightforward.
From there, our product manager spearheaded a structured design partner program. Ten customers in phase one. Open, direct feedback, no playing telephone. More customers requesting access every week. Something magical happens when you open the lines of communication and get into tight feedback cycles with your actual customers. The product gets sharper faster than any internal review process could make it. By the time we hit public preview we’d been through dozens of customer sessions and real users shaped the product around what they actually needed, not what we assumed they’d want.
A clean codebase is an AI multiplier
It wasn’t an explicit goal when we started, but the new platform turned out to be exactly the kind of codebase AI thrives in. Single design system, single state management approach, standard patterns, clear component boundaries, single responsibilities. When you describe a change clearly, AI can one-shot it correctly because the codebase is consistent enough for it to reason about.
Our frontend team is now leading the company in AI-fueled productivity, not because of any top-down mandate, but because they’re getting exceptional value out of it. They’ve built their own tooling for local development to manage multiple worktrees each with its own local UI instance. They’re creating custom AI skills and workflows.
The proof is in the numbers. Merged pull requests on the new platform: 75 in December, 124 in January, 102 in February, 196 in March, 243 in April. More than 3x in five months, and that’s with one engineer out on paternity leave and the team starting to split focus to other projects.
Great design doesn’t have to cost you the timeline
This one surprised me. We scoped this as a platform migration. Get on the new stack, lift and shift the features, ship it. But we had a talented designer on the team, and what could have been a purely functional migration became something customers actually enjoy using.
It didn’t blow up the timeline, but it wasn’t free either. The overhead was coordination. Keeping design and engineering moving together, making sure design work reached the right engineers at the right time. Sometimes design led and engineers built to spec. Sometimes engineers went first with a straw man and took feedback. The team stayed flexible to keep the project moving. And a strong design system actually reduces decisions during the build. You’re rewriting every component anyway, and making them look good on top of making them work doesn’t add much time.
Customers noticed. “It looks very modern… a really good step in the right direction.” Body language leaning forward in demos. We went from a UI that cost us deals to one that helps close them.
The results
The numbers back it up:
- Pages load 28-61% faster, content appears in under 2 seconds
- JavaScript execution is 85% faster (57ms vs 369ms), clicks, filters, and interactions respond almost instantly
- Warm load times are 14-77% faster
- Public preview launched to all customers on April 30, 2026, five months after the project started
What this was always about
CzNext wasn’t about dark mode or faster load times, as much as customers love both. It was about building a foundation we can innovate on.
We now have a modern foundation to innovate on instead of fighting our own codebase. This is what CzNext was always supposed to unlock, and it’s just in time to go win the battle over AI cost management.