Isolation
A database of your own. Not a row with your name on it.
Most multi-tenant software puts every customer in the same tables and adds a column to tell you apart. That works until one query forgets the filter. Mealforma is built the other way: each company gets a dedicated Postgres database from the moment it signs up. There is no shared table to leak from, and no cross-database query without infrastructure nobody is going to install.
It is not a tier you buy
Because every customer has one, it cannot be sold as an upgrade. It is a baseline property of the product. The paid step above it is a dedicated server — your database on hardware nobody else is on — which is a connection-string change rather than a different version of the software.
Signing up is not slow because of it
Provisioning copies a template database that is already at the current schema version rather than replaying every migration. You get a working shop in the sign-up request, not an email an hour later.
There is still an inner wall
Every business table also carries an organisation id, and every query runs through a scoped client that injects that filter automatically. Inside a database holding one company, that wall protects you from our bugs as well as from other customers.
Isolation is tested adversarially
We run tests whose entire job is to reach another company’s rows through the API, exports, search, webhooks, files and the AI assistant. A pass is not proof of safety, but a failure is a release blocker.
Shipped
What is running in the platform today
Everything in this list exists in the product now. Anything decided but not yet built is in the next list, separately, because a security page that blurs the two is worthless.
Break-glass lockdown
One control revokes every active staff session, forces re-authentication, and can freeze the business to read-only while you work out what happened. It works from a phone, needs no deploy, and is reversible. It is scoped to your company and cannot be triggered platform-wide by accident.
Per-account and per-IP kill switches
Disable one staff account and revoke its sessions, or block an address range, without touching anyone else.
Read auditing on personal data
Opening or listing customer records, addresses, phone numbers and order history is recorded — who, when, which records, from where. Most systems log writes only, which means a compromised session that merely browsed leaves no trace. This one answers "what did they actually see?".
A tamper-evident security log
Security and audit rows are append-only, and each security row is chained to the one before it, so silent deletion or editing is detectable rather than invisible.
Detection that reaches a human
Sign-ins from a new country, impossible-travel jumps, bursts of customer-record reads, bulk exports, repeated permission denials, role changes and failed-login spikes each raise an alert with a link to the evidence. Every threshold is a setting you can tune, not a constant we compiled in.
A session and credential inventory
Who is signed in right now, from where, on what device, and when each staff account last authenticated — as a screen, not an investigation.
Export and erasure you can run
A customer’s data can be exported and erased on request, with the request, the decision and the outcome recorded. Orders, payments and deliveries are never hard-deleted — they are anonymised, because a business still has to be able to account for the money.
A database per company, created at sign-up
Signing up creates a dedicated Postgres database for your company, copied from a template already at the current schema version. Your data is never in the same tables as another company’s.
Every update reaches every company’s database
When we ship a schema change, each company’s database is updated before the new version takes traffic, and the version applied is recorded per company. A company whose update fails is paused and retried on its own, and shows on our operations console until it is current — nobody is left running new code on an old schema.
Decided, being built
Not finished yet
Time-boxed, audited support access
When our staff need to look inside your account to help you, it will be a named action with a reason, an expiry, and an entry you can see. "Log in as" with no trace is how software companies lose customers. This is decided and specified; it is not built yet, and until it is, support works from what you send us.
Known gaps
What we do not have, said out loud
No point-in-time recovery
There is no rewinding a company’s database to a chosen minute.
Row Level Security is not used
We considered enforcing isolation inside Postgres with row policies and chose a database per customer instead. Inside a database that holds exactly one company, row policies protect nothing the database boundary has not already protected. If you are comparing us with a shared-table vendor that does use RLS, that is the trade we made and why.
No third-party audit yet
Mealforma has no SOC 2 report and no external penetration test. We are not going to claim a certification we do not hold. What we can show you is the architecture, the audit trail, and a restore transcript.
If you are comparing vendors
Ask every one of them which of their claims are shipped, which are roadmap, and what their last restore actually proved. A vendor who will not separate those three is telling you something.
