Our own business website: a live build example

A real update to our own website

From an update request to a checked release

On 22 October 2026, we released an update to this website. The app finder was present in the prepared source, but its public address still showed Page not found. We also needed clearer website inclusions and a direct route from our service lists to the AI receptionist page.

1. Agree the change. Keep the existing design and prices, preserve the app finder and clarify which website extras need a separate quote.
2. Check the draft. The release passed 59 automated checks and its production build. We reviewed desktop and phone layouts, completed the five-question app finder and checked that its answers reached the enquiry form before submission.
3. Publish and check again. After approval, we published the update and reopened the live pages. The app finder loaded at its public address, the receptionist links reached the intended page and the website inclusions showed the agreed wording.

You can inspect the live app finder, explore the sample receptionist conversations or try the sample app review workflow. The conversations and review workflow are illustrative; they do not make calls or send customer work.

This is evidence of one update to our own website, not a client result, a response-time promise or proof of improved Google rankings. We checked the quiz's form prefill without sending a new enquiry. For your website, agree the change, its cost and the checks that show it is ready before release.

23 October 2026: from the contact form to the owner's inbox

We submitted one clearly labelled internal enquiry through the published Contact page, using an existing test contact. We matched the saved submission, its workflow run and the email received in the owner's inbox.

1. Form and CRM. The form confirmed receipt. The saved submission contained the submitted name, email, phone, business and exact message.
2. Enquiry routing. The contact-enquiry path ran and preserved the test contact's existing owner.
3. Received alert. The owner's inbox received the alert with the matching enquiry details and message. Its sender authentication checks passed.

This was a desktop check of one contact-enquiry path using an existing test contact. It is excluded from lead reporting and does not demonstrate first-time owner assignment, other forms, calendar bookings, phone notifications or every future delivery. No customer outcome or conversion improvement is claimed.

Agree the receiving record, owner and alert details for your project. Our enquiry follow-up guide explains the handoff to check before launch.

25 October 2026: checking callback details beyond the form

A form confirmation is only the first check. In a labelled internal test, the submitted callback number appeared in the form record but did not populate the contact’s standard Phone field. We added a fallback that preserves the entered number in the enquiry message and verified that it reached the owner’s inbox.

That protects callback visibility in the tested alert; it does not repair the standard Phone field, which remains under investigation. This was our own existing test contact, not a customer enquiry or evidence of AI receptionist call handling. For your project, agree which details must reach each receiving record and alert, then check them there.

1 November 2026: checking the website quote form beyond the confirmation

We sent one clearly labelled internal enquiry through our website quote form’s direct link. We matched the saved submission with the pipeline entry created by its connected workflow. The submitted callback number was present in the receiving record. The owner alert and submission-confirmation email also reached our test inbox.

This checked one submission through the form’s direct link, not a submission inside the website’s embedded form. It used our own test details and is excluded from customer-enquiry reporting. The email check used our own mailbox and alias; it does not establish delivery to other email providers. These results apply to this form and route, not other forms or AI calls.

For your website, agree where enquiries should arrive, which details must be retained and who takes the next action. Then inspect the receiving record and messages, rather than relying on the form’s success screen.

Working examples from our own website

Two working planning tools you can try

We built two small tools into this website to make buying decisions easier. One turns an app idea into a structured first-release brief; the other compares the known costs in a minute-based receptionist quote. You can use the actual tools and inspect their output. These are our own website features, not customer projects or claims of customer results.

How we checked the work

Before their release on 16 October 2026, we checked the cost arithmetic, blank and invalid inputs, setup allocation and reset. The brief checks covered plain-text output, copying, the manual-copy fallback and clearing. We also checked the layouts in a phone-sized preview, then exercised both tools on the published website using clearly illustrative inputs.

The scope of this example

The tools process their entered figures and text in the page; they do not send those entries or save them as customer records. The website's ordinary page tracking is separate. A copied brief is a planning document, and the cost result is an estimate from supplied inputs, not a quote or billing forecast.

These examples demonstrate focused browser interactions, validation and readable output. A client portal with accounts, shared records, permissions or connected business systems has additional requirements that need their own scope and tests. Start by defining one complete task and the checks that prove it works.