Getting Started

What makes BuildWithHQ different

Seven differences you could verify in the database schema — and what each one means for your day.

Every app-builder platform says it's secure, flexible, and AI-powered. So this page makes a different kind of argument: each difference below is a structural property of how the platform is built — something an auditor could verify by reading the database schema, not a policy that depends on everyone remembering to follow it. For each one: what it is, and what it does for the people using it.

1. Every application gets its own databases — three of them

Most platforms put all customers in shared tables and separate them with a filter column. Here, every application you create is provisioned with three physically separate databases: live data, immutable history, and AI. Each carries its own identity, and a built-in tripwire refuses to serve traffic if a connection ever points at the wrong database — misrouting fails loudly instead of leaking quietly.

What this means: database routing separates SaaS applications. Customer organizations inside an application still share that application's databases, with server-enforced account, DataRole, Location, and record permissions. Separate databases help with operational boundaries, but shared hardware still needs capacity planning.

2. One security layer, inherited by everything

Everything in an application — contacts, tasks, conversations, files, events — is anchored to a single universal record identity, and every read flows through one security layer that evaluates role, location scope, and capability. Features don't implement their own access checks; they inherit the one model. The inbox has no inbox security code. AI insights inherit visibility from their source records. Even a user's favorites silently drop a record the moment access is revoked — the bookmark reads through the same layer as everything else.

Easier because: builders configure permissions once and every feature — including ones that ship next year — obeys them. There is no per-feature permission matrix to keep synchronized, and no new feature can introduce a new class of leak, because no feature has an access path of its own.

3. Security decisions you can replay

The permission tables keep full version history, and every AI data retrieval logs a cryptographic proof of exactly what the user was allowed to see at that instant — into a per-tenant, hash-chained record that can't be silently edited. Any past access can be replayed: re-derived under the rules as they stood then, or under today's rules, and compared against the proof.

Easier because: when a customer or auditor asks “did the AI ever see something it shouldn't have?”, the answer is a procedure with a verdict, not a promise. No other builder platform we're aware of can rewind a security decision and check it.

4. Encryption that changes what's physically possible

Fields marked secure are encrypted with per-tenant keys — and the database itself enforces, by constraint, that a field value holds either readable text or an encrypted envelope, never both. Search indexing and AI read only the readable side, so an encrypted value isn't “filtered out” of search and AI — it was never there to filter.

Easier because: protecting a sensitive field is one checkbox with no follow-up checklist. There is no list of downstream features someone must remember to exclude it from, because the exclusion is a property of storage, not of each feature's good behavior.

5. Customize everything — and still receive upgrades

Template platforms force a choice: stay stock and get updates, or customize and be stranded. Here every block on every page carries a stable identity, forks record the exact baseline they diverged from, and upgrades arrive as block-by-block choices merged three ways against your customizations — with conflicting blocks flagged for a human decision instead of silently overwritten. Premium bespoke work is excluded from automated upgrades entirely, by classification.

Easier because: builders customize on day one without mortgaging every future improvement, and tenants can restyle their own pages knowing an upstream release will never flatten their changes.

6. AI that was designed inside the rules, not bolted on after

The permission model has an AI-specific read capability as a first-class flag — meaning a role can see data itself while excluding that data from AI entirely. On top of that sit the rest of the controls this documentation covers: assistants that propose while humans approve, action budgets enforced by the platform rather than the AI's own logic, full attribution on everything AI produces, and scored Harness Pack gates before an AI behavior serves customers.

Easier because: you can adopt AI feature by feature, user by user, with the same governance answer every time — instead of choosing between “no AI” and “trust the AI.” And when AI runs on partner or dedicated hardware, the data rules travel with it, because they live in the platform, not the model.

7. A history that can prove itself

Every application's audit trail is append-only and hash-chained — tampering is detectable by arithmetic, not just forbidden by policy. Third-party extensions operate under manifests frozen at release, with every network attempt logged as allowed or blocked and every data access written to a tenant-verifiable disclosure ledger. And because the history is append-only and stored analytics-grade from birth, each tenant can export their own history to their own Snowflake warehouse — their data staying theirs all the way into their own BI stack, with no builder-side path to warehouse it for them.

Easier because: disputes end with evidence, security questionnaires get short answers, and tenants get warehouse-scale analytics over their own history without their data ever becoming someone else's dataset — a data-ownership answer most platforms can't give.

To pressure-test these claims — ours and anyone's — take the ten questions into your next vendor evaluation.

The same differences, from each chair

Capability review: 2026-09-14. For exact current technical availability, use the generated API Map and first-class module inventory.