TVS
From Demo to Live: The Infrastructure Behind a TVS Website
Every TVS website starts as a demo hosted on TVS infrastructure before a single invoice is raised. The engineering behind that demo — tracking, versioning, transition to production — is more involved than it looks from the outside.
The TVS model is build-before-billing. A prospect does not receive a proposal document, a quote, and a timeline. They receive a working demo of their actual site — their name, their photography, their services, their content — before they are asked for a decision, and certainly before they are asked for money.
This creates a technical requirement that most web agencies never face: TVS has to own and operate the hosting infrastructure for every prospect’s demo, without knowing in advance whether that prospect will become a client. The demo must be fast, tracked, editable, and transferable to production the moment the client says yes.
The engineering behind that pipeline is what this article describes.
The demo hosting layer
Every TVS demo site is hosted on TVS-controlled infrastructure as a subdirectory of the TVS demo domain. The URL structure places every demo under a shared domain root, with the client’s unique slug as the subdirectory. This is intentional — it means every demo site inherits the domain’s SSL certificate, nginx configuration, and performance settings from day one, with no per-client server provisioning required.
The demo site is a fully static Astro build — the same framework, the same code quality, the same technical output that the production site will eventually be. It is not a mockup or a preview image. It is a real, deployable website running on real infrastructure, with schema markup, correct canonical URLs for its demo location, structured data, and all the SEO implementation the final production site will carry.
One deliberate difference: every demo carries a noindex directive. The demo URL is not the client’s production domain, and it should never be indexed by Google. The meta tag and robots.txt both enforce this. When the site transitions to production on the client’s own domain, both are removed.
The tracking layer
When a prospect receives a demo link, TVS needs to know what happens next. The demo site contains a visit beacon — a small script that fires once per page per session, recording which pages the prospect viewed and in what order. This data flows back to the TVS audit platform in real time.
The tracking is session-aware — it does not fire on every page reload, only once per page per session — and it is tied to the demo slug so the data routes to the correct client record in the audit platform. The beacon is passive. There are no cookies, no identifiers, no cross-site tracking. It simply confirms: someone visited this page, in this session, on this demo.
The intelligence this creates is practically useful. When a prospect calls back after seeing a demo, TVS already knows which pages they spent time on. A prospect who looked at the services page twice and opened the contact page is a different conversation from one who bounced from the home page. The demo is not just a sales tool — it is a lead qualification instrument that generates data before the first conversation.
The data-tvs-slug attribute on the site’s root HTML element identifies the demo to the tracking infrastructure. This attribute is set at build time, unique per client, and is what allows the platform to route beacon events correctly across dozens of concurrent demo sites.
The client garage
Every demo lives inside a client garage on the server — a structured directory containing the original build, a versioned history of every edit made since deployment, active workspaces for any in-progress edits, and a metadata file that records the client’s status, edit credits, and the state of their record in the admin platform.
This versioning architecture is what allows TVS to offer AI-assisted editing of live demo content. When a prospect asks to see their tagline changed, or wants to swap a photograph, or wants to see a different layout for their services section — that edit is applied to the demo through the TVS editing workflow, previewed in a sandbox before it goes live, and recorded as a version in the garage. No version is ever deleted. Every state the demo has been in is recoverable.
The garage is created at the same time as the initial demo deployment. The onboarding script that provisions a new demo also creates the garage structure, registers the client in the audit platform, and validates that the demo URL and the admin record are linked correctly before returning. These happen as a single atomic operation — there is no state where a demo is live but the garage does not exist.
The transition to production
When a client confirms they want to proceed, the demo they approved becomes the production site. This is not a rebuild. The same Astro codebase, the same components, the same content — redeployed with a different set of environment variables and a different target.
On the demo, the site’s URL is the TVS demo domain with the client’s slug as a subdirectory. Navigation links, image paths, canonical URLs, and the sitemap all resolve relative to this subdirectory. On production, the site lives at the root of the client’s own domain. Every path resolution must be updated automatically.
The environment variable system handles this without touching any code. The base path and site URL are injected at build time from environment variables — the same codebase builds correctly for the demo subdirectory or for a root-domain production deployment depending on what variables the build script supplies. This is why the withBase() utility is mandatory throughout every TVS site — every internal link and asset path is resolved through it, making the same source code deployable to two completely different URL structures without modification.
On production promotion, the build is pushed to Cloudflare Pages on the client’s domain. The noindex meta tag is removed. The robots.txt is updated from blocking all crawlers to allowing them. The sitemap is submitted to Google Search Console. The Google Business Profile is updated to link to the new domain. These steps happen in a defined sequence — not all at once, and not out of order.
The contact form problem
A contact form is the most consequential element on any service business website, and the hardest to get right across the demo-to-live transition.
On the demo site, any contact form submission must not go directly to the client — the client has not yet engaged TVS, may not know the demo exists, and certainly should not be receiving form submissions from a site they haven’t approved. Demo form submissions route to the TVS audit platform, which logs them and alerts the TVS team.
On the production site, the inverse is true. Every form submission must reach the client reliably, immediately, and with the full content of the submission preserved. A missed lead from a contact form is a cost to the client’s business — the person who submitted it will not fill it in again. The form infrastructure must be robust: server-side submission handling (not client-side JavaScript that fails in restricted environments), spam filtering that blocks bot submissions without requiring the client’s customers to solve puzzles, POPIA-compliant data handling for South African clients (the form submission is personal information under South African privacy law and must be handled accordingly), and a confirmation to the submitter that their message was received.
Email delivery is not as simple as it sounds. A form submission sent from a VPS via a poorly configured mail server will be silently discarded by Gmail, Outlook, and most South African business email providers before the client ever sees it. The TVS mail infrastructure is configured specifically to pass SPF, DKIM, and DMARC validation on outbound form notifications — the technical sender authentication protocols that determine whether an email arrives in the inbox or is dropped by the receiving server without notification.
The form works when none of this is visible. When it goes wrong, the failure is invisible — the client does not know a submission was lost, and the prospect does not know their message was never received. Getting it right from day one is not optional.
TVS manages the full deployment pipeline for every site it builds — from demo to production, tracking to transition, hosting to mail delivery. If you want to understand what a properly deployed website looks like for your business, speak to us.