Backend and architecture
Mobile App Backend Development: What Sits Behind the Screens, and How to Choose It
Mobile app backend development is the part of a project founders see least and pay for longest. The screens get the attention, but accounts, data, rules, notifications and payments live behind them, and decide whether the app still works in its second year. This guide explains what a backend does, compares three ways to build one, and lists the mistakes that cost the most later.
Short answer
Mobile app backend development means building the server side of an app: accounts and sign in, the database, business rules, file storage, notifications, payments and connections to other systems, plus the admin panel your team uses. There are three common approaches. A managed backend such as Supabase or Firebase fits most first versions and starts fastest. A custom backend, for example in NestJS, fits products with heavy rules, integrations or unusual data. A thin API layer fits companies whose data already lives in an existing system. The choice should follow the product's second year, not only its launch.
Key takeaways for founders and product owners
- The backend is most of the product. Screens show data; the backend decides what is true and what is allowed.
- Start managed, unless you know why not. A managed backend covers most first versions faster.
- Rules belong in one place. Logic copied into each app drifts apart after the first change.
- Own the accounts from day one. Hosting, database and payments in your company's name keep the next step open.
What a mobile app backend actually does
Every app with accounts or shared data has a backend, even if the founder never sees it. In practice it does six jobs.
Who is who
Accounts, sign in with Apple, Google or email, roles and what each person is allowed to see.
What is true
The database that holds bookings, orders, jobs or messages, so every device shows the same state.
What is allowed
Business rules: who can cancel, what a booking costs, when a job is complete. One place, not copied into each app.
Who needs to know
Push notifications and emails triggered by events, such as a new booking or a finished job.
Where money goes
Payments, refunds, payouts and receipts through a payment provider, recorded against the right order.
What else it talks to
Accounting, CRM, ERP, maps or calendars, so data does not have to be typed twice.
When one company builds both the apps and everything below them, these layers are designed together, and problems between them stay inside one team. That is the core idea behind end to end app development, and the reason we rarely build an app without its backend.
Three ways to approach mobile app backend development
There is no single right stack. There is a right fit for the product, the team that will own it and the next two years of changes.
Managed backend
Supabase, Firebase and similarCustom backend
NestJS or similar, on PostgreSQLAPI layer on what you have
A thin backend over an existing systemMost products we build start on a managed backend and keep it, because the rules are simple enough to live there. The decision changes when the logic grows heavier than the data.
When a managed backend is enough
Loopy Jobs and EveSport on Supabase
Loopy Jobs is a marketplace where clients find specialists on a map, message them and book. EveSport connects personal trainers with clients, with booking, slot swapping, chat, payments through Stripe and a React admin panel. Both run on Supabase with PostgreSQL.
A managed backend gave both products sign in, a relational database, file storage and real time updates from day one, so the effort went into the rules that make each product different, such as booking logic and slot swaps, written as server functions.
Loopy Jobs has since passed 4000 users on the same backend without a rebuild.
A managed backend is usually enough when the product has standard accounts, a clear data model, moderate rules and no unusual integration. It is not a shortcut you pay for later, as long as the data model is designed properly and the rules stay on the server.
The screens show what is true. The backend decides it. Build the second one with the second year in mind.
Not sure which backend fits your product? Send us a short description and we will recommend one, with reasons.
When mobile app backend development needs custom code
Liniowiec: offline sync that a template could not do
Liniowiec is a Flutter navigation app for inland waterways, covering about 1000 km of routes across more than 18 rivers, where coverage is often absent. There was far too much route data to download at once, so the backend was built in NestJS with a custom sync: routes are split into segments, data that never changes ships inside the app, and only new segment versions are fetched.
A React admin panel lets the operator publish routes and moderate user reports. The first stage is live and the client came back for the next one, built on the same backend.
Custom code earns its cost when the product has heavy business rules, several integrations that must stay consistent, offline data that syncs in unusual ways, or volumes a managed service would make expensive. More on the offline side in offline first app development, and on connecting to existing systems in mobile app integration with existing systems.
The admin panel: the backend your team actually sees
Users never see the backend. Your team does, through the admin panel. On TimeFix, a field app for electrical crews, the mobile app and a React web panel for contractors and team leads share one backend, so a job closed on site appears in the office immediately. On EveSport, the React panel runs the operation behind the trainer and client apps.
Two rules make an admin panel safe. It should change data through the same API and rules as the app, not by editing the database directly. And the office must be able to correct a record by hand, because field data will occasionally be wrong. For marketplaces specifically, see marketplace admin panel.
Backend mistakes that show up in the second year
None of these breaks the app at launch. Each one makes every later change slower and more expensive.
Rules copied into the app
A cancellation fee calculated in the app on iOS and again on Android drifts apart after the first change. Rules belong on the server, once.
No plan for the admin side
Without a panel, every refund, correction or approval needs a developer. The data model should be ready for it even if the panel comes later.
Accounts that do not connect
A user who signs in with Apple one day and email the next ends up with two accounts unless identities are linked from the start.
Photos treated like form data
Large uploads on a weak connection block everything behind them. Files need their own queue and compression, or storage costs and failures grow together.
Everything in the founder's personal accounts
Hosting, database and payment accounts should belong to the company from the first week, or the next team inherits a locked door.
No monitoring
Without error tracking and logs, the first sign of a backend problem is a one star review.
Sensitive data adds its own layer of care, from secure storage on the device to encrypted connections and limited access on the server. We cover that in how Flutter apps keep sensitive data safe.
How mobile app backend development fits into the project
The backend is not a phase that happens before the app. It grows in the same two week cycles, one flow at a time, so you can test a real booking, order or job on your phone early instead of waiting for a finished server.
- Discovery. The data model and the rules are written down: who the users are, what they create, what can change and who may change it. Most backend mistakes are prevented here, on paper.
- First cycles. Sign in, the core data and the first rule go live on a test environment, connected to the first screens.
- Middle of the build. Notifications, payments, file uploads and integrations are added flow by flow, each one tested end to end from the phone.
- Before release. Separate production and test environments, backups, error monitoring and access for your team are set up and handed over.
What a mobile app backend costs to run
Besides building it, a backend has running costs that belong in the budget from the start. None of them is large for a first version, but each one grows with usage, and some grow faster than founders expect.
- Hosting and database. A monthly plan that scales with users and data. Managed services publish their tiers, which makes this the easiest line to predict.
- File storage and transfer. Photos and documents are usually the fastest growing cost. Compressing images before upload keeps it under control.
- Messaging. Push notifications are generally free; text messages and transactional email are paid per message.
- Payment fees. A percentage of each transaction, paid to the payment provider rather than to the hosting company.
- Monitoring and maintenance. Error tracking, security updates and small fixes keep the backend healthy as phones, libraries and traffic change.
Yearly upkeep is covered in more detail in mobile app maintenance cost.
Six questions to ask about mobile app backend development before you sign
Ask any agency these questions. The answers should be specific and, ideally, written into the contract.
The answer should be your company, from the first week.
On the server, in one place, documented.
Through the same API and rules as the app, not directly in the database.
A specific answer about the database, files and costs, not just "it scales".
Automatic backups and a tested way to restore them.
Documentation, environments and a repository in your name make that possible.
A backend costs more than most founders expect and less than a rebuild. Its price is driven by the number of rules, integrations, roles and the admin panel rather than by the number of screens; current price bands are on our pricing page. If you are choosing the app technology at the same time, our page on working with a Flutter app development company shows how we build the apps on top of these backends.
About the source
Who is answering this?
- Company
- Apps Value, mobile app development agency
- Location
- Cracow, Poland
- Markets served
- United States, Western Europe, Nordics
- Experience
- 6 years, 19+ projects delivered, 13+ positive client reviews
- Backend technologies
- Supabase, NestJS, PostgreSQL, AWS, Google Cloud
- Backends we have built
- Loopy Jobs, EveSport, Liniowiec, TimeFix
FAQ
What is mobile app backend development?
It is building the server side of an app: accounts and sign in, the database, business rules, file storage, notifications, payments, integrations with other systems and the admin panel your team uses. The app screens show data; the backend stores it and decides what is allowed.
Does every mobile app need a backend?
Almost every app with accounts, shared data, payments or notifications does. Only apps that work entirely on the device, such as a simple calculator or an offline tool with no syncing, can do without one.
Supabase, Firebase or a custom backend?
A managed backend such as Supabase or Firebase fits most first versions with standard accounts and data. A custom backend, for example in NestJS, fits heavy business rules, several integrations or unusual sync. We use Supabase when its relational database and server functions cover the rules, and NestJS when they do not.
Can we start with a managed backend and move later?
Yes, if the data model is designed properly and the business rules live on the server rather than in the apps. Then moving rules into a custom service later is a project of its own, but not a rebuild of the whole product.
Who should own the backend accounts?
Your company, from the first week: hosting, the database, file storage and the payment provider. The agency works with access you grant, so the next team, in house or not, can take over without a locked door.
Can you build a backend for an app another team made?
Yes. We start by reviewing the existing app and its data, agree how it should talk to the new backend, and connect it flow by flow. If the app itself needs work too, the same review tells you whether to extend it or rebuild parts of it, with the reasons written down.
How long does mobile app backend development take?
It is built alongside the apps rather than before them. For a focused first version that usually means the same 8 to 12 weeks as the app; heavy integrations, offline sync or a large admin panel extend it.
Related guides
Written by
Thomas Siudut
Co-Founder and CEO, Apps Value
Thomas sets the company's long term strategy and direction, identifies market opportunities, and owns business development and client acquisition. He builds strategic partnerships that last beyond a single project. He works with clients from the first strategy conversation, so their business goals, not just their feature list, drive every decision.
Need the backend, not just the screens?
Tell us what your app has to do and what systems it must talk to. We will recommend a backend approach, explain why, and tell you what a fixed price for the apps, backend and admin panel covers.