The Journey to Server Driven UI At Lyft Bikes and Scooters
Article Summary
Lyft Bikes & Scooters was drowning in complexity: 3 vehicle types, multiple markets, and endless switch statements. Their solution? Move the UI logic to the server.
Alex Hartwell and Tim Miko from Lyft's Bikes & Scooters team share their multi-year journey from hardcoded mobile apps to a flexible Server Driven UI architecture. They evolved from simple database models to a sophisticated BFF (backend for frontend) that handles all their product variations.
Key Takeaways
- Started with Server Supplemented UI using boolean flags and configuration
- Built two component types: Declarative (like HTML) and Semantic (client-driven)
- Actions decouple layout from behavior, enabling reuse without app releases
- New features now expand the platform, making future work faster
- Shared SDUI primitives across Lyft teams to avoid duplicate solutions
SDUI shifted business logic from client to server, enabling Lyft to ship new markets and features without app updates while managing massive product complexity.
About This Article
Lyft Bikes & Scooters had a monolithic business model that mixed UI concerns with hardware properties. Mobile engineers had to maintain hacky mappings across three docking configurations: fully docked, fully dockless, and hybrid. There were no standardized abstractions to work with.
Alex Hartwell and Tim Miko built a dedicated BFF microservice called lbsbff. It uses protobuf to return view representations instead of business models. They established atomic Components and Actions as reusable primitives that separate layout from behavior.
Feature teams could now experiment independently while using shared SDUI patterns. Configuration changes replaced code changes. Many product variations no longer required simultaneous iOS and Android releases.