How Nubank Uses Server-Driven UI to Ship Features to 115 Million Customers in Minutes

Nubank is one of the world's largest digital banks — 115 million customers across Brazil, Mexico, and Colombia. Their mobile app sees 40 million daily active users with peaks of 3,000 app opens per second across 20,000 different device types.

In March 2026, Rafael Ring (a principal engineer at Nubank) gave a detailed talk at InfoQ breaking down how Nubank built and evolved their server-driven UI framework — from simple templates to a full tree-walk interpreter. It's one of the most comprehensive public accounts of SDUI at massive scale.

What Nubank built validates everything the industry has been converging on: that server-driven UI isn't a niche pattern, but the same architectural choice made by companies like Airbnb, Lyft, and Netflix. The difference is the scale — and the cost of building it yourself.

The Problem That Made Nubank Build Their Own SDUI Framework

With over 3,000 engineers contributing to the same mobile codebase, Nubank hit every pain point that growing mobile teams face — just at a much larger scale:

Single Binary Packaging

Every team's code gets bundled into one app binary. This means PRs conflict, dependencies break, and release queues back up. When thousands of engineers are pushing changes to the same binary, coordination becomes the bottleneck — not coding.

Brutal Lead Times

Even with weekly release cycles — which is fast for mobile — it takes 4-5 weeks for a change to reach 85% of users. Find a bug? That's another 4+ weeks minimum to ship the fix.

— Rafael Ring, "Mobile Server-Driven UI at Scale", InfoQ March 2026

Think about that: 4-5 weeks from "code merged" to "most users see it." And that's with a weekly release cadence that most mobile teams would consider aggressive. The bottleneck isn't development speed — it's the app store review process and the reality that users don't update their apps immediately.

Regulatory Pressure

As a financial services company operating across Brazil, Mexico, and Colombia, Nubank faces regulatory requirements that can demand immediate UI changes. When a regulator says "add this disclosure to the transfer screen by Friday," waiting 4-5 weeks isn't an option — it's a compliance violation.

The Four Generations of SDUI at Nubank

Nubank didn't jump straight to their current architecture. Their SDUI framework evolved through four distinct generations, each solving problems the previous one couldn't handle. Understanding this evolution is valuable for any team planning their own SDUI adoption.

The key insight from Nubank's evolution: each generation emerged from hitting the limitations of the previous one. Templates were great until product needed a layout that didn't exist. Components were great until product needed conditional logic. Each upgrade expanded the expressiveness of what the server could control.

How Catalyst Works: A Tree-Walk Interpreter in Flutter

Catalyst is Nubank's fourth-generation SDUI framework — and it's significantly more ambitious than what most companies build. Rather than just mapping server-defined component trees to native widgets, Catalyst is a full tree-walk interpreter.

What Makes Catalyst Different

Most SDUI frameworks (including what companies like JobKorea built) operate at the component level: the server says "render a carousel here with these properties," and the client renders a pre-built carousel component. This is Generation 3 in Nubank's taxonomy.

Catalyst goes further. It can:

• Execute conditional logic — show different UI based on user data, account state, or feature flags, all without updating the app
• Handle dynamic behavior — respond to user interactions with server-defined logic paths
• Compose arbitrary layouts — the server defines not just which components to render, but how they relate to each other structurally
• Manage state transitions — navigate between screens, update local state, trigger animations based on server-defined rules

Conceptual Catalyst Component Tree (Simplified)

{
  "type": "screen",
  "children": [
    {
      "type": "conditional",
      "condition": "user.accountAge < 30",
      "then": {
        "type": "onboarding-banner",
        "props": {
          "title": "Welcome to Nubank!",
          "subtitle": "Complete your profile to unlock all features",
          "action": { "type": "navigate", "target": "/onboarding" }
        }
      },
      "else": {
        "type": "balance-summary",
        "props": { "showInvestments": true }
      }
    },
    {
      "type": "section-list",
      "children": [
        {
          "type": "transaction-feed",
          "props": { "limit": 5, "showFilters": true }
        },
        {
          "type": "product-carousel",
          "props": {
            "products": ["credit-card", "savings", "insurance"],
            "layout": "horizontal-scroll"
          }
        }
      ]
    }
  ]
}

