Backend-Driven UI · at ANNA Money

Portable product flows, native rendering.

A contract-first UI platform aligned backend producers, Android and Flutter without turning every product change into a coordinated app release.

ProtobufUniversal CardAndroid + FlutterCompatibility
Backend-Driven UI architecture visual
SpecialtyBackend-Driven UI
Formal role or capacityContractor · offer title: Android Developer
Personal scopeContract redesign, Android integration, and Universal Card co-development
SystemProtobuf IDL · JSON transport · native renderers

Flexibility increased the client change radius.

Low-level layout freedom and several chat payload families made each new composition more expensive to support consistently.

Before

Several payload families

Specialized cards and flexible primitives increased client mapping, rendering and compatibility work.

Target

A governed vocabulary

Constrained product semantics aligned with platform Design Systems while preserving native rendering.

The work crossed repository and team boundaries.

The contribution spans contract generations, client integration and the initial Universal Card change—not sole ownership of every service or renderer.

CONTRACT WORK

Schema evolution

  • Versioned contract generations
  • Generated platform models
  • Universal Card introduction
  • Compatibility governance
ANDROID

Native implementation

  • JSON deserialization
  • App-owned domain mapping
  • Compose/Tiger rendering
  • Native action handling
FLUTTER

Later implementation

  • Local generated schema mirror
  • Dart mapping
  • Barracuda presentation
  • Host action delegation

One vocabulary, independent implementations.

Protobuf defines the IDL and generated model boundary. Runtime paths deliver JSON; each client owns its mapping and presentation.

CONTRACT PROJECT

Versioned semantics

Pages, modals, forms, actions and chat payloads evolve explicitly.

→
PLATFORM MAPPER

Client-owned models

Android and Flutter isolate transport models from product presentation.

→
NATIVE RENDERER

Platform Design System

Compose/Tiger and Flutter/Barracuda render equivalent semantics independently.

Govern the change radius.

The platform is valuable because contract changes remain reviewable across generators, clients, fallbacks and host actions.

01

Use Protobuf as IDL, not a UI runtime

Generate typed models across platforms while keeping transport and rendering concerns explicit.

02

Constrain newer contract generations

Trade arbitrary layout freedom for predictability, portability and Design System alignment.

03

Introduce Universal Card as one payload family

Reduce bespoke chat templates without misrepresenting cards as the whole BDUI system.

04

Keep compatibility paths

Legacy and malformed payload fallbacks preserve product continuity during adoption.

05

Treat schema synchronization as governance

Flutter carries a local generated mirror; snapshot drift must remain visible and managed.

Universal Card is the concrete platform example.

A reusable composition model connects contract governance to visible product behaviour without exposing private schema details.

CARD ANATOMY

Header · body · footer

A constrained composition model covers context, status, content, carousels and actions.

RUNTIME BOUNDARY

Local state · host actions

Clients keep draft form state and execute navigation, requests and native actions through explicit boundaries.

A constrained contract that travelled across platforms.

Universal Card expanded from its initial chat use to Android, iOS, web, the agent administration interface, and later Flutter, while older payload paths remained supported during migration.

CHANGE RADIUS

One addition can touch generation, Android, Flutter, Design Systems, tests and release artifacts.

PRESERVED

Platform-native presentation, host ownership and compatibility fallbacks.

ADOPTION

Universal Card travelled across client and administration surfaces while older payloads remained supported.

Evidence & NDA boundaryThis case uses approved public visuals and a sanitised technical narrative. Private source, endpoints, credentials, configuration, customer data, and proprietary schemas are excluded.

Explore a role or project

Target role · Staff Mobile Engineer (Android + Flutter)
Worldwide remote · English / Russian
Novi Sad, Serbia · hybrid possible