What Backend Does Your App Need?
By CodexierPublished 4 min read
The part of an app you see is only half of it. Behind the screens sits a backend that stores data, checks who is logged in, sends notifications and talks to other systems. For a founder or product owner, the key decisions are what jobs the backend must do and whether a managed service can do them, or whether you need a custom API. This guide explains both without assuming you write code.
What a backend does for an app
- Authentication: who the user is, and keeping them securely logged in.
- Data storage: the records users create and share, stored centrally rather than only on the phone.
- Access rules: which user may read and change which data.
- Files: images, documents and uploads.
- Server logic: calculations, payments and rules that cannot be trusted to the app itself.
- Integrations: talking to payment providers, CRMs, Fortnox or other systems.
- Notifications and background jobs: reminders, emails and scheduled tasks.
Managed backends vs custom APIs
| Aspect | Managed backend | Custom API |
|---|---|---|
| Examples | Supabase, Firebase and similar | Node, .NET, Python or similar on your own hosting |
| Time to first version | Short, much is ready | Longer, everything is built |
| Flexibility | High for common needs, limited at the edges | Unlimited |
| Operations | Handled by the provider | Your responsibility: servers, updates, monitoring |
| Lock-in | Moderate; open-source options reduce it | Low, but you own all the code |
| Fits | MVPs, most business and consumer apps | Complex rules, heavy integration, special compliance needs |
The common pattern is a hybrid: a managed backend for accounts, data and files, plus a small amount of custom server code in serverless functions for payments, integrations and anything that needs secret keys. That keeps the benefits of both.
Logins, data and files
Logins are the part not to build yourself. Managed services handle password storage, email verification, social login and session security. For Swedish apps, BankID usually runs through an identity provider that the backend trusts; our guide to BankID login in an app explains the setup.
- Define access rules in the database, not only in the app, since the app's code can be inspected and bypassed.
- Separate each customer's data clearly if the app serves several companies.
- Store files in object storage with access rules, not in the database.
- Keep personal data in an EU region and document the provider as a sub-processor.
Notifications and background jobs
Push notifications
Sent through Apple's and Google's services, triggered by the backend. Store device tokens and user preferences. See our guide to push notifications users keep.
Email and SMS
Receipts, reminders and login codes through an email or SMS provider, triggered by events.
Scheduled jobs
Nightly syncs, reminder runs and cleanup tasks run on a schedule, not when a user opens the app.
Webhooks
Receiving events from payment providers and other systems, such as a completed payment.
Costs as users grow
Managed backends often start free or cheap and charge by usage: database size, storage, bandwidth, function calls and active users. That is ideal early on. Costs grow with success, so model them before launch: estimate active users, data per user and files per user, and run the provider's pricing against a year of growth. Surprises usually come from file bandwidth, chatty apps that make many requests, and inefficient queries, all of which are fixable.
When you do not need a backend: an app that only works with data on the device, such as a calculator or an offline reference tool, may need none at all. For everything else, our cross-platform MVP app includes the backend setup, access rules and EU hosting. See the pricing page or book a short call.
Frequently asked questions
Can we use the same backend for the app and the website?
Yes, and you usually should. One backend serving both the web and mobile apps keeps data and rules in one place and avoids syncing between systems.
Is a managed backend secure enough?
The platforms themselves are generally well secured. Most incidents come from configuration, such as missing access rules or exposed keys. Security depends on how the backend is set up, not only which one you choose.
What happens if the provider raises prices or shuts down?
Choose a provider built on open standards, such as a Postgres database, so data and logic can be moved. Keep regular exports and avoid features that only exist on one platform where you can.
Do we need a backend developer on staff?
Not for an MVP on a managed backend. Someone must still own the access rules, integrations and updates, whether in-house or through a maintenance agreement.
Sketch the backend for your app
Describe what your app does and who uses it. In 15 minutes we will outline the backend jobs and whether a managed service covers them.
Book a free 15-minute call