Work is built in the client's own accounts, on the client's own subscriptions, using the interfaces the client's existing software already publishes. There is no ZAAPTO platform in the middle, no runtime that has to keep being paid for, and no account that only ZAAPTO can log in to.
Where a piece of work needs a scheduler, a queue or a small database, it uses the ordinary managed services a business of that size can administer, chosen so that the running cost is visible on a bill the client already receives.
Credentials and access
Access is requested per system, named, and scoped to what the work needs. Credentials are issued by the client, held in the client's own secret storage, and revoked by the client at the end of the engagement without needing anything from ZAAPTO. Where a system supports a service account with limited permissions, that is used in preference to a person's login.
What is handed over
Source code in a repository the client owns. A written description of every scheduled job and every automatic handoff, including what it does when it fails. Instructions for turning each piece off. The specification written during scope, updated to match what was actually built.
On security claims
ZAAPTO LTD does not hold ISO 27001 certification, a SOC 2 report or Cyber Essentials certification, and will not represent otherwise. Nothing on this site is an attestation by a third party. The statements above are commitments about how work is arranged, and a client is entitled to hold ZAAPTO to them in the engagement contract, which is where commitments of this kind belong.
On the limits of a written specification
A specification describes a process as it was found. Businesses change, and software a company buys changes underneath it. Aftercare exists because of that, and its boundary is written down at the start so that neither side is guessing later.