CTO's Guide to SDUI: Buy vs Build in 2026

The mobile dev tools market hit $19.9 billion in 2026. A big piece of that growth is server-driven UI (SDUI) — the architecture that lets you update native mobile screens from your server without app store review.

Airbnb built it. DoorDash built it. Lyft built it. Nubank built it and now powers 43% of their app across 115 million customers. The pattern works.

But here's the question nobody answers honestly: should your team build it?

For most companies, the answer is no. This guide will help you figure out which side of that line you're on.

Why CTOs Are Looking at SDUI Now

Three forces are converging to make SDUI a boardroom-level conversation:

1. Release velocity is a competitive advantage. Your web team ships multiple times a day. Your mobile team ships every two weeks — if they're fast. That gap is no longer acceptable. When slow mobile releases cost you missed experiments, delayed revenue, and frustrated PMs, leadership starts asking hard questions.

2. Remote config hit its ceiling. Feature flags and remote config solve the easy problems — toggling features, changing copy. But they can't restructure a screen, swap a component, or rearrange an entire flow. CTOs who've maxed out LaunchDarkly and Firebase Remote Config are looking for the next step.

3. A/B testing on mobile is still painful. Every experiment requires a code change, a build, a release, and a wait. SDUI makes mobile experimentation as fast as web: change the server response, target a cohort, measure. The business case for SDUI increasingly starts here.

The 3 Options on the Table

If you've decided SDUI makes sense for your product, you have three paths:

Option 1: Build In-House

This is what Airbnb (Ghost Platform), DoorDash (Mosaic), and Lyft (Canvas) did. You design a schema, build rendering engines for each platform, create backend tooling, and maintain it all yourself. Total control. Total cost.

Option 2: Adopt Open Source

