Kubex turns a wall of numbers into clear next steps with Claude

Client

Kubex is redefining how Kubernetes and cloud resources should be managed, with a mission to make Kubernetes, GPU, and AI infrastructure more efficient, automated, and sustainable. Formerly Densify, it develops technology that automates resource optimization across Kubernetes, AI infrastructure, and cloud environments by combining deep analytics, verticalized AI, and governed automation. A single optimization engine spans containers, nodes, GPUs, and cloud instances, rightsizing workloads, reducing waste, and applying safe automation so SRE, platform, and FinOps teams can cut cost, improve performance, and spend less time on manual tuning. Trusted by large enterprises running demanding infrastructure, Kubex is built to fit existing stacks rather than force a new operating model.

Challenge

An autonomous Kubernetes and AI optimization platform is only worth having if people can act on it. Kubex collects cost, utilization, saturation, risk and automation data across clusters, node groups, namespaces and containers (at enterprise scale, that can mean hundreds of thousands of containers across dozens of clusters) and it showed nearly all of it at once. Power users coped. Everyone else opened the dashboard and could not tell where to start.

Approach

Working in close partnership with GoodLabs, the Kubex team developed the design strategy using Claude Cowork: user problems mapped, design principles set, navigation architecture defined, and detailed specifications written for each screen. Those specifications went into Claude Design, producing high-fidelity designs across 27 screens, reviewed and refined throughout with the GoodLabs team.

GoodLabs built on that foundation. We designed in the open, with stakeholders and users reviewing from the first week. Changes were cheap because nothing had hardened into code yet.
Taking the Claude Design screens as our brief, we built standalone HTML prototypes, including A/B versions of the same screens and components. The expensive questions got settled in days, with no build step and no architecture in the way.
We turned the winning prototypes into a design system: components, a colour palette and reference screens, all documented in Storybook. One rule kept it clean. Nothing in the library fetches data, so adopting it was a presentation swap rather than a rewrite.
Then we rebuilt the existing pages on it, replacing the old components with the new ones and flagging any design that needed new data behind it before it could ship.
Several rounds of review followed, shipped in phases. Each phase applied progressive disclosure so the information arrived in digestible layers, and fixed navigation, labelling and drill-through as it went.

Before

A wall of numbers that rewarded power users who knew what to look for, but left everyone else without a clear place to start.

After

Clear calls to action, captions that say what each KPI means, and a navbar that is easier to scan.

Result

• 12% of new users now act on a recommendation in their first session, up from 5% before the redesign.

• In the first 7 days after launch, customers approved 57 Claude-generated optimization proposals in the product, reclaiming 12.7K CPU cores and 36.1 TB of memory and saving $263K in that week alone.

• Redesign delivered in 6 weeks, against a 12-week estimate.

• One design language across the app: 94 components and 249 tokens replaced one-off styling on every screen.

• A wall of numbers became six intent-first cards: Reduce Waste, Eliminate Risk, Optimize GPUs, Manage Automation, Track Your Impact, and Know What To Do. Each answers one question with one figure.

• Kubex now ships with a point of view. The product knows what good looks like, shows it out of the box, and tells users what to act on first, with six ready-made boards, each with a sensible time window and all still configurable.

• Every number leads somewhere. Rows and counts link into the explorer at the scope the user was reading, and Claude's proposals can be reviewed as a diff and approved in the product, without a spreadsheet or a ticket.

• Delivered in reviewable phases instead of one large merge.