How it is built
You are considering handing a small company your inbox, your calendar, your CRM and your books. That is a reasonable thing to be careful about. This is how the software is actually made, with nothing dressed up.
Every software company will tell you they have tests and a deploy pipeline. That is table stakes and it predicts nothing. What actually predicts whether a platform will quietly corrupt your data is narrower: what the team does when a check passes and they are not sure it should have. Everything below is an answer to that.
Nothing ships from anyone's laptop.
There is no path from a developer's machine to your data. Changes reach production only by merging, which triggers a pipeline that assumes a short-lived cloud identity scoped to exactly what it may touch. No long-lived deploy credentials exist to be leaked. A manual deploy is an emergency procedure with its own written protocol, not a convenience.
Five independent checks have to pass before anything merges: type checking and the invariant lints, the test suite in parallel shards, the customer portal built and type-checked, the operations console built, and the agent runtime built and tested. A failure on the main branch pages a person immediately, because a broken main would silently block every deploy queued behind it.
A guard is not finished until someone has watched it fail.
A test that has only ever passed has not been tested. It has been written. And it is worse than having no test, because from that moment everyone trusts it. So the rule here is that a new test, alarm or gate must be seen failing against the broken condition it exists to catch, and the change that introduces it has to record that it was seen.
This is not aspirational. It exists because two checks shipped green while checking nothing at all. One was written to catch a circular dependency and passed happily while producing output containing exactly that, because the detection lived in a different function than the one being called. The other had been validating the whole system's configuration against placeholder values for weeks. Both were found by deliberately breaking the thing they were meant to catch.
Both of those were ours. A vendor who has never found a bug like that in their own tooling has either been lucky or has not looked. We would rather you knew which kind of company this is before you trust it with your books.
The unglamorous parts.
We check the running system still matches the code
Code and reality drift apart quietly. A scheduled detector compares what is deployed against what the repository says should be deployed, and pages a person when they disagree.
Security primitives are copied, never reimplemented
Where a security check has to exist in two places, it is a copy rather than a second implementation, and a test compares their real behaviour. Two subtly different fences are worse than one.
Numbers come from the source, never from memory
Every cost, price and quota is read from the system that owns it and validated before use, including inside code comments. A number that was true when it was written down becomes a lie without anyone touching it.
Least privilege, concretely
The isolated machine that runs code for you is allowed to write log lines. That is the complete list. It cannot read a secret, reach the database, or touch file storage.
Every count on these capability pages is read from the product's own catalog when the site is built. When a role or a workflow is added, these pages change with it. When one is removed, the claim disappears rather than lingering. We do not maintain a marketing number by hand for the same reason we do not maintain a price by hand.
And who is watching it at 3am?
Building it carefully is one thing. Noticing when it goes wrong at three in the morning is another.
How it is watchedAll areas