Getting Started
Ten questions to ask any platform (including us)
Take these into every vendor evaluation. Our answers are below, each linked to its documentation. We suggest asking everyone else for theirs in writing.
Platform demos all look the same. The differences live in questions that only come up later — during the audit, the incident, the migration, the customer's security review. Here are ten worth asking before you commit, with our answers. Each answer links to the documentation that backs it, because an answer you can't verify is a slogan.
1. “If we order you to delete our audit trail, will your system refuse?”
Why it matters: the moment an audit trail can be deleted on request — by you, by an admin, by a compromised account — it stops being evidence.
Our answer: yes, it refuses. The retention cleanup routine has the compliance-critical history tables — the audit log and every record- and field-level change and access log — hard-excluded at the code level. Asking it to delete them doesn't get a warning; it gets an error. The same discipline runs through the page system: the pruner that trims editing history is written to never delete the record of what was published. Tenant logging.
2. “Can you prove — not promise — that your AI never accessed something it shouldn't have?”
Why it matters: every platform will promise this. Almost none can demonstrate it for a specific query on a specific day last quarter.
Our answer: every AI retrieval logs a cryptographic proof of exactly what that user was permitted to see at that instant, into a tamper-evident chain — and the permission rules themselves keep full version history, so any past decision can be replayed and given a verdict. “As of then” catches violations; “as of now” catches drift. Replayable authorization.
3. “Does your access log distinguish an AI reading a field from a human viewing it?”
Why it matters: “who saw this?” and “did an AI ingest this?” are different questions with different regulatory weight, and a log that can't tell them apart can't answer either.
Our answer: yes — field-level access logging records the kind of access: a human view, an export, a print, an API read, a report read, or an AI read, each its own category. Down to the individual field. Tenant logging.
4. “What happens if a connection ever points at the wrong customer's database?”
Why it matters: on shared-table platforms this question doesn't even parse — there is only one database, and isolation is a WHERE clause. Where separate databases exist, misrouting is the nightmare scenario.
Our answer: every tenant database knows its own identity, and a tripwire check refuses to serve a connection whose claimed identity doesn't match — the request fails loudly with a misconnection error naming both sides, instead of quietly serving someone else's data. The isolation model.
5. “If we encrypt a field, list every feature we must remember to exclude it from.”
Why it matters: the usual answer is a checklist — search, reports, AI, exports, integrations — and the checklist is exactly where breaches live, because someone forgets one.
Our answer: the list is empty. A database constraint makes it physically impossible for a secure field to hold readable text alongside its encrypted envelope, and search and AI only ever consume the readable side. Nothing downstream needs to exclude it, because there is nothing to exclude. Secure fields.
6. “Show us every customized page with an upstream update waiting — right now.”
Why it matters: template platforms lose track of forks. The honest competitor answer is “customers find out when something looks broken.”
Our answer: one query. Every fork records the exact version it diverged from, so the platform can enumerate, at any moment, every customized page whose baseline is behind the current release — with the original, the customization, and the new version side by side, ready for a block-level merge that flags conflicts instead of overwriting. Templates, forks, and upgrades.
7. “When our AI assistant hits its daily limit, whose code enforces it?”
Why it matters: if the answer is “the AI is instructed to stop,” the limit is a suggestion. Instructions are what misbehaving software ignores first.
Our answer: the platform's, at the moment each action is queued — outside the assistant entirely. A hypothetically malfunctioning assistant is still mechanically capped, and everything it wants to do waits in a human approval queue besides. GoClaw in depth.
8. “Can someone probe your API to learn which accounts and apps exist?”
Why it matters: APIs that answer “not yours” differently from “doesn't exist” are enumeration oracles — reconnaissance tools handed to attackers for free.
Our answer: no. Routing and lookup paths deliberately return the same nothing for “not yours” and “not real,” a design rule written into the code as a comment future engineers can't miss. API overview.
9. “Can our customers take everything and leave?”
Why it matters: the platforms most eager to hold your data are the ones you most need an exit from. Data ownership you can't exercise isn't ownership.
Our answer: yes — an authorized account export provides that organization's records and related artifacts with checksums. A whole-SaaS backup is separate and may contain multiple organizations; it is not an individual organization's export. It is a standing owner-only feature available at any time, not an off-boarding concession (Back up and download your data). Builders can separately export the versioned JSON and JSON Schema definitions for pages and workflows. Customer-owned S3 restore bundles can preserve the database, files, schemas, settings, manifest, and checksums outside BuildWithHQ. For an enterprise relocation or a company shutdown, the application can run in AWS, Azure, another cloud environment, or a virtual machine using the continuity runtime. Business continuity and application portability.
10. “When third-party code touches our data, can you show us exactly what ran?”
Why it matters: “an integration accessed your data” is not an answer. Which version, doing what, reaching where is an answer.
Our answer: extensions run under manifests frozen and fingerprinted at release — endpoints, network reach, everything. Every data access lands in a tamper-evident ledger with that fingerprint attached; every network attempt is logged as allowed or blocked, host and port included. The audit trail names the exact code. Appliances and their endpoints.
Every answer above is documented on this public site — no NDA, no sales call, no “let me check with engineering.” We'd suggest asking the same ten questions of any platform you're evaluating, and asking for the answers in writing. The ones who can answer will be glad you asked.
Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.