Use an existing framework like RemoteCompose (Google's AndroidX SDUI library), DivKit (Yandex), or Stac (Flutter). Free to start, but you still own integration, tooling, and maintenance. And each has real limitations — RemoteCompose is Android-only, DivKit has a steep learning curve, Stac only works with Flutter.

Option 3: Buy a Platform

Use a managed SDUI platform like Pyramid or Nativeblocks. You get the rendering SDK, visual builder, backend infrastructure, and cross-platform support out of the box. Fastest path to production, but you're taking a vendor dependency.

The SDUI frameworks comparison covers the technical details of every option. This article focuses on the business decision.

The True Cost of Building SDUI In-House

This is where most CTOs underestimate. "We'll just build a simple renderer" quickly turns into a multi-year platform project. Here's what the actual investment looks like:

But the dollar cost is only half the story. The opportunity cost is what kills most teams.

Those 2–4 senior mobile engineers spending 6–12 months on internal SDUI infrastructure? They're not building product features. They're not reducing tech debt. They're not shipping the things your customers actually asked for.

And SDUI is never "done." Schema versioning, new component types, architecture pattern evolution, platform OS updates (every September, like clockwork), performance optimization — this is a permanent line item on your engineering budget.

"SDUI is incredibly powerful when launched, but migrations to SDUI are tough in my experience. Without strong tooling or a dedicated team to support platform changes & improvements, it might not be worth the complexity for small teams."

— Ryan Brooks, Airbnb (Android Platform Engineer)

Use our Build vs Buy Calculator to model these numbers for your specific team size and salary costs.

Decision Matrix: Build vs Open Source vs Platform

Here's how the three options compare across the criteria that matter most to engineering leaders:

Criteria	Build In-House	Open Source	Platform (Pyramid)
Time to production	6–12 months	3–6 months	2–4 weeks
Upfront cost	$300K–$1M	$50K–$150K (integration)	$99–$499/mo
Annual maintenance	$150K–$400K/yr	$75K–$200K/yr	Included
iOS + Android support	You build both	Varies by framework	Both included
Visual editor / tooling	You build it (or don't)	None / limited	Included
A/B experimentation	You build it	Not included	Built-in
Customization depth	Unlimited	Framework-limited	Extensible via custom components
Vendor independence	Full ownership	Open source	Vendor dependency

The pattern is clear: build gives you control, platforms give you speed, open source gives you something in between (with its own trade-offs). The right choice depends on where your team falls on the control-vs-speed spectrum.

When to Build In-House

Building SDUI yourself makes sense when all of these are true:

• You're a top-50 app with the engineering budget to match. DoorDash, Airbnb, and Lyft built custom SDUI because they had hundreds of mobile engineers and billions of sessions to optimize.
• SDUI is core IP. Your competitive advantage comes from how you render and personalize UI. It's not infrastructure — it's the product.
• You have 20+ mobile developers. At this scale, the per-engineer cost of a platform is trivial, and you can afford a dedicated platform team to maintain it.
• You need deep integration with proprietary systems (custom design systems, internal experimentation platforms, proprietary data pipelines) that no vendor can accommodate.

If that's you, start with the SDUI migration guide and the architecture patterns for production systems.

When to Buy a Platform

A platform is the right call when:

• Your mobile team is 3–20 developers. You can't afford to pull 2–4 senior engineers off product work for 6+ months. The ROI calculation is overwhelmingly in favor of buying.
• Speed matters more than control. If you need SDUI in production in weeks (not months), a platform gets you there. The adoption playbook covers how to start with a single screen and expand.
• SDUI isn't your competitive advantage. You're a fintech, e-commerce, or SaaS company. Your product is what you sell, not how you render it. SDUI is infrastructure — buy it like you buy cloud hosting.
• You want non-engineers involved. PMs and designers can update screens directly through a visual builder, without filing tickets and waiting for the next sprint.

For mid-size teams, the math is brutal: a platform at $99–$499/month costs less than a single engineer-day per month, while a custom build costs $300K+ and takes half a year. That's 10–50x ROI before you factor in opportunity cost.

10 Questions to Ask Any SDUI Vendor

If you go the platform route, here's what to evaluate. These questions separate serious platforms from prototypes:

1. Does it render truly native components? — Not WebViews, not canvas drawing. Native SwiftUI and Jetpack Compose views that integrate with your existing design system.
2. How does it handle schema versioning? — When you add new component types, do old app versions gracefully degrade? Or do they crash?
3. What's the offline story? — Can screens be cached? What happens when the network is down? A blank screen is unacceptable.
4. Can you register custom components? — You'll need to use your own design system components, not just the vendor's built-in ones.
5. How does experimentation work? — Can you A/B test at the component level? Screen level? Can you target by user segment?
6. What's the performance overhead? — Ask for benchmarks. JSON parsing, rendering latency, memory footprint. Compare to native baseline.
7. How do you handle actions and navigation? — Deep links, API calls, analytics events. SDUI without an action system is a static brochure.
8. What does the migration path look like? — Can you start with one screen and expand gradually? Or is it all-or-nothing?
9. What's the exit strategy? — If you leave the platform, what happens? Can you export your screen definitions? Are the SDKs open source?
10. Who's using it in production? — Ask for case studies, reference customers, and production traffic numbers. SDUI at scale is hard — make sure they've done it.

Frequently Asked Questions

How much does it cost to build SDUI in-house?

Expect $300K–$1M upfront (2–4 senior engineers for 6–12 months) plus $150K–$400K per year in maintenance. This covers the rendering engine, schema layer, versioning, and cross-platform support. Add $100K–$300K if you want visual tooling for non-engineers. Model your specific costs with our Build vs Buy Calculator.

When should a company build SDUI in-house?

Build when you're a top-50 app with 20+ mobile developers, SDUI is core intellectual property, and you need deep integration with proprietary systems. Companies like Airbnb, DoorDash, and Lyft fall here. If any of those conditions aren't true, a platform likely gives you better ROI.

What open-source SDUI frameworks are available?

The main options in 2026: RemoteCompose (Google, Android-only), DivKit (Yandex, cross-platform but steep learning curve), and Stac (Flutter-specific). See the full framework comparison for details on each.

What ROI can mid-size teams expect from a platform?

Teams with 5–20 mobile developers typically see 10–50x ROI from a platform versus building in-house. A platform like Pyramid at $99–$499/month costs less than a single engineer-day, while a custom build runs $300K+ upfront. Use the ROI Calculator to model your specific scenario.

The Bottom Line

Server-driven UI is no longer experimental. The architecture is proven, the case studies are real, and the business value is measurable.

The only question is whether you should allocate $300K+ of engineering time to build infrastructure that isn't your product, or spend 0.1% of that on a platform and put those engineers back on features your customers pay for.

For DoorDash-sized companies with 200+ mobile engineers, building makes sense. For the other 99% of mobile teams, it doesn't.

Know where you stand. Choose accordingly.