Notice the conditional node — this isn't just rendering components, it's executing logic. A new user sees an onboarding banner; an established user sees their balance. This decision happens at render time based on the server-defined tree, without any client-side branching code.

Why Flutter?

Nubank chose Flutter as their mobile platform, which gives them a single codebase for iOS and Android. Building Catalyst on top of Flutter means their SDUI interpreter only needs to exist once — not separately for iOS and Android. This is a significant advantage over companies that need to maintain parallel SDUI renderers in Swift and Kotlin.

The Component Tree Architecture

At a high level, Catalyst works by:

1. Server sends a component tree — a JSON structure describing the UI hierarchy, including conditional logic, data bindings, and interaction handlers
2. Catalyst parses the tree — the interpreter walks the tree node by node, evaluating conditions, resolving data references, and determining which components to render
3. Flutter widgets are generated — each component node maps to a Flutter widget (or composition of widgets), creating a standard Flutter widget tree
4. Flutter renders natively — from here, Flutter's own rendering pipeline takes over, producing native iOS and Android UI

The result looks and feels completely native because it is native Flutter rendering. Users don't know or care that the screen they're looking at was assembled from a server-defined tree rather than compiled into the app binary.

The Results: 43% of the App, Minutes Not Weeks

After years of investment and four generations of evolution, here's where Nubank stands:

The trajectory is telling: 43% of the app today, but 70% of new development is server-driven. Nubank is clearly converging on SDUI as the default way to build mobile UI. The 57% that's still traditional will likely shrink over time as screens get rebuilt or replaced.

Speed Comparison: Before and After

Scenario	Traditional Release	With Catalyst (SDUI)
New feature rollout	4-5 weeks to 85% adoption	Minutes to 100% of users
Bug fix deployment	4+ weeks minimum	Immediate hotfix
A/B test launch	Requires app release per variant	Server-side, instant activation
Regulatory UI change	Emergency release + review	Same-day deployment
Home screen redesign	Full dev cycle + release	Server config update

The Organizational Investment

Here's the part that doesn't get enough attention: Nubank didn't just build a framework. They built an entire organizational structure around it.

According to Rafael Ring's talk, Nubank's SDUI effort involves:

• A dedicated platform team — engineers whose full-time job is maintaining and evolving Catalyst
• Internal developer advocates — people who help product teams adopt SDUI for their features
• Monthly "mob sessions" — collaborative coding sessions where teams learn Catalyst patterns together
• Extensive internal documentation — tutorials, best practices, component catalogs, migration guides
• Custom tooling — preview environments, debugging tools, performance monitoring specifically for SDUI

This is a significant investment. Nubank can justify it because they have 3,000+ engineers and 115 million customers — the math works at that scale. The platform team's cost is a rounding error compared to the velocity gains across thousands of engineers.

What 3,000 Engineers Need That 30 Don't

Much of Nubank's organizational overhead exists because of their scale. When 3,000 engineers need to use a framework:

• You need dedicated advocates to onboard new teams
• You need extensive docs because you can't just walk over and ask
• You need mob sessions because institutional knowledge doesn't spread naturally across 100+ teams
• You need custom tooling because generic solutions don't handle 3,000 contributors

A team of 10-50 engineers doesn't need most of this infrastructure. What they do need is the core capability: the ability to define UI on the server and render it natively on the client, with experimentation and instant updates. That's the kernel of value — and it's exactly what a managed platform can provide without the organizational overhead.

What We Can Learn from Nubank

1. SDUI at Scale Is Proven — Not Experimental

When a company running 43% of a 115-million-user app on SDUI calls it a success, the "is SDUI production-ready?" question is settled. This isn't a proof of concept. It's battle-tested infrastructure serving one of the largest digital banks in the world.

2. The Pain Points Are Universal

