Backend options for a mobile app: managed, custom, or both

01What managed backends are genuinely good at

Getting to a working product quickly with a small team, and doing so with authentication and realtime behaviour that would otherwise take real effort to build correctly.

For products where the data model is document-shaped, access patterns are simple, and scale is moderate, a managed backend can remain the right answer indefinitely. Replacing it out of principle is a common and expensive mistake.

They are also good for the parts of a system that are genuinely commodity - file storage, push delivery, anonymous auth - even when the core is custom. Using one for everything and using one for nothing are both avoidable extremes.

02Where the constraints bite

The pain arrives at predictable points and is worth checking against your roadmap before committing.

• Query complexity. Document stores handle simple lookups well and aggregate reporting badly. If your product needs analytics over your own data, plan for it separately from day one.
• Cost at scale. Per-read pricing is cheap early and can become the dominant line item once usage grows, particularly with realtime listeners on large collections.
• Vendor-shaped security rules. Access control lives in a rules language rather than your codebase, which is harder to test and review than application code.
• Data residency and compliance. Regions are what the vendor offers, which can be decisive for regulated or public-sector customers.
• Migration cost. Auth is the stickiest part - moving providers means re-authenticating every user unless you can export password hashes, which most vendors do not permit.

03The hybrid that usually works

Use managed services for auth, file storage and push; run your own API and database for domain data. This keeps the parts that are genuinely commodity cheap and the parts that carry your business logic under your control.

It also contains the migration risk. Replacing a storage provider is a contained project; replacing the system of record for your entire product is not.

The failure mode to avoid is splitting authority over the same data across both, where some writes go through your API and some go directly to the managed store. Once two paths can write the same record, your invariants live in neither.

04How to decide

Choose managed when speed to market dominates, the data model is simple, the team is small, and no compliance requirement forbids it. That describes most early products honestly.

Choose custom when the data model is relational and complex, when reporting is part of the product, when data residency is contractual, or when per-operation costs at your projected scale exceed running your own infrastructure.

And decide deliberately rather than by default. The expensive outcome is not either choice; it is arriving at scale having never checked which one you were on.