The backend is the server side of an app: it stores data, runs the business logic and connects the app to your CRM, accounting system and payment provider. The API is the set of methods the app calls to reach the backend and get an answer. Without a server side there is no sign-up, no orders, no payments and no sync between devices.
Key takeaways
The backend is what happens on the server: validation, calculations, writes to the database, calls to external services. The API is the door the app knocks on: a list of methods, each with an address, a set of parameters and a predictable response format.
A restaurant analogy: the waiter takes the order and brings the dish, but the cooking happens in the kitchen. The waiter is the API, the kitchen is the backend. The guest never walks into the kitchen and does not need to know the order of work there.
One tap on “Place order” turns into a chain of actions on the server:
The app only sees the result of that chain. This is why the list of API methods is written together with user scenarios, at the design stage rather than after the screens are drawn. How it all fits into the wider project is covered in the article on mobile app development for iOS and Android.
A backend is not one server but several parts with different jobs. Knowing the composition helps before the estimate: each part needs configuration, monitoring and backups.
| Component | What it does | Example in a delivery app |
|---|---|---|
| Application server | Accepts requests, runs the business logic, answers the app | Calculates the order total with delivery and discount |
| Database | Stores users, orders, payments, documents and action history | Remembers addresses, past orders and the loyalty balance |
| API | Defines the data exchange methods for the app and external systems | Serves the catalogue, accepts an order, returns its status |
| Authentication and permissions | Decides who is signed in and what they are allowed to do | A courier sees their deliveries, a customer only their orders |
| Queues and background jobs | Runs long operations outside the user's request | Sends notifications and exports reports overnight |
How these parts survive growth, and when a monolith is split into services, is covered in the article on scalable platform architecture.
Signing in solves two problems: proving that the person is who they claim to be, and remembering that without asking for the password on every screen. Tokens handle the second part: the server issues a short-lived access token and a refresh token, and the app keeps them in the platform's secure storage.
Permissions are checked by the server, not by the app. A button hidden in the interface protects nothing: if an API method returns somebody else's order on a direct request, it will return it without the button too. Every method therefore checks the role and the ownership of the data.
Account deletion needs its own method: rule 5.1.1(v) of the App Store Review Guidelines requires an app with sign-up to let people delete their account. Deletion touches related data as well, so it is designed with the database schema, not right before submission.
Payments are taken by the payment provider, not by your backend. The server creates the payment with the provider, receives confirmation from it and moves the order to the next status. Card details never pass through the app and are not stored on your side.
Local services work the same way: with Payme, card binding and charges run through the client methods of the Subscribe API, and the server receives the payment confirmation from the provider rather than from the app. Never trust a status sent by the client: an app on somebody else's phone can be modified.
The backend connects the app to your CRM, accounting system and external services through their APIs. It is where orders from the app, the website and Telegram come together, while employees keep working in the tools they know.
The order of work and the usual difficulties with 1C, telephony and messengers are covered in the article on CRM integration with 1C, telephony and messengers. One rule matters most: each field needs a single source of truth between any two systems, otherwise the data starts to drift.
A backend handles personal, payment and corporate data, so its requirements go into the architecture rather than being bolted on before launch. The baseline set of checks looks like this.
There is an industry reference for checking a finished app — OWASP MASVS: the standard is split into groups of requirements for storage, cryptography, authentication, networking, platform interaction, code, resilience to tampering and privacy. It is a convenient basis for a security review brief before publishing.
Where the backend lives is not only a question of speed. For apps that handle data about citizens of Uzbekistan it is set by law.
Important Under article 27-1 of the law “On personal data” as amended by ZRU-1125 of 26 March 2026, biometric and genetic data, along with data on telecom subscribers, must be stored inside Uzbekistan. Other personal data may be processed abroad if the conditions of the same article are met, and only databases holding data that must be stored inside Uzbekistan are entered in the State Register.
For cross-border transfers the Cabinet of Ministers approved a list of foreign states with adequate protection of personal data by resolution No. 415 of 29 July 2026, in force since 3 August 2026. Before choosing a foreign cloud, check whether your provider's country is on that list: it determines which conditions you will have to meet.
The practical takeaway: if the app stores customer data, hosting inside the country removes part of the question straight away. We keep servers in a data centre in Uzbekistan — a server for a website or CRM from $30 per month, with backups and monitoring.
The server side is built in parallel with the interface but starts earlier: without described API methods the mobile team has nothing to call.
A finished API comes with documentation you can work from without a developer beside you: method address, parameters, a sample request and response, error codes. That documentation stays with the client and makes it possible to change contractors without rewriting the server.
At Syntra Systems we start with scenarios and the data schema, not with a framework. We describe the API methods together with the mobile team, build in permissions and logging from the start, and test integrations with CRM and payment systems on a staging environment before release.
After that we take on the infrastructure as a whole: a server in a data centre in Uzbekistan, backups with verified restores, availability monitoring and incident response. If a company already has its own servers and team, we take on the app's server side alone and hand over the documentation.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Only an app that stores no user data can work without a server — a reference guide, a calculator, an offline tool. Sign-up, orders, payment or syncing between devices already need a server side, where the data is validated, calculations run and the database is stored.
Often yes: if the website has an API and returns data in a machine format, the app can use the same server side. Usually you add methods for mobile scenarios, token-based authentication and notification delivery.
If the app handles biometric data, genetic data or telecom subscriber data, the server has to sit inside Uzbekistan — the Law on Personal Data requires it. Everything else can stay abroad, for example in a country from the Cabinet of Ministers' list of states with adequate data protection. A server in our own data centre in Uzbekistan starts from $30 a month, including backups and monitoring.
Exclusive rights to the code pass to you once payment is complete. Along with the code we hand over the database schema, server access and a description of how the app exchanges data — endpoints, parameters, and examples of requests and errors. A new team can continue the work from that documentation without rewriting the server.
By the signs that appear before failure: method response times grow, database queries get heavier, background job queues pile up and server load stays high during ordinary hours. You watch these in monitoring, not after customers complain.
