A startup has one web client, a small team, and a single small backend service. An architect proposes introducing a BFF layer in front of it 'for future scalability.' Why might this be premature, and what should trigger actually adopting the pattern later?

## The trade a BFF actually is A BFF is a genuine engineering trade: in exchange for per-client optimization and team autonomy, it costs - an extra network hop on every request, - another service to build, test, deploy, monitor, and secure-patch, - and an ongoing discipline burden to keep business logic out of it. Those costs are worth paying when there's a real problem on the other side of the ledger - divergent client needs, or a team-ownership bottleneck. A single web client talking to a single small backend service has neither problem by construction: there's exactly one consumer, so there's no aggregation to tailor differently for a second client, and there's exactly one team, so there's no cross-team coordination cost to remove. Inserting a BFF in this situation produces a service whose entire job is passing requests through to the one backend it fronts, unchanged - pure overhead with no offsetting benefit, and a textbook case of **speculative generality**: building for a scale or diversity of clients that doesn't exist yet, on the assumption it eventually will. ## Why YAGNI here has a price tag The **YAGNI** argument here isn't just aesthetic minimalism, it has concrete costs attached. - Every request now takes an extra hop, adding latency that has to be budgeted even though it buys nothing today. - The team now owns and operates a second deployable - its own build pipeline, its own monitoring and alerting, its own on-call surface - for logic that, in this scenario, does nothing but relay. - And because "for future scalability" is a prediction rather than an observed need, there's a real chance the actual shape of future divergence (which second client shows up, what it actually needs shaped differently) won't match what was speculatively built, meaning the BFF gets reworked or thrown away anyway once real requirements appear - at which point the only thing gained from building it early was cost paid sooner for no benefit realized. ## The triggers worth waiting for The correct trigger for introducing a BFF is **observed** pain, not **anticipated** pain. Concretely: 1. A second client type appears - say a mobile app - and its data or latency needs genuinely diverge from the web client's, such that a single shared response shape starts becoming awkward for one or both. 2. Or, even with a single client type, multiple teams start needing independent control over the same shared API and start queuing behind whichever team owns it, which is the ownership-bottleneck trigger discussed independent of whether the client types themselves differ. 3. Or the existing API has started accumulating client-specific conditionals, optional fields, or version branches because more than one consumer is pulling it in different directions - that accretion is itself observable evidence that a single shared shape is no longer serving everyone well. ## When something cheaper fits Even once one of those triggers appears, a full per-client BFF service isn't always the cheapest fix. If the actual pain is purely about shape - different clients wanting different subsets or nestings of the same data - a lighter-weight alternative like a **GraphQL** API, or a REST API with sparse-fieldset/field-selection support, lets each client query for exactly what it needs from one shared endpoint without standing up a dedicated backend deployment per client. This solves the shaping problem cheaply but doesn't give teams independent deployment and ownership the way a true BFF does, so it's the better fit specifically when shaping is the pain and organizational bottleneck isn't. A full BFF is worth its cost specifically when a team also needs to own and release its own API surface independently, not merely when it wants a different field selection. ## Adopting it once the trigger arrives When the trigger does arrive - say the team ships a genuine second client, a mobile app - the lower-risk adoption path is incremental rather than a big-bang migration: introduce a BFF for the new client first, leaving the existing web client on its current direct path to the backend. This: - limits blast radius to the new client, - lets the team learn the pattern's actual operational cost (deployment pipeline, monitoring, on-call) on one service before deciding whether the web client should migrate too, - and avoids committing to a wholesale rewrite based on a prediction. If the web client later develops its own divergent needs, or the shared backend becomes a bottleneck for the web team too, that's the point at which extending the BFF pattern to web is itself justified by observed rather than anticipated pain - the same discipline applied a second time.