In short
- The frontend is what people see. The backend is everything behind it: data, accounts, rules, and integrations.
- Most products need one as soon as users have accounts or data has to be shared between devices.
- Backend-as-a-service platforms cover the common parts and suit many first releases.
- Security, backups, and data ownership live in the backend. Ask about them early.
Also called: Back end, Server side, Backend development, Backend as a service, BaaS.
What the backend does
When someone signs in, saves a note, or pays for a plan, the app on their phone or in their browser does not do the work alone. It sends a request through an API to a server, which checks who they are, applies the product's rules, reads or writes the database, and sends back a result. That server side, with everything it connects to, is the backend.
What sits behind an app
- FrontendWeb or mobile screens people use
- APIThe agreed requests the app can make
- Application logicAccounts, permissions, business rules
- Data and servicesDatabase, file storage, email, payments
Frontend and backend
| Factor | Frontend | Backend |
|---|---|---|
| Runs on | The user's browser or phone | Servers or cloud functions |
| Handles | Screens, interactions, input | Data, accounts, rules, integrations |
| Typical tools | React, Swift, Kotlin, React Native | Node.js, Python, Go, Postgres |
| Can be trusted with secrets | No, users can inspect it | Yes, it is under your control |
The last row matters most. Anything shipped to a browser or a phone can be read by a determined user, so passwords, payment keys, and checks such as whether this person is allowed to see this record must happen on the backend.
Modern web frameworks blur the line. In Next.js, for example, some code in the same project runs on the server and some in the browser. The distinction still holds; it is just organized differently.
Build your own or use a backend service
A backend-as-a-service (BaaS) platform such as Firebase or Supabase provides the common parts ready-made: a database, sign-in, file storage, and access rules. You write less server code and pay a monthly fee that grows with usage.
- A backend service fits when the product is mostly storing and showing data with standard sign-in, and speed to launch matters most.
- A custom backend fits when the product has complex business rules, heavy processing, strict compliance needs, or integrations the platform does not support well.
- Many products mix both. A managed database and sign-in, plus a small amount of custom server code for the parts that are unique.
At Choie, the people who scope a project are the people who build it, so this choice is made by the person who will build on it, not handed to another team.
Plan for leaving
Whichever you choose, make sure you can export your data in a standard format. Products outgrow their first backend more often than their first design.
What founders should ask
You do not need to understand the code, but a few questions reveal a lot about how the backend is built and how much risk sits in it. They are worth asking any team building one for you.
- Where is the data stored, and in which region?
- How are backups made, and has a restore been tested?
- How are permissions checked, so one customer can never see another's data?
- Whose accounts are the hosting, database, and services in, and who holds the keys?
- What will hosting cost at ten times today's usage?
These choices are part of the tech stack and shape technical debt for years. At Choie, once the fees for a deliverable are paid, the source code written for you is yours, backend included. See who owns the code.
Common mistakes
- Trusting the frontend. Checking permissions only in the app, so anyone calling the API directly can bypass them.
- Overbuilding early. Microservices and complex infrastructure for a product with a few hundred users.
- Infrastructure in someone else's name. Hosting and database accounts owned by a former contractor.
- No backups, or untested ones. A backup that has never been restored is a hope, not a plan.
Common questions
Does every app need a backend?
Most do. If users have accounts, data syncs across devices, people interact with each other, or the app takes payments, it needs a backend. A simple calculator or offline tool may not.
What is backend as a service?
A hosted platform, such as Firebase or Supabase, that provides a database, sign-in, file storage, and access rules ready to use, so a team writes less server code of its own.
What languages are used for backend development?
Common choices include JavaScript or TypeScript on Node.js, Python, Go, Ruby, Java, and C#. The right one is usually the one the team knows well and can hire for.
Can a web app and a mobile app share one backend?
Yes, and they usually should. Both talk to the same API, so data, accounts, and rules stay consistent whichever device someone uses. The number of platforms is one of the things that moves a Choie quote, and a shared backend keeps the second platform from doubling the server work.