Choosing a backend for a mobile app, honestly
Managed backend, custom API, or backend-as-a-service. The right answer depends on two questions that have nothing to do with technology, and most teams answer neither.
The backend decision on a mobile project is usually made on familiarity, which is not the worst heuristic but is rarely the right one. Two questions matter more, and neither is technical.
Question one: who maintains this in three years?
If the answer is a team the client will hire, the technology should be one they can hire for. That argues strongly for boring and mainstream over elegant and niche, regardless of what the build would prefer.
If the answer is us, indefinitely, you have more freedom - but you have also just committed to something you should say out loud during the proposal rather than discover later.
It is worth answering this in the client's terms rather than yours. In Surat or any city outside the largest hubs, the pool of people who can maintain a mainstream stack is an order of magnitude larger than the pool for anything fashionable. A technology choice that requires a specialist hire is a choice to make the client dependent on a market they cannot reach.
Question two: what happens if the vendor changes terms?
Backend-as-a-service is genuinely excellent for getting to market. The risk is not that it fails; it is that pricing or terms change once you depend on it, and your data model has been shaped by their abstractions.
That risk is acceptable for a product testing whether anyone wants it. It is harder to accept for a business whose operations run through the app.
The question to ask is not whether you could migrate but what the migration would cost on the day you are forced to. A product where the vendor holds the records and the query patterns and the authentication and the file storage has four migrations to run at once, under time pressure, while continuing to serve users.
How we usually decide
- Validating an idea, small team, speed above all: managed backend. Take the leverage.
- Known domain, real business rules, long life expectancy: custom API on a boring stack.
- Regulated data or strict residency requirements: custom, self-hosted, and plan the operational cost honestly.
- Existing systems to integrate with: the decision is usually made for you by whatever you have to talk to.
Pick the backend your client can still operate after you stop returning calls.
The costs people forget to count
A custom API looks more expensive than a managed one because the build is visible and the operations are not. Both have an ongoing cost; only one of them arrives as an invoice with a familiar name on it.
- Somebody has to be reachable when it stops. That is a rota, not a task, and it exists whether or not anyone has been asked to be on it.
- Backups are not real until a restore has been performed. An untested backup is a belief.
- Certificates, base images and dependencies expire on their own schedule, and none of them care about your roadmap.
- Observability is part of the build. Finding out from a user that the API has been failing for two days is a cost, just not a line item.
None of this argues for managed services. It argues for pricing both honestly, so the choice is made on real numbers rather than on the one that happens to be itemised.
The part that matters more than the choice
Whatever you pick, the app should not know. Network calls behind a repository interface, models that belong to your app rather than mirroring the vendor's response shape, and no vendor SDK types reaching the view layer.
Do that and the backend becomes replaceable in weeks rather than never. Skip it and the choice becomes permanent on day one, whatever anyone intended.
The failure is rarely dramatic. It is a vendor's user type appearing in a view because it was already there and had the right fields on it. A year later that type is in ninety files, and the migration nobody planned for is now a rewrite.
A test you can run today
Search the view layer for the vendor's name. Not the networking layer, where it belongs, but the screens.
Zero results means the decision is still reversible. Anything else is a measure of how much the choice has already cost you, and it only grows. This takes a minute and is worth running on any project you inherited rather than started.
