Architecture and Security, Stated Plainly

At some point in a platform evaluation the conversation stops being about features and becomes about architecture. It usually arrives as a spreadsheet from somebody who was not in the demo. This post is for that person, and the operator who has to forward it.

Everything below is something the platform does today. Where a capability has a boundary, the boundary is stated in the same sentence as the fact — a reviewer who finds it out later has been misled. The same material is on the security page in questionnaire form.

Where your tenant runs

The platform runs on Google Cloud and Firebase — Firestore and Realtime Database for live data, Cloud Functions for server-side logic, Firebase Authentication for identity, Cloud Storage and Hosting, plus a MongoDB reporting replica, a Redis cache and a reporting queue. One queue component runs on AWS; nothing is placed in the US by default.

Your tenant runs in the Google Cloud region agreed at provisioning — EU and UK tenants in Europe, everyone else in the region closest to their operations. A tenant is moved only with written agreement, which matters more than the initial choice: data residency is worth very little if it can change without you.

Dedicated projects are available on enterprise plans; enterprise hosting and self-hosted arrangements are scoped on request.

What tenant isolation actually means

“Multi-tenant” covers a wide range of designs, so here is the specific one.

Every record is stored under your tenant. Tenancy is part of the storage path rather than a column a query is expected to remember — orders, customers, outlets and catalog items all live inside your tenant’s own tree. That is structural: code that forgets to filter does not silently read someone else’s data, because there is nothing at the path it is looking in.

The check runs twice. Database security rules evaluate the tenant on every read and write, and server-side middleware checks it again on every API request. Rules default to deny — a path with no rule granting access is closed rather than open. The two layers are deliberately redundant: one is enforced by the database itself and cannot be bypassed by application code; the other catches what a rule cannot express.

Identity carries the tenant. Every signed-in user holds signed claims naming their tenant and role. They are issued server-side and verified on each request, so a client cannot edit them into something else — which is what makes the two checks above meaningful.

Roles, and what each one reaches

Access is role-based throughout, and the roles are narrow on purpose:

Role	Reaches
Admin, Co-Admin	The whole marketplace
Outlet owner	Their own outlet — orders, catalog, customers, reports, earnings
Outlet user / manager	Only the areas granted on their record
Franchise owner / user	Every outlet in their franchise, with franchise reporting
Zone manager	The outlets in their zones
Dispatch manager	The dispatcher panel, and nothing else
Driver	The partner app in driver mode
Customer	The customer app

Settings, configuration, reports and the loyalty features are admin and co-admin only. The reduction is real rather than cosmetic: a staff member with order management but not catalog management never sees the catalog editor, so there is nothing to open by mistake.

Two operational details. Hand out Co-Admin rather than Admin — it reaches the same screens and keeps “who has the keys” answerable — and keep one login per person, because shared accounts make till sessions, refunds and approvals unattributable.

Money actions are permissioned separately

This is the part most role models get wrong, so it is worth stating on its own. The permissions that govern money are not part of the role — they are set independently, per role, in the order edit and cancellation settings:

• Edit items on a placed order
• Add a fee to one
• Collect payment on an edited-up order
• Process a refund
• Cancel an order
• Waive a cancellation fee

A common configuration is everyone can edit, only managers refund. Money-moving actions run server-side and are audit-logged; the client asks, the server decides.

Devices are their own identity class

A register, a kiosk or a kitchen screen is not a person with a password. Each enrols with a single-use eight-character code and is then tied to one outlet. The in-store loyalty tablet pairs with a one-time PIN and afterwards authenticates with a rotating device secret. Register staff sign in on their own PIN roster with lockout — a shift identity, separate from dashboard accounts — and POS refunds require a manager PIN.

Any device can be deactivated from the admin dashboard and its tokens revoked — the answer to what happens when a tablet leaves the building. See Devices.

Client integrity is checked too. Firebase App Check — reCAPTCHA v3 on web, Play Integrity on Android, App Attest on iOS — validates that a request came from a genuine build of your apps rather than a script pointed at the API. Rate limiting sits on every public API and webhook.

Card data, and where it is not

Card details go from the customer’s device straight to Stripe, Finix or your chosen processor — each PCI DSS certified — and never reach our servers. That is what keeps both you and us out of card-data scope, and why the answer to “are you PCI certified” is about architecture rather than a certificate.

The tooling that makes you a good controller

You are the data controller; the platform’s job is to make acting like one straightforward.

• Consent has provenance. Marketing consent is recorded per channel — email, SMS, push — together with the source, version and actor of every change. SMS STOP and START replies are honoured through a suppression list.
• Erasure reaches the whole record. A customer erasure purges the profile, addresses, saved-card references and favourites, and redacts that customer from order records rather than leaving their details inside historical orders.
• Exports are masked by default. Contact fields are masked in reports and CSV exports; an unmasked export is logged. That is about reports, not about your data as a whole — a full unmasked export of your own customer records is available from your account team whenever you need one, including when you are leaving.
• The processor relationship is written down. We act as processor under the Data Processing Annex, and the subprocessor list is published on the security page.

Where the boundaries are

Three answers a questionnaire always comes back to, stated in full.

Certifications. The platform runs on Google Cloud, whose infrastructure carries SOC 2 and ISO 27001. SuperApp does not hold a separate report of its own today, and everything an auditor would ask for is written up on the security page and in the Data Processing Annex.

Support and availability. Support runs business hours with fast responses across time zones, and response-time targets are written into your contract — a commitment you hold, rather than a published marketing figure. Planned maintenance is announced in advance.

Data protection. Compliance belongs to you as controller, and the platform is built to make it straightforward: consent provenance, erasure that reaches orders and exports, masked exports, and a Data Processing Annex covering us as processor. We call it GDPR-ready, because compliance is a property of how you run it.

And when you leave

The exit path is part of the architecture rather than a concession at the end of it: self-serve export from your dashboard, then export on request, then deletion from live systems, then backups ageing out. The stages and their windows are in the SaaS agreement, rendered from one source so the documents cannot disagree.

If you have a questionnaire in front of you, send it — the answers above are the ones we give on the form. Or book a demo and bring the person who has to sign off.