How Customer-level page forks fits into BuildWithHQ
BuildWithHQ separates the application engine from each tenant’s page configuration. A SaaS owner can publish a base page for all customers, then allow selected customers to fork that page into a private tenant override with its own JSON, history, version, and adoption state.
Fork creation
The SaaS owner marks which pages may be customized at the tenant level.
The fork records the base page version and the exact base JSON from which the customer started.
The tenant receives an isolated page definition that can be modified without changing other customers.
The platform prevents accidental duplicate active forks for the same tenant and page.
Ongoing base development
The SaaS owner can continue improving the master page for new and standard customers.
A tenant fork remains stable when a new base version is published.
The platform can compare the old base, new base, and tenant-modified page.
A merged page can be applied when the customer chooses to adopt selected upstream improvements.
History and recovery
Before adoption or replacement, the prior tenant page is retained.
The earlier base version and base JSON remain available for comparison.
Every adopted or edited page advances the tenant page version.
History supports returning to a prior tenant state without redeploying the application code.
Commercial value
Agencies can give important customers custom screens and workflows without creating separate code repositories.
Core product improvements do not silently break customized customer experiences.
One SaaS product can support many tenant variations through configuration rather than branching the application code.
Tenant-specific layouts and workflows can become a paid implementation or enterprise-customization offering.