Who writes this
The Miniwall team writes this blog. We build Miniwall, a tool that renders subscription screens in web and mobile apps from a JSON description, so we have a stake in these topics.
Posts about how things work are meant to be fair to other approaches, including building it yourself. We mention Miniwall at the end of a post only when it fits.
What we cover
Changing what users see in a live app without shipping a new release: server-driven UI, release practice, subscription growth, and the technical and product decisions around them.
- Server-driven UI: How server-driven UI works, where it pays off and where it hurts: schemas, rendering, versioning and caching, explained without the hype.
- Shipping without a release: Feature flags, remote config, OTA updates and store rules: the ways to change a live app without a release, and what each one can't do.
- Growth without waiting on dev: Campaigns, paywalls, upgrade prompts and tests, and how growth teams can ship changes without a ticket queue or a release train.
- Build, buy & decide: Build or buy, pricing models and third-party risk: checklists for the calls tech leads and founders make about tools they depend on.
How we write
- Every factual claim links to a source we read: standards, official documentation, or what a company wrote about its own systems. Sources sit at the end of each post with the day we opened them.
- Code runs before we publish it, and we note the version.
- Opinions are marked as opinions. If we couldn't verify something, we leave it out.
- We don't invent numbers, customers, or stories.
- We weigh the options fairly, including the ones that aren't ours.
Corrections and updates
Substantive changes show an “Updated” date and a line saying what changed. Factual errors get a visible correction note.
Technical posts are reviewed against new versions; posts about policies and regulations more often. Policy and legal posts are not legal advice.
Spotted a mistake? Tell us (opens in a new tab).