One backend for the app and the web: the right call?
For a first release where several roles share data in real time, one backend usually beats one per app. The trade-offs, the lock-in question, and how we built five surfaces on one backend.
- Choose one backend when surfaces share entities and need real-time consistency.
- Enforce access in the data layer with row-level security, not separately in each client.
- Put business rules in the backend, not in the apps, so every surface follows the same ones.
- Scope real-time channels narrowly, per clinic and per doctor in our case, never one global channel.
- Ask about the exit: Postgres is portable, platform extras are not.
Quick answer
For a first release where several roles share the same data in real time, one shared backend usually beats a separate backend per app: one data model, one set of access rules, one home for business logic, and a schema change that reaches every surface together. You trade some coupling and a single thing to secure and scale. Split later if load or team structure forces it.
The short answer
If a patient app, a reception dashboard and a doctor dashboard are all looking at the same queue, they should be reading and writing the same data through the same rules. Giving each its own backend means keeping three copies of the truth in sync. That is where bugs breed.
Why engineers ask this
You’re being asked to inherit or approve an architecture. You want to know whether “one backend” is a sensible simplification or a trap that will cost you a rewrite. A fair worry: coupling that was convenient at launch can become a bottleneck later.
What good looks like: the decision criteria
| Question | Leans to one shared backend | Leans to separate backends |
|---|---|---|
| Do the surfaces share the same entities? | Yes: bookings, queues, users | No: different data per product |
| Must they stay consistent in real time? | Yes | No |
| How big is the team? | Small, shipping together | Several independent teams |
| Where do access rules live? | In the data layer, once | Each service has its own model |
| What’s the load profile? | Moderate and uniform | A hot path needs its own scaling |
| How reversible is the choice? | Standard Postgres underneath | Heavily platform-specific parts |
A few practices make “one backend” safe rather than risky:
- Enforce access in the data layer. With row-level security, a user can only touch their own rows no matter which client they use.
- Keep business rules in the backend, such as booking, check-in and queue advance, so every surface follows the same ones.
- Scope real-time narrowly. Subscribe each client to the channel it needs, not a global stream.
- Keep the schema and the clients in one repository when they change together, so a column change reaches every client in one commit.
How we built it
A clinic-queue platform with five surfaces on one backend. Built and tested on a demo clinic ahead of launch. It has not been proven under real clinic load, and no performance number has been measured.
The clinic platform has five surfaces: a patient app, a reception dashboard, a doctor dashboard, an admin panel, and a public site with web booking. They all read and write through one Supabase backend (Postgres, Auth, Realtime and Edge Functions), hosted in Mumbai. The patient app is Flutter. The dashboards and site are Next.js.
Three decisions did most of the work:
- One repository for the app, the web and the database. A schema change ships to the Dart models and the TypeScript types in one commit, so the app and the web can’t drift apart.
- Row-level security on every table. A patient, a reception user, a doctor and an admin can only touch their own rows. We don’t rely on each client to behave.
- Real-time channels scoped per clinic and per doctor. There is no global broadcast. A reception screen hears about its own doctors’ queues and nothing else.
The business rules, such as booking, check-in and queue advance, live in backend functions. That’s why a change in one rule reaches the app and the web together.
The honest limits. This is a pattern built before launch, not proven under real clinic load. The shared backend is also a single thing to secure and a single place where a mistake affects everyone, which is why the access rules sit in the database and not in the clients. And we haven’t measured performance, so we don’t quote a user ceiling.
Where this doesn’t apply
If your surfaces don’t share data, or separate teams own separate products on separate release cycles, one backend creates coordination cost for no benefit. If a single path needs its own scaling, such as heavy media processing, pull it out when you have evidence it’s needed, not before. And if a vendor can’t tell you what leaving their platform would involve, treat that as a cost you haven’t priced.
Questions to ask any vendor, including us
- Which surfaces share entities, and where do the business rules live?
- How are permissions enforced: in the database or in each client?
- What ships together, and what is in one repository?
- What is the real-time scope, and how do you avoid broadcasting to everyone?
- If we leave the platform, what moves and what must be rebuilt?
Next: how to prevent double bookings and how to test before real users arrive. Part of the guide Buying custom software and hiring a tech vendor.
The architecture facts come from our clinic-platform brief and project notes and are tracked in our claim ledger. The decision table is our method. We hold no performance or scale measurement for this build, and no figure on this page comes from a third party.
More by GarunaCDX
How do I vet a software vendor, especially a new one?
India solar market, October 2026: what the numbers mean for EPC operations
What should a tech handover and a maintenance agreement cover?
Let's talk about your build.
Tell us what you are building. A founding engineer replies within one working day with how we would approach it.
