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, a reporting queue and a reporting API. That reporting stack is shared by every customer and does not follow your tenant’s region: the reporting database and the queue that feeds it (on AWS) are in the United States, the cache is in Japan, and error monitoring is in the United States. Engineering and support work from India.

Your tenant’s primary database and file storage run in the Google Cloud region recorded at provisioning — the United States for most customers, an EU region on a dedicated EU project. The database 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 checks scope staff and device requests to their tenant again; for end-customer requests that second check currently logs mismatches rather than refusing them, so the database rules are the enforcing layer there. 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:

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 enrols the same way, with no separate pairing PIN, and is then linked to a staff phone or register. 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 — issues attestation tokens from genuine builds of your apps, and server-side enforcement of those tokens is being rolled out surface by surface. The API is rate-limited, inbound payment webhooks are signature-verified, and so are messaging webhooks where the provider signs them.

Card data, and where it is not

Card details are tokenised by the payment processor rather than stored by the platform. That reduces card-data exposure; it is not a PCI DSS certification or an automatic exemption. PCI SSC explains that service providers can remain in scope even without directly handling card data. Confirm the responsibilities for your integration with your acquirer or a qualified assessor.

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 past orders. A customer who deletes their account from the app has their profile, saved addresses, saved-card references and favourites purged, and their name and contact details replaced on historical orders; delivery addresses on those orders are removed on your request. The financial record of each sale is kept.
• Exports are masked by default. Contact fields are masked in CSV exports, and access to personal data through reports is logged. That is about exports, 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.