Security & reliability
Your designs are yours, and the software is built to keep them that way.
One company’s work, kept apart
Several companies use the same application. Keeping their work separate is the first thing the software has to get right, so it is enforced in more than one place.
A workspace per company
Your designs belong to your company and are visible only to the people your administrator has invited. There is no shared pool of designs and no public gallery.
Separation the database enforces
Every design, report and file carries the company it belongs to, and the database applies that boundary itself — not only the application code above it. A query that forgets to filter returns nothing rather than someone else’s work.
It refuses to run without it
If the application is ever connected to its database in a way that could bypass that boundary, it stops at start-up instead of serving. Protection that is switched off without anyone noticing is the failure worth designing against.
Checked on every change
Automated tests deliberately ask for another company’s data and must come back empty. They run against a real database every time the software changes, so isolation is re-proven rather than assumed.
Who gets in, and what is recorded
- Invitation only
- People reach your workspace because your administrator invited them by email address, and lose access when the administrator removes the seat.
- We hold no password of yours
- Sign-in is handled by a specialist identity provider. There is no password column in our database, because there are no passwords in it.
- An audit trail that cannot be rewritten
- Changes to your account and its branding are written to an audit log the running application is permitted to add to and not permitted to alter or delete.
- Your reports carry your brand
- A report from your account shows your logo and your company details. Our brand does not appear on your customer’s copy.
Reliability
Practice you can check, not a number we picked.
Anyone can print an availability figure. What is worth knowing is what happens to the software before it reaches you, and every one of these runs on every change:
- Types, tests and a production build run on every change, and a failure blocks it.
- The engine’s outputs are pinned by tests, so a number cannot move quietly — a change has to be deliberate and reviewed.
- The tenant-isolation suite runs against a real database, not a stand-in.
- The application is built as a self-contained container and booted on every change, so it stays movable between hosts rather than tied to one.
- It is served over HTTPS with a strict set of response headers, including a content security policy.
What we do not claim yet
We publish what is true on the day it is published, and nothing else. So, plainly:
- No certifications. We hold none today. If that changes, this page will say which, and who issued it.
- No uptime or recovery figures. We will not publish an availability or restore-time number before we have measured it on our own system. When we have, it goes here.
- A privacy policy is being prepared with our lawyers. Until it is published, nothing on this website collects personal information — there is no form here, only an email address.
If your own review process needs answers we have not put on this page, ask. A question we cannot answer honestly yet is one we would rather tell you about than write around.
Questions from your security review?
Send them over. You can also read what the application does and what it costs on the pricing page.