WizusLabs Engineering · Craft

Premium is a state, not a screen

A premium purchase is not the screen that sells it. It is a state the whole app has to agree on, even when the store is slow, the network is gone, or the player is only trying to restore what he already owns.

By WizusLabs Engineering · 2026-08-04 · ~7 min read

The easiest premium feature to build is the visible one: a card in Settings, a price row, a restore button, maybe a badge on the home screen. That is also the least important part. The product only becomes trustworthy when the entitlement is boring. Every path that cares about ads, hints, undo, cosmetics or store state should ask one question and get the same answer. If the answer changes depending on which screen the user entered from, the purchase is not a feature; it is a race condition with copywriting.

Boardlore forced that distinction because its paid shape is deliberately simple from the player's point of view: the game remains free, optional rewarded ads still have a role for free players, and Pro exists to remove ads through either an annual subscription or a lifetime unlock. Two products, one promise. The implementation detail is that the stores report subscriptions, non-consumables, pending purchases and restores through different flows. The product detail is that the player does not care which one happened. He only cares whether the app remembers that he paid.

That is why the entitlement has to be the source of truth, not the sales screen. The store callback may be where the state is refreshed, but it cannot be the only place the app understands Pro. The ad gate should not inspect SKU names. The Settings card should not recompute purchase logic. The restore button should not be a special case that unlocks a parallel flag. All of those surfaces should read a single durable entitlement model, then render their own concern: ads hide, the Pro row becomes owned, restore reports the result, and gameplay keeps moving.

The dangerous failure is not a crash. It is partial belief. One screen says Pro is active while another still offers a rewarded ad; the player sees an annual plan as bought, then returns from a cold launch and watches an interstitial request; restore succeeds but the badge remains locked until another screen is opened. Those bugs are expensive because each one looks local. In reality they are the same defect: the purchase became a UI event instead of a durable state transition.

The release check therefore has to include negative space. It is not enough to buy Pro on a happy path. The app has to launch cold with the entitlement already cached. It has to restore on a fresh install. It has to survive the store reporting a pending state. It has to prove ads are suppressed at the actual ad request boundary, not only on the button that would have led there. And the free path has to remain honest: declining Pro should not degrade into punishment, because a free game that sells removal of ads still owes a complete game to the player who never pays.

The clean version is almost dull. The Settings surface explains the two options. Purchase and restore both refresh the same entitlement. Gameplay asks the entitlement before requesting ads. The app keeps a local readable state for UI and revalidates through the store when it can. Test builds may expose debug helpers, but the production promise cannot depend on them. A premium feature is done when there is no cleverness left on the hot path.

That is the standard we want for every paid feature in the studio. Do not ship a purchase screen. Ship a state machine with a screen attached.

Notes

This post is part of the recovered daily-publisher backlog after the site publication service drifted and stopped producing dated blog results. It is intentionally written as an engineering note, not as a legal, financial, or store-policy guarantee.

Keep reading: all posts on the WizusLabs Engineering blog.

← Back to the Blog