A company gives each frontend team - web, iOS, Android - its own BFF that they build and deploy themselves. What organizational benefit does this bring, and what failure mode commonly emerges a year later if it isn't actively managed?

## Where the autonomy comes from The organizational benefit follows directly from who controls the deployment pipeline. When a frontend team owns its BFF end to end - code, tests, deployment, on-call - it can change that BFF's response shape, add an aggregation, or adjust a field the moment its UI needs it, without opening a ticket against a separate backend team and waiting for that team's roadmap to have room. This is the practical expression of **Conway's Law**: because the system's module boundaries (one BFF per client) mirror the organization's team boundaries (one team per client), coordination cost between teams drops for anything that's purely client-specific. - In a **shared-backend model**, a small UI-driven change - reshaping a response to support a new screen layout - has to compete for priority against every other team's requests on the same shared API. - In a **BFF-per-team model**, that same change is a same-sprint pull request the owning team merges itself. ## The failure mode - logic leak The failure mode that commonly emerges without active management is **business-logic duplication**, sometimes called "logic leak." A BFF's intended job is orchestration and shaping - call the right services, combine and trim their results - not deciding business outcomes. But in practice, when a frontend engineer needs a computed value (say, a loyalty-tier discount percentage) and the domain service doesn't yet expose it cleanly, the path of least resistance is often to compute it inline in the BFF using whatever raw fields are already available, rather than filing a request for the domain service to expose the computed value directly. Multiplied across several BFFs owned by different teams, each with their own engineers making that same convenient shortcut independently, the same business rule ends up implemented multiple times, in slightly different code, evolving independently as each team makes local changes for its own reasons. ## What the drift looks like in production The production symptom of this drift is usually a customer-facing inconsistency discovered well after the fact: the iOS app shows a different discount or a different eligibility result than the web app for the same account, because their BFFs' copies of the discount formula have quietly diverged. - Maybe one BFF was updated for a new promotion tier and the other wasn't. - Or one has an off-by-one difference in a threshold check that nobody caught because there was no single place a reviewer would see both versions side by side. This is expensive to debug precisely because it looks like a data problem at first (two clients showing different numbers for the same account) when the actual root cause is duplicated logic, not duplicated or inconsistent data. ## The fix - a rule and a mechanism The fix is a combination of a clear rule and a shared mechanism. 1. **The rule.** Business logic - anything that decides a business outcome rather than merely reshaping data for display - stays in the domain service that owns that concept, and the BFF's job is to call that service and pass its answer through, not to recompute it. 2. **The mechanism.** What makes the rule sustainable at scale, once there are many BFFs, is usually either periodic contract or logic audits across BFFs looking for suspicious duplication, or a shared internal library/SDK that legitimately client-agnostic logic (e.g., currency formatting, a shared validation helper) can live in, so it isn't hand-rolled per BFF even when it is presentation-adjacent rather than a domain rule. ## The other cost - operational surface There's also a second, less dramatic but steadily accumulating cost worth naming: **operational surface area**. Each BFF is a separately deployed service needing its own on-call rotation, monitoring dashboards, dependency upgrades, and security patching, even when its code is mostly thin orchestration. With three client types that's three times the deployable surface for logic that individually is not very large; some organizations offset this by building a shared BFF framework or scaffolding library that standardizes cross-cutting BFF concerns (auth propagation, tracing, error handling) so each team's actual BFF code stays small, while deployments and ownership remain separate. Both costs - logic drift and operational surface - are manageable, but only if a team is actively watching for them; left alone, they're exactly the kind of thing that looks fine at launch and only becomes visible as an incident a year later.