The icon on the home screen is the tip of the iceberg. What actually decides whether the app works, whether your customers’ data goes missing, and how much it costs to run, sits hidden on a server the user never sees. This lesson is about that invisible half. You don’t need to understand it line by line, but you should know it exists and that it’s real work.

Why almost every app needs a backend

A purely “on-device” app that lives entirely on the phone and talks to nothing outside is rare these days. A calculator, a simple flashlight, an offline unit converter. The moment you add anything more alive than that, you need a server.

Accounts and login. If a user is supposed to sign in on a different phone and find their data there, that data has to live somewhere. It isn’t in the phone itself.
Shared data. A restaurant booking, messages between people, stock levels in a shop. Anything more than one person sees at once needs a single shared place.
Payments. Subscriptions, purchases, invoices. Never let the phone decide prices and permissions; it can be spoofed. That belongs on the server.
Content that changes. A menu, a price list, news. If you want to change it without making people download a new version of the app, it has to flow from the server.

The rule is simple: if the data needs to show up anywhere other than one single phone, there’s a backend behind the app. And the backend is a project of its own, not an add-on to the mobile part.

The API is the bridge between app and server

The app and the server are two separate worlds. What connects them is the API, which you can picture as a menu and an order window. The app “orders” (“give me tomorrow’s bookings,” “save this order”) and the server sends a reply back. The menu defines what can be ordered and in what form it comes back.

You, as the client, don’t need to be able to write that code. But you should know this: every screen that shows live data means one or more of those requests, and each one has to be built on the server, secured, and handled for what happens when it fails.

So when you say in a meeting “and the app could also show stock levels in real time,” you’re not adding one screen. You’re adding work on the server, on the API, and in the app. It isn’t expensive because someone is padding the bill. It’s expensive because a bridge gets built from both banks.

Offline-first sounds nice, but it isn’t free

Phones lose signal. On the subway, in an elevator, out in the countryside, abroad with data turned off. An app that freezes on an endless loading spinner at that moment feels broken, even when it’s actually fine.

“Offline-first” means the app keeps the data it needs on the phone too, so it works without a signal and syncs itself the moment it reconnects. For the user, magic. For whoever builds it, the hardest part of the whole app.

The catch is called sync and conflict resolution. Imagine you edit the same note in an offline notes app on both your phone and your tablet, each one differently. When both reconnect, the server gets two truths. Which one does it keep? The newer one? Merge them? Let the user decide? There’s no single universal answer to these questions, and every app solves them a little differently.

Order full offline mode when the app genuinely needs it (a field worker with no signal, a reader, notes). For a typical app where the user is connected almost all the time, it’s often enough to handle dropouts gracefully and save work in progress. That’s a fraction of the cost.

Push notifications: the most powerful lever, and the easiest to break

Push notifications are delivered to the app by the phone’s operating system, even when the user doesn’t have it open. Apple does it through its APNs service, Google through FCM. You don’t need to remember these acronyms, just know that iOS and Android each have their own channel and the app has to handle both.

It’s the best tool you have on mobile for keeping a user around. And also the one that loses you a user the fastest.

You have to ask first. Without permission, the system won’t deliver your notifications. And you get that permission only once, so don’t beg for it on the very first screen. Ask when it’s clear what it’s good for.
Send only what has value for the user. “Your parcel is on its way,” yes. “We miss you, come back,” for the third time this week, no.
Notification fatigue ends in an uninstall. When an app nags, people turn the notifications off, and then they delete the app. You lose them forever over a few messages too many.

A good rule: for every notification, imagine it arriving on a Saturday night. If it would annoy you, don’t send it.

Where your data lives and who really owns it

This is a question to ask before the first line gets built. User accounts, their data, payments, all of it physically sits somewhere and someone holds the keys.

Login (auth). How a user signs in and how passwords are stored. You never build this from scratch in-house; you use proven methods and services.
Where the data lives. A database runs somewhere, typically on a provider’s server. You should know where, in which country, and who has access to it.
GDPR. The moment you collect personal data from users in the EU, the rules on protecting it, on consent, and on the right to erasure apply to you. That isn’t optional, and the app has to be ready for it from the start.

And now the most important part, the one others might not tell you. Insist that you own the backend, the database, and the user accounts, not the vendor. When your entire customer base sits on some agency’s account or in a closed platform you can’t get the data out of, you’re not building an asset. You’re building a gilded cage. At FRGTN we do it so the code, the server, and the accounts stay yours, and you can take them elsewhere whenever you want. The app is your business. The keys to it should be yours too.