Build your own remote UI platform, or use one?

Build, buy & decideOpinionNov 1, 20264 min readMiniwall team

Part of the series: Ways to change a live app without shipping a release

If you already have a platform team and a need that only you have, build it. If you don't, buying is usually faster, and the part to decide carefully is how you'd leave. We make one of these platforms, so read this with that bias in mind. The questions in the middle work for any vendor, including us, and you can ask them of your own team too.

If you haven't yet decided that screens should come from a server at all, start with where server-driven UI helps and hurts.

What building really includes

A first version is easy to picture: a JSON format, a renderer, and a text box to edit it. That's maybe a few weeks. What a team ends up owning is longer:

A schema and a way to change it without breaking old app versions.
A renderer for each platform (web, iOS, Android, and any cross-platform layer), kept in agreement with each other, including the edge cases.
An editor, or the decision to ask non-engineers to edit JSON.
Preview, so people can see a change before it's live.
Publish checks, so a broken screen can't reach users.
Permissions, rollback and a record of what changed.
Measurement: what was shown, to whom, and what happened.
Docs and on-call for all of the above.

Our opinion is that the first version is the cheap part. What lasts is keeping the renderers in step as platforms change, and supporting app versions that stay installed for months. That cost doesn't go away; it just moves from the vendor's invoice to your team's roadmap.

What buying means

You rent those parts, and the work of keeping them consistent. In exchange you accept someone else's component set, rules and pace, and you take on the risks of depending on them.

Those risks are worth naming: you can't make the platform do what it doesn't do, you need a way to leave, and the vendor's price at ten times your volume matters more than their price today.

Questions to ask, of any vendor or of your own team

Question	Why it matters
Who keeps the renderers working when iOS or Android changes?	This is the cost that doesn't show up in a demo.
What does an old app version do with a screen it can't fully draw?	Old builds stay installed.
What can't it express?	You want the limits before you depend on it.
Where does the data go, and what does it collect?	Privacy review will ask.
Can we leave? In what format do our screens come out?	Exit cost is the real price.
What does it cost at ten times today's volume?	Pricing shape matters more than the starting price.
What happens if the vendor stops?	Think of the worst day, not the average one.

Swipe sideways to see every column.

When building wins

You already have a platform team that owns shared infrastructure, and this fits its work.
You need components or behavior that a general platform will never offer.
Your data or compliance rules rule out third parties.
Your volume is large enough that rent costs more than owning.

When buying wins

You have no platform team, or it's already full.
You want the first screen live in weeks, not quarters.
You're moving a handful of screens, not building a general framework.
You'd rather your engineers work on what's only yours.

A middle path

Whichever way you go, put a thin layer of your own between your app and the platform: one function that asks for a screen by name and falls back to the old native screen if it can't get one. Then switching later means changing one function, not every call. Migrating one screen shows how small that first step can be.