Single binary packaging, slow lead times, inability to iterate quickly — these aren't Nubank-specific problems. Every mobile team hits these walls. Nubank just hit them harder because of their scale. If you have 10 engineers instead of 3,000, the pain is still real — it's just proportionally smaller. Your 2-week release cycle still means 2 weeks of latency for every change.

3. Evolution Is Natural — Start Simple

Nubank didn't start with a tree-walk interpreter. They started with templates. Then components. Then scripting. Each generation solved the problems of the previous one. This is a critical lesson for teams considering SDUI: you don't need to build Catalyst on day one. Start with template-based or component-based SDUI, prove the value, then evolve as your needs grow.

4. The Framework Is the Easy Part

The real cost of Nubank's SDUI isn't the Catalyst codebase — it's the platform team, the documentation, the tooling, the developer advocacy, the monthly training sessions. These ongoing costs dwarf the initial build effort. Any team considering DIY SDUI should use the build vs. buy calculator and factor in at least 3x the initial build cost for ongoing maintenance and organizational support.

5. Financial Services Needs SDUI Most

Regulatory compliance, fraud response, disclosure requirements — financial apps face unique pressures that make instant UI updates not just convenient but legally necessary. If you're building a fintech app, SDUI isn't optional. It's a compliance strategy. Use the SDUI ROI calculator to see the impact for your specific situation.

How Pyramid Gives You This Without the Multi-Year Investment

Nubank built something remarkable — but they also spent years building it, with a dedicated platform team, across four generations of iteration. The investment was enormous.

Pyramid gives you the same core capability as a managed platform:

Capability	Nubank (DIY)	Pyramid
Build time	Years of iteration	Days to integrate
Team required	Dedicated platform team	Your existing mobile team
Platform	Flutter (custom interpreter)	Native Android (Compose) + iOS (SwiftUI)
Component trees	Custom tree-walk interpreter	Managed component rendering
Conditional logic	Custom scripting engine	Built-in targeting rules
Experimentation	Custom A/B framework	Built-in LiveValues
Component approach	Internal Flutter widgets	BYOC — use YOUR design system
Developer tooling	Built internally	Dashboard + preview included
Documentation	Internal wiki	Public docs + support
Ongoing maintenance	Full-time platform team	Managed — we handle it

The key difference: Nubank built Catalyst because in 2020-2021, no managed SDUI platform existed that could meet their needs. They had to build it. Today, you don't.

You shouldn't be building infrastructure — you should be building product. Let us handle the SDUI platform so your team can focus on what makes your app unique.

Frequently Asked Questions

What is Nubank's server-driven UI framework called?

Nubank's SDUI framework is called Catalyst, which evolved from their earlier system called Backend Driven Content (BDC). Catalyst is a tree-walk interpreter built in Flutter that renders component trees sent from the server. Unlike simpler SDUI frameworks that only map components to native widgets, Catalyst can execute conditional logic, manage state, and handle dynamic behavior — all defined server-side.

How much of Nubank's app uses server-driven UI?

43% of the Nubank app currently runs on server-driven UI via Catalyst, and approximately 70% of all new screens and flows are built using the framework. This means SDUI has become the default approach for new feature development at Nubank, and the proportion of the app that's server-driven is growing with every release.

How fast can Nubank ship UI changes with SDUI?

With Catalyst, Nubank can ship UI changes in minutes instead of the 4-5 weeks required for traditional app releases to reach 85% of users. This includes bug fixes, new features, A/B test variants, and regulatory compliance changes — all deployed instantly without app store review or waiting for users to update.

What SDUI generations did Nubank go through?

Nubank evolved through 4 generations of SDUI: (1) Traditional client-side rendering where every change required an app release, (2) Template-based SDUI with pre-built templates filled by server data, (3) Component-based SDUI where the server sends component trees that the client renders dynamically, and (4) Scripted SDUI (Catalyst) with a tree-walk interpreter that can execute logic, not just render components. Each generation expanded the expressiveness of what could be controlled from the server.

Sources: Mobile Server-Driven UI at Scale — InfoQ, March 2026 · Backend Driven Content: Server Driven UI Framework at Nubank