The page editor is a drag-and-drop canvas backed by a structured document, not a pile of generated markup. Anything you can arrange visually you can also open as JSON and edit directly, which means the visual layer never becomes a wall you can't see past.
The visual canvas and the JSON view are the same document. Designers work in one, developers work in the other, and neither has to undo the other's work.
Arrange blocks, bind them to data, and set component properties without writing markup.
Open the underlying page document and edit it directly when that is faster or more precise.
Work on a draft without affecting what customers see, then publish deliberately.
Every save is a snapshot. Restore any earlier version of a page without a deployment.
The modules that ship with the platform and the modules you invent are the same kind of object. A custom module gets the same tenant isolation, location scoping, workflow triggers, page bindings, search, logging, and AI controls as the built-in ones — you are not building on a lesser tier.
Every business object is a record, which is why permissions, custom fields, relationships, and logging work identically across modules you didn't write.
Text, numbers, dates, booleans, JSON, and relationships, with validation defined alongside the field rather than in each form.
Mark a field as encrypted and it stops appearing in search and AI retrieval automatically, because the searchable value is simply not there.
Link records across modules so a conversation, a task, and an invoice can all point at the same customer without duplicating it.
This is the feature that quietly removes the largest share of your support queue.
You publish a base page. Every customer sees it. Then one customer wants two extra fields and the panel reordered — the kind of request that is too small to justify a code branch and too persistent to ignore.
On BuildWithHQ, that customer forks the page. The fork is theirs: it has its own JSON, its own version history, and its own adoption state. Nobody else's version of that page changes. Your codebase does not gain a branch. Your support queue does not gain a ticket.
When you publish a new version of the base page, forked customers are not silently overwritten and are not silently stranded. The fork records what it changed, so the customer can see the difference between their version and the new base, adopt the update, or stay where they are. If they adopt it and dislike the result, they roll back.
A fork created by the customer for themselves is self-service and free. A fork created by you, for one customer, as paid work is tracked as a sellable item with its own entitlement — so custom work you were doing for free becomes something you can quote, bill, and end.
No. A fork is a separate document with its own history. Your update does not overwrite it, and the customer sees what changed and decides whether to adopt it.
Yes. Forking is a permission, not an automatic entitlement. You decide which customers can customize which pages.
First-class. It edits the same document the canvas edits, and changes made either way are saved and versioned the same.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docs