Trust & security
Your data stays yours, and your export files stay on your machine.
The five things a procurement team actually needs to know before it puts its purchasing data into something new. The engineering detail behind them is further down, for whoever has to sign this off.
Your export files are never uploaded
Refresh files are read in your own browser. The raw export — with whatever else happens to be in it — does not leave the machine it was opened on. Only the extracted records are stored.
Only your company sees your data
Several companies run on one deployment and each sees only its own. That separation is a rule in the database rather than a filter in the screen, and it is re-checked automatically before every release.
People can only do what their role allows
Approvals, creating and retiring items, changing a committed schedule, editing configuration — each is tied to a capability, and the database refuses the write if the person does not hold it. Not hidden in the interface: refused.
Nobody signs themselves up
There is no public registration. Accounts are created by your administrator, and an address that is not on the list cannot get past the sign-in screen even with a valid password.
Backed up every day, and the restore has been rehearsed
A complete copy of production is taken daily onto separate infrastructure. The restore runs as a single transaction, so a failure rolls back cleanly instead of leaving half a system — and it has been exercised, not just documented.
For whoever has to sign this off.
The same claims, stated precisely enough to be checked. Nothing here matters to a buyer on a Tuesday; it matters once, to the person who asks the hard questions before you start.
Isolation is audited, not asserted
Row-level security applies to every table holding business data, so a query cannot return another company's rows; no code path asks the browser which company it is. An automated audit checks every table for its policy, its company column and its isolation rule as part of the deploy, and one regression stops the release. It currently reports no gaps.
Permissions are resolved server-side
Roles and capabilities are computed by the database and returned to the client, not decided by it. The sensitive write paths carry database triggers that reject the write outright when the capability is missing, whatever the interface allowed.
No third-party code in a signed-in session
The sign-in and mapping libraries ship with the application rather than being fetched from a public CDN at runtime, so a compromised CDN cannot reach a live session. A strict content-security policy pins where code, data and images may come from, and the page cannot be framed by another site.
The deploy refuses to run when a check fails
Releasing is one command, and it runs the full gate first: static checks, every unit test, every browser test on desktop and phone, and the isolation audit. Over 700 automated tests today. If any of them fails, nothing is deployed — it is not a warning that can be clicked past.
Nothing is typed into a production console
Every database change is a numbered, reviewed migration applied in order. An applied migration is never edited; a correction is a new one. The schema's history is the actual history rather than a reconstruction.
Changes reach one person before everyone
Features can be switched on per account, so a significant change is proven against real work by one willing user first. Riskier migrations run in shadow: the new path and the old one both execute, and disagreements are logged until there are none. The running version and a fingerprint of the exact code behind it are visible inside the application.