A quick-commerce platform serves a mobile app, a web app and a partner API from the same services. When does a backend-for-frontend earn its place?

When it earns its place

• When the clients genuinely need different data shapes. A mobile home screen needs a compact aggregated payload optimised for one round trip on a poor connection; a partner API needs complete normalised records. Serving both from one endpoint means one of them is wrong.
• When round trips are expensive for one client and not another. A mobile client on a slow network benefits enormously from aggregation; a server-side partner integration does not care.
• When client release cadences differ. A mobile app cannot be updated instantly, so its BFF absorbs backend changes and keeps the app's contract stable — which is one of the strongest arguments and the least cited.
• When client-specific concerns exist: device-specific formats, per-client authentication, per-client rate limits, response shaping for a partner's requirements.

When it does not

When the BFF is a pass-through. A layer that forwards requests unchanged adds a hop, an availability dependency and a deployment, and provides nothing. That is the common state of BFFs added by convention.

What it must not become

A place where business logic accumulates. The temptation is real: the BFF is close to the client, it is easy to change, and the shortest path to a feature is to add the logic there.

Logic in a BFF is logic duplicated per client — implemented once for mobile, again for web, differently each time — and the divergence is discovered as inconsistent behaviour between platforms.

The BFF aggregates, shapes and adapts; it does not decide.

The ownership question that determines success

A BFF should be owned by the client team, because its purpose is to serve that client's needs and it must change at that client's pace. A BFF owned by a backend team becomes a queue: the client team requests changes and waits, which is the coupling the pattern existed to remove.

The alternative worth considering

A single gateway with client-aware response shaping, or a query layer that lets clients request the shape they need. Both avoid a deployable per client, and both introduce their own costs — the second in particular creates an unbounded query-cost surface that must be budgeted.