Trust & Security
Data lifecycle, residency, and portability
How customer data is isolated, exported, backed up to customer-owned storage, and assigned to an enterprise deployment.
SaaS databases and customer organizations
Each SaaS application has its own core, AI, and logs databases. Customer organizations inside that app are tenant accounts (AppAccounts); they do not each receive another database set. Server-verified account identity, DataRoles, Locations, and record permissions keep organizations separated within the app.
An organization export must include only that account's authorized data. A full application database backup is a different operation and can contain multiple organizations; it must never be handed to an individual organization as its account export. See Tenant Data Security for the permission model.
Export at any time
The account owner can run an export whenever needed: for a backup, an audit, analysis in another system, migration work, or to build an independent replacement system. The export includes customer records, files, AI data, operational history, and audit history, plus a manifest and checksums used to verify completeness. See Back up and download your data.
Customer-owned backup storage
Customers can keep restore bundles in their own Amazon S3 storage. A bundle can contain the customer database, uploaded files, application schemas and settings, a machine-readable manifest, and checksums. The destination remains under the customer's control, including bucket access, retention, versioning, and Object Lock when the customer enables it.
BuildWithHQ uses limited backup-only access for delivery to the selected bucket. The backup destination is not treated as a general-purpose BuildWithHQ storage account, and BuildWithHQ does not rely on the customer sharing an interactive cloud login.
Residency and enterprise deployment
For enterprise customers, BuildWithHQ workloads can be placed in an agreed AWS or Azure environment, including a customer-approved cloud or virtual-machine deployment. The selected region, operating responsibilities, retention requirements, and recovery objectives are recorded in the enterprise order and operating plan so they can be reviewed before deployment.
Residency, deletion windows, retention periods, RPO, and RTO can vary by deployment. BuildWithHQ documents the values that apply to the customer's environment in the applicable service terms or enterprise operating plan rather than implying one unpublished number applies everywhere.
Cancellation and deletion
Before closing an account, the owner can run a current export and verify its checksums. Cancellation stops future renewal at the end of the paid period; the retention and deletion schedule that applies afterward is the schedule stated in the customer's service terms or enterprise agreement. A customer should not depend on a post-cancellation recovery window as its backup plan.
If BuildWithHQ shuts down
The continuity plan is designed to preserve more than raw data. BuildWithHQ will release the managed API code and the JSON interpreter needed to run exported application definitions. A customer application can then be restored in a cloud environment or on a virtual machine using that customer's isolated database, files, schemas, settings, and application definitions. See Business continuity and application portability for the complete recovery model.
Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.