A field report on the strangest bottleneck left in software — the app-store release cycle — and the Flutter engineer who decided interfaces should ship in seconds, then open-sourced the fix.
There is a button, somewhere in your company’s mobile app, that is wrong. The copy is stale, the colour is off-brand, or it points at a flow that stopped making sense two sprints ago. On the web, fixing it would be a deploy: minutes, an hour with review. In a mobile app it is a project: branch, fix, build, submit, wait out a store review measured in days, stage the rollout — and then hope, genuinely hope, that users bother to download the update at all. Multiply by two platforms. The industry has no name for this tax, so we will give it one: the two-week button.
The workarounds are a museum of partial credit. Feature flags that can only toggle what already shipped. A/B tools bolted to the side. Webviews smuggled into native screens, trading away the entire point of a native app for the ability to change it. Forced-update nags that users resent and ignore. Underneath them all sits the same structural fact: the interface is compiled into the binary, and the binary answers to a review queue in Cupertino or Mountain View. Whoever owns the binary owns your release calendar — and it has never been you.
This transmission is about an engineer who spent the better part of a decade teaching the Flutter ecosystem — essays since 2017, a Google Developer Expert badge, a meetup community spanning two emirates — and then co-founded the company that attacks the bottleneck at its root: move the interface out of the binary and onto the server, where it can change in seconds. Readers of this series will recognise the shape before we finish drawing it.
Divyanshu — first names are policy here; he can introduce himself properly — is a Flutter and Dart engineer based in Abu Dhabi, and one of the small number of engineers worldwide whom Google vets, and re-vets, as Developer Experts for the framework. The credential is earned in public. His essay archive — collected on his site, uncommit — runs back to 2017: Android tutorials first, then Flutter from its early days. Custom painters. Bézier-curve animations. The camera plugin. Dynamic theming. Code generation. Unglamorous, useful, precise — the kind of writing a framework’s community is actually built out of.
Read the archive in order and you can watch the judgment accrue. 2017: dialogs and chatbots on Android. 2019: animation internals, custom painters, the camera plugin. 2022: tooling and code generation — the concerns of somebody now responsible for other people’s velocity, not just his own. By January 2025 the essays stop describing how to build things inside the constraint and start describing the constraint itself. A decade of notes from the workshop floor, and then — the move this publication exists to document — the notes become a machine.
The other half of the profile is convening. Since 2022 he has organised the Flutter communities of Abu Dhabi and Dubai — the meetups where the region’s mobile teams compare notes, show work, and complain about the same things. Publish, teach, convene: it is the profile of somebody who gets told about every team’s wall, over and over, for years. And for years, every Flutter team he taught eventually hit the same one.
Here is the wall, and its special absurdity in Flutter. The framework’s signature feature is hot reload: change the code and see it on the device in under a second. Development runs at the speed of thought. Then the app ships, and the same one-line change takes two weeks to reach a user. The gap between those two numbers is the entire problem — a framework that made building instant, still shipping at the speed of 2008. His conclusion is the one this series keeps finding: the fix is not a better process. It is infrastructure.
Server-driven UI is the pattern the largest consumer apps built for themselves years ago, in-house and at great expense: define the interface as data on your server, and let the app render it natively at runtime. Change the data, and every user’s screen changes — instantly, with no rebuild, no review queue, no waiting for downloads. What the giants had, the average Flutter team did not. Stac is Divyanshu’s answer: an open-source, MIT-licensed, fully self-hostable server-driven UI framework for Flutter. The interface is JSON; the rendering is native Flutter; the release cycle is a save button. Their line for it is the correct one: seconds, not weeks.
In practice the shift is organisational as much as technical. The store binary becomes a thin, stable shell that rarely needs to change; the screens live on your server, versioned like any other deployment. A product manager reorders an onboarding flow in the console and ships it before the standup ends. A broken checkout gets its fix written at eleven and reaching every user by five past. Nothing about the app stops being native — the rendering, the performance, the feel are all still Flutter. What stops is the waiting.
The open-source part is not garnish. The framework went up on GitHub first — over nine hundred stars and a hundred-plus forks at the time of writing — and the company, co-founded at the start of 2025, grew around it. By v1.5 the platform has done the unglamorous completing: Dart-to-JSON conversion, so you write Flutter widgets and get server payloads; a CLI and a managed cloud; a visual console with one-click updates; navigation, theming and forms defined server-side; caching so screens load instantly and survive offline. Flutter contributors praise it in public, and a design lead at Airtel calls it flatly the best server-driven UI framework for Flutter. The store review, meanwhile, still guards what it should — the binary, the permissions, the native code. It just no longer holds your button hostage.
Notice, for the third time in this series, the shape. A decade of accumulated judgment about where Flutter teams actually bleed — gathered in essays, meetup Q&As and a thousand DMs — encoded into infrastructure that dispenses the fix automatically. Readers met the same pattern in recent transmissions, in very different trades. But there is an extra, very engineer-ish move in this telling: he gave the engine away. The framework is MIT; the convenience — cloud, console, one click — is the product. Trust arrives before the invoice, which is roughly how developer infrastructure has to be sold now.
Strip away Flutter and the lessons travel to anyone whose product lives behind a release gate:
Your release cadence is a product decision, not a law of physics. Teams inherited the two-week cycle so long ago it looks structural. It is a choice — and some of your competitors have already chosen differently.
Hot reload was the demo; production is the point. Developer-experience magic that stops at the device on your desk is a toy. The loop worth closing is the one that ends at the user.
Move what changes often to where change is cheap. Copy, campaigns, flows and themes churn weekly; compiled binaries should not gate them. Ship the skeleton through the store; serve the skin from your server.
Open-source the engine, sell the cockpit. Inspectable infrastructure earns a trust no landing page can buy. Charge for convenience — never for the ability to leave.
Teach in public, for years, before you need anything. Stac launched into a community its founder had spent a decade building by giving knowledge away. Distribution earned that way compounds — and cannot be bought at launch time.
What actually changes when the interface ships in seconds is bigger than convenience. Experiments become cheap enough to actually run. Seasonal campaigns land on the day, not the sprint after. A broken flow dies the hour it is found, instead of surviving until v2.4.1 clears review. Release trains stop being events with names and go back to being what they always should have been: routine.
There is also something quietly satisfying about where this one comes from. Server-driven UI’s previous life was as a private luxury of the largest app companies, each rebuilding it in-house with platform teams to spare. Its open-source Flutter incarnation comes out of Abu Dhabi, from an organiser who spent four years wiring the Gulf’s Flutter rooms together. The person standing closest to a community’s complaints turns out to be better placed to fix them than anyone in a lab three time zones away — which is, of course, why he heard them all.
So if your roadmap is currently waiting on a review queue — if you have a two-week button of your own — the fix exists, it is open source, and you can read exactly how it works before you adopt a line of it: stac.dev. The decade of writing that built it is at divyanshu.dev. And since the masthead of his essay site compresses the whole philosophy into four words, we will let him have the last ones: “Ship small. Learn always.” The button was never supposed to take two weeks.
— END TRANSMISSION 04T
We’re publishing often at the moment. One email when the next one lands, if you ask for it.
Ask for the one email →