Websites

A website that reads the same record.

Pages assemble from sections, and the ones that matter are wired to the platform: bookings, products, the knowledge base, support and forms render from your own data, so the site stops being a copy of the business that someone has to keep updated.

Sections that are wired to the platform

Most website builders give you boxes to type into. These sections read the system you already run:

Bookings

The real booking flow, embedded. A visitor books a slot on the site and it lands in the calendar your team already works from.

Products

The catalogue your billing engine sells from. Change a price in the platform and reload the page.

Knowledge base

Your docs, books and chapters, published as they are written.

Support

A visitor raises a ticket from the site and it arrives in a helpdesk queue, on the record it belongs to.

Forms

The same forms engine as everywhere else. A submission can create the contact, the ticket or the deal, because the actions it fires are the platform's own.

Sessions and spaces

Bookable sessions and venue space, listed on the site with the booking flow attached.

And one honest mechanism underneath them all: a section whose module you have switched off renders nothing. The site never shows stale data from an engine that is not running.

The rest of a real site

Around the wired sections sit the ordinary ones: heroes, columns, galleries, FAQs, pricing tables, testimonials, maps, and forty-odd ready-made presets to start from. A blog with RSS. Sitemap and robots handled. A theme system of palettes, font pairings and spacing scales, set once per site.

Your own domain, verified by DNS, with the certificate issued and renewed for you.

And a gate we are prepared to lose a sale over: a page that fails its accessibility check does not publish. A missing image description is a blocked publish, not a warning you dismiss.

Sites that are meant to end

Some sites have a lifespan. A product launch, an open day, a season of classes, a recruitment push. You can run more than one site from one workspace, so a microsite is not rationed: stand one up beside your main site, give it a subdomain or its own domain, run it for its window, and switch it off when the window closes. Taking it down is a switch in settings, not a support ticket.

Two honest limits. There is no event template yet: you assemble an event site from the sections above, a hero, the session list, the booking flow, a form, and it takes an afternoon rather than a minute. And retirement is a switch you flip, not a timer you set: pages can be scheduled to publish at a time, but a site does not yet take itself down on a date.

Built by you, handed to them

A site you build for a customer does not have to live in your workspace. The transfer flow moves it to theirs: you offer it, they accept, the content copies across, writes freeze while the copy is verified, and then it cuts over. Decline, expiry and reversal are all handled states rather than hoped-for outcomes.

The event site is a product

If you run an MSP you have had this call: the client has an event in six weeks and needs a page with a booking form on it by Friday. Now it is a line on your price list. The hosting, the domain, the certificate and the booking flow are already the platform's. The afternoon of assembly and the six weeks of running it are yours to charge for, and the enquiries it takes land on a record, not in an inbox.

Build a site in an afternoon and put a booking section on it.

Make a test booking, then open the calendar.