Agentic Design at Scale

A spec can say a gradient should feel premium. It can't tell you whether that gradient bands on a three-year-old Android screen, and it can't tell you how much of a phone's display a mobile browser's own chrome will eat before your layout even starts — not until something is actually running on the device.

For the Bibel TV app redesign, iOS and Android, I'm also product manager and product owner alongside Head of Product Design — the redesign is the reason the current contract exists, which meant I didn't need anyone else's sign-off to change how we were building it. I still start in Figma: layout, flow, hierarchy, the concept work. Writing a spec after that would hand engineering, an external agency, a document instead of an answer, and leave the interaction states and the actual rendering as things to discover later, once a build finally exists to discover them in.

So I prototype it myself, in Claude Code, against real data. That alone caught issues and edge cases Figma never would have shown me, the kind that only exist once content is actually rendering.

The web prototype ran first, and it ran into two real problems. Mobile browsers eat a chunk of the screen with their own chrome before a design even starts, and the visual language I was building leans on gradients — which someone had flagged a genuine worry about: older Android screens, which is where most of our users actually are, tend to band on that kind of gradient. So I kept building the same prototype, but continued it as a native Android app in Kotlin and Jetpack Compose, the only way to see the rendering the way those screens would actually show it.

Where the production API didn't have what I needed yet, I stood up a custom API myself rather than fall back on placeholder content. A prototype running on fake data isn't worth much. Both versions let me put a working app in front of users and stakeholders in a session, not walk them through static screens.

Engineering, Jannis and Timo at appbase, the agency Bibel TV works with, doesn't get a spec from any of this. They get a build that already runs, and they decide what to keep, what to change, and what to rebuild native for performance. As implementation continues, a teardown of the shipped Android build measured how much of the token and data-model layer survived — 91.8% of the design-token fields and 94% of the core Kotlin data model, verified field by field. Separately, Jannis at appbase has told me directly that engineering is able to reuse a lot, if not the majority, of the code overall — his own estimate, not something I've measured myself. Engineering ships from code I wrote, and that engineering sits outside my own company entirely.

Engineering still makes the call. I don't force-ship what I build — the agency reviews it and decides to keep it, change it, or start over. That's not a formality; it's what keeps a designer's prototype from becoming an unreviewed dependency in someone else's codebase.

What carries best is exactly what a spec is worst at: interaction and state, the parts of an app you can only really judge by using them. What doesn't automatically carry is platform-native polish. Some of what I build gets rebuilt native once engineering picks it up, for performance rather than correctness, and that's not a failure of the approach. It's engineering doing the part of the job that's actually theirs.