Most vendors put a row of certification logos on this page and hope nobody checks the scope on them. We would rather publish the whole list, including the four lines where the honest answer today is no. If any of those four is a blocker for you, it is better that you find out here than in month two.
Four states, and they mean what they say. By design is a property of how we build, not a policy we wrote down. Scheduled carries a date. Not held means not held, with no adjective in front of it.
Every hosted vendor's security page is an argument about how well they guard your data forever. Ours only has to hold for a few months, because after that it is not ours to guard.
We read your live systems to write the spec, and we run a build environment on our infrastructure.
The system is already on your server. We hold time boxed access to keep building and to teach your person.
Access is removed on the date in the contract. Certification is signed by both sides and lists every account closed.
After handover your data is not on our infrastructure at all. No vendor with a subscription business can write that sentence.
Policies do not stop breaches, mechanisms do. These are the ones that sit in the code and in the pipeline, where they cannot be forgotten under a deadline.
Nobody can push straight to the main branch, including us. A change enters through review with lint, types, schema, the full suite and the build all green, or it does not enter.
Money, tax and stock logic is written test first. We also check the suite can go red: a green build that is structurally incapable of failing is worse than no build, because it is trusted.
The deploy script writes the exact commit it published and reads it back on the next run, so what is running is answerable without opening a shell. Rolling back is that commit redeployed by the same script. A release that the project's own roadmap does not call shipped stops the deploy until somebody names it.
Row level security means a role restriction holds even for a direct query, not only for a screen. A read only user is read only to Postgres itself.
Every external system has a real mode and a mock mode, and a new environment starts in mock. Loading your real customer addresses cannot accidentally email or ship to them.
Credentials live in environment configuration on the host with restricted permissions. The repository records where a secret lives, never what it is.
The list applies to the build phase. After handover you choose your own, and this table stops being about you.
| Provider | Purpose | Region | Holds your business data |
|---|---|---|---|
| Hetzner Online | Compute and storage for the build environment | Germany | Yes |
| Supabase | Managed Postgres and authentication | EU region | Yes |
| Resend | Transactional email from the system | EU routing | Addresses only |
| GitHub | Source control and the merge gate | EU / US | No, code only |
| Anthropic | The AI engineering that builds the system | US | No, structure and code only |
On the last row, plainly: we do not send your business records to a model. What goes out is schema, code and the shape of a problem. If your policy forbids even that, say so at the first call and we will scope the build differently.
Handing you the keys means some of this genuinely becomes yours. Better to name which parts now than to discover it during an incident.
Preferably the person who has been burned by a vendor before. If they come back with a question this page does not answer, that question belongs on it, and we will add it.