Skip to updates
DevLaunch home

Approved launches, website restores and client handovers

Publish approved client websites, connect domains, restore earlier versions, review GitHub changes, add enquiry alerts and prepare a handover.

Build 1.7 brings the steps between client approval and a finished website launch into one update. All six additions are included in one complete source download. These are screenshots of the real Build interface with fictional Cedar Plumbing and Juniper Studio examples. Hosting, domain, GitHub and notification services are simulated for the examples.

  • Publish the saved version your client approved.
  • Check and connect a domain for each client website.
  • Restore an earlier website version while retaining saved enquiries.
  • Review incoming GitHub text changes before importing them.
  • Add optional email or webhook alerts for new enquiries.
  • Download ownership, support and maintenance details in a client handover ZIP.
The approved version and its launch details stay together. Fictional client and local hosting example.

Put the approved version live

Choose an approved client review in Ready → Client launch, then publish that saved version. Later edits stay in the working draft until you build, review and publish them.

This gives the approval a practical purpose: you know which website version the client agreed to put live. Use your hosted Build address when sharing a review with a remote client.

Client approval stays with the saved preview version. Example names are fictional.

Give each client website its own address

Use a domain managed in the Cloudflare account connected to the project. Enter the client hostname and check its setup before connecting it. Build checks the account and existing DNS or website connections.

Confirm the connection when the checks pass. Cloudflare may need time to activate the certificate; check the finished HTTPS address before sharing it with the client.

Check the website address before confirming its connection. Domain services are simulated in this example.

Return to an earlier website version

Release history lists the versions you published and restored. Choose an earlier version when you want its website layout or behavior back.

Restoring the website retains its live storage, including saved contact enquiries. Review changes to how your site stores data before restoring; a website restore does not reverse those changes.

A restore appears in the history alongside earlier launches. These are actual launches and restores of the fictional example website.

Bring your developer’s GitHub changes back

Connect GitHub using the project’s existing export controls, then compare the saved repository. Review incoming files, keep local work or choose the GitHub version. Conflicting edits need an explicit choice.

Importing updates the working project. Rebuild its preview and review the result before publishing it. This import reviews text files; use the usual asset workflow for images and other binary files.

Review file decisions before applying the import. This is a fictional repository served by a simulated GitHub connection.

Know when an enquiry arrives

Add an optional email destination through your verified Resend sender, or send the enquiry to your automation’s webhook address. Save the settings and publish an approved version to activate them on the website.

Check alert delivery status and retry recent failed alerts after correcting the destination. The contact form keeps its saved enquiry even when an alert needs attention.

Delivery status comes from the website’s actual alert queue. This example delivered to a local simulated webhook.

Your form keeps its saved enquiry

The existing working contact-form kit still provides a saved receipt. Build 1.7 connects that saved enquiry to the optional alert workflow.

Use the visible form when checking a launch, then confirm the receipt and its alert status. This checks the path a visitor will actually use.

A real submission to the locally hosted example website. The name, email and enquiry are fictional.

Finish with a useful client handover

Record who owns the domain and hosting, the support email, maintenance contact and useful notes. Download the client handover ZIP to keep those details with the live address and release history.

The handover excludes credentials and private review links. Use the existing Source export separately when the client also needs the website’s source files.

These details are included in the downloaded client handover. Fictional client and agency information.

Try it in your own workspace.

  1. Download the complete Build 1.7 update and follow the included upgrade guide, preserving your projects, private settings and credentials.
  2. Open a built project in Ready → Client launch. Record the client details and optional alert destination, save them and connect your own Cloudflare account.
  3. Create a fresh client review, obtain approval, choose that approved version and publish it.
  4. Check the domain setup, confirm its connection, test the visible contact form and review alert delivery. Try a second launch and restore on a disposable project.
  5. Connect GitHub through the project’s export controls when needed, review incoming changes and rebuild the preview after importing. Download and check the client handover before delivery.