Install Base Lag
also called Client Version Spread, Release Adoption Tail
The distribution of client build versions actually in use at a given moment - the number that decides how many screen contracts a server experience layer must keep alive and how long a field can never be removed.
A web team ships a change and after one cache cycle every session runs the new code. A mobile team ships the same change and three weeks later 90% of installs have it - which means 10% do not, and some will not for months. One server cannot treat both alike.
Install base lag is that distribution, measured in production rather than assumed: for each client build still in use, its share of sessions and how long the release took to reach it. It is a property of app stores and device behaviour, not of the deployment pipeline. It is the input that sets a backend-for-frontend's versioning obligations, and it is routinely missing from the design discussion.
Why it matters
A backend-for-frontend shapes payloads for one client's exact needs. Once the client is a shipped binary rather than a page, those needs are the union of several binaries' needs - on a two-week cadence with a three-week tail, typically 3 to 5 screen contract versions concurrently.
A field therefore cannot be removed inside a live contract version, a renderer absent from older builds cannot be targeted, and "deploy the BFF with the client" is unavailable - there is no single client to deploy with.
Implementation patterns
- Version the screen contract explicitly, by path (
/v3/screens/home) or by a client-version header. Implicit versioning by "whatever the newest client wants" is the defect itself. - Publish the live distribution where engineers see it: oldest version above roughly 1% of sessions and share per version, so "can we delete this field?" is a lookup.
- Keep a contract alive for two full adoption tails - about 6 weeks here - plus the forced-upgrade grace period.
- Let the client declare capabilities, not just a version, so the BFF degrades one region instead of guessing from a build number - and instrument error rates per client build, which surfaces a break on old installs in hours rather than at the next store review.
Industry example
The archetype is a marketplace with iOS, Android and web clients behind one experience layer, and the lesson has one shape: a BFF change shipped in lockstep with the newest app build, after which the previous two versions received a payload naming a component those binaries cannot render - no server error, no alert, just blank regions on devices nobody on the team is holding, found through store reviews.
Industry adoption curves repeat one pattern: steep in the first week, roughly 90% within two to three weeks, then a long tail that never updates until forced. The tail, not the median, is what the policy must cover.
Failure scenarios
- Silent blank regions on older builds, because a removed field returns null and the renderer skips it rather than failing loudly.
- Client-side crash loops from an unexpected payload shape, unfixable by deploying - the broken code is on the device, so only a server-side contract rollback helps. This is why the BFF is the real kill switch for a mobile release.
- Experiment contamination, when a variant renders only on the newest build, so the treatment group is a device-recency cohort.
Trade-offs
| Choose | Gains | Pays |
|---|---|---|
| Many contract versions | no forced upgrades | every change multiplied; dead code |
| Forced upgrade window | one or two contracts | support burden; users at a wall |
| Capability negotiation | degradation without branching | a vocabulary to keep honest |
The decisive asymmetry: adding a version is cheap once and expensive forever, while forcing an upgrade is expensive once. Teams take the cheap option repeatedly and arrive at nine live contracts.
When not to use it
A web-only experience layer does not need this machinery. With a short cache TTL and a reload, version spread collapses to one within minutes, so fields can be removed freely and the BFF deploys with the client.
It is also the wrong frame when every client is under your operational control - kiosks, internal tools on managed devices. There the distribution is a fleet-management fact with a deadline, and the answer is a rollout plan, not a versioning policy.
Interview question
Q: Your mobile app reaches 90% of installs in three weeks and you need to remove a field from a screen payload. How do you decide when that is safe, and what makes the next removal cheaper?
What a strong answer covers: reading the live version distribution rather than the adoption median; the oldest-version-above-1% rule and why 1% is a business choice; two adoption tails plus the grace period; per-version error instrumentation; capability declarations so removals stop being version-gated; and the asymmetry that a contract rollback is the only kill switch once broken code is on the device.
Quick check
Quiz: Why can a mobile BFF not deploy in lockstep with its client while a web BFF can? Answer: a shipped binary leaves several versions in concurrent use for weeks, so the BFF must satisfy their union; a web client converges on one version within a cache cycle.
Flashcard: Which number decides how many screen contracts a BFF must keep alive? — The live client version distribution: the oldest build above about 1% of sessions, held for two adoption tails plus the grace period. A two-week cadence with a three-week tail means 3 to 5 concurrent contracts.