Most vendors show a row of certification logos here and hope nobody checks what they cover. We publish the whole list instead, including the lines where the answer today is no. If any of them is a blocker for you, it is better to find out here than in month two.
Each status means what it says. By design means it is built into how the system works, not just written in a policy. Scheduled comes with a date. Not held means we do not have it.
While we move your work and while we run the system, your data is on our servers in the European Union, in a system of your own, under the DPA. When the agreement ends, you take your data out and we delete it.
Before you sign, we study your live systems under the mutual NDA to write the scope. Then we move your work into your own system on our servers, and your people sign in there.
After acceptance, your system goes live. We run it, monitor it and update it every week. Your people use it.
You have 90 days to take your data out, in open formats, free. Then we delete it and sign a certificate of deletion.
After you leave, your data is not on our infrastructure at all, and a signed certificate says so.
Breaches are stopped by mechanisms, not by policies. These controls are built into the code and the release process, so nobody can forget them under deadline pressure.
Nobody can change the main code directly, including us. A change goes in only after review, and only when every automated check passes: code style (lint), types, database schema, the full test suite and the build.
We write the tests for money, tax and stock logic before the code. We also check that the tests can fail. A test suite that can never fail is worse than none, because people trust it.
The deploy script records the exact version (commit) it published and reads it back on the next run. So anyone can see what is running without logging in to the server. To roll back, the same script redeploys a recorded earlier version. If the project’s own roadmap does not mark a release as shipped, the deploy stops until someone names it.
The person’s role is checked on the server, not only in the interface. So a restriction applies to a script just as it does to a person on screen.
Every external connection has a real mode and a test mode (a sandbox), and a new environment starts in test mode. So loading your real customer addresses cannot accidentally send them emails or shipments.
Passwords and keys are stored in settings on the server, with restricted access. The code records where a secret is kept, never the secret itself.
If a new release fails its health check, the deploy puts back the version that was running a minute earlier and stops with an error. On a client’s system, the database is backed up before every release, so the data can be restored too.
Your own assistant (Claude, ChatGPT, Claude Code or Codex) connects through MCP and signs in with OAuth. It works as the person who connected it, through the same server checks as that person’s screens, and only in the areas the person allowed: off, read, or read and change. Confirming an order or a purchase, winning a deal and posting an invoice wait for the person’s click in the system. Payments, stock moves, e-mail, deleting and settings are never open to it. It stays off until your administrator turns it on.
This list applies for as long as we run your system. Services your business already uses, such as a courier, a tax service or a marketplace, connect with your own credentials and stay yours. So does the AI assistant you connect: it works under your own terms with its provider.
| Provider | Purpose | Region | Holds your business data |
|---|---|---|---|
| Hetzner Online | Servers and storage for your system, and the offsite copy of its backups | EU | Yes |
| Google Workspace | The alex@a-systems.pro mailbox, and since 25 September 2026 the service that sends the system’s own emails | Global | What you send us by mail or at /start/, and the mail the system sends |
| Resend | Sends the scope read from /start/ by email, and is a backup sender for the system’s emails | US | Addresses and the emails themselves: a scope read, questionnaire answers and files |
| GitHub | Code storage and the merge gate | EU / US | No, code only |
| Anthropic | Writing and testing code, and reading the requirements sent for a scope read at /start/ | US | As the purpose states |
On the last row: the model is Anthropic’s Claude. It writes and tests the code, and it reads the requirements you send through the scope read at /start/, which are deleted after 30 days. If your policy restricts the use of AI tools, tell us at the first call.
For the engineer who reviews us before you sign. The architecture, the stack and the way out of each part, speed measured on real volumes, how data stays correct, security, AI access and the release process. We update it every month.
We run the system, so most of the duties are ours. A few stay yours, and it is better to name them now than to discover them during an incident.
Ideally someone who has had a bad experience with a vendor. If they have a question this page does not answer, tell us, and we will add it.