Prototyping in code, not in Figma specs
Prototyping the Bibel TV app redesign in real code, against real and self-built APIs, so an external engineering agency — not down the hall, outside the company entirely — evaluates something that already runs instead of a document that describes it.
The gap a spec can't close
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.
What I do instead
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.
Read the reasoning behind this decision
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.
Where this stands
The redesign itself hasn't launched, so this is about how it's getting built, not a consumer number yet. What's already verified: the design tokens and data contracts I prototyped are the ones running in production, confirmed by tearing down the shipped build field by field. Beyond that layer, engineering's own read, from Jannis directly, is that they're able to carry over a lot of what I hand them, if not the majority of it — his estimate, not something I've measured myself. Either way, what ships started as something I wrote and ran, reviewed and decided on by the agency rather than guessed from a document.
- What the agency evaluates
- A spec and redlines to interpret A working prototype, already running against real data
- Design-token and data-model fields verified in the shipped app
- 91.8% of token fields, 94% of the core Kotlin data model — confirmed via a teardown of the production build
- Broader code reuse, per engineering
- "A lot, if not the majority," per Jannis at appbase — his estimate, not a measured figure
Want the specifics?
- Curious why a mobile browser's own chrome was reason enough to rebuild a prototype natively in Kotlin, or exactly how much of what I hand engineering survives into the shipped app?