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.
What happens when you ship an update
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.
Two kinds of fork
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.