# Executive transport: a hardened launch, then a tested Astro rebuild > Source: https://redactlabs.ca/case-studies/03-executive-transport-web-build/ > Machine-readable Markdown of this page (also served at this URL under `Accept: text/markdown`). > A Toronto executive-transportation company launched on our hardened edge in the summer of 2026 as nine hand-edited HTML pages, and its untested booking path broke silently for about three weeks. After the fix, the booking funnel got end-to-end tests. In September we rebuilt the site in Astro, deployed from CI, with staged releases and automatic rollback, and cut its JavaScript from 980 KiB to 216 KiB. **Industry:** Executive transportation, Toronto **Engagement:** Website rebuild + managed hosting **Duration:** Summer 2026 launch; September 2026 rebuild **Published:** 2026-07-14 **Updated:** 2026-09-23 --- ## Evidence packet Client anonymized; proof points are drawn from the build record, the CI test suite, and the production audit. ### Operating constraints - The live booking line is revenue-critical — the site could not go dark during cutover. - The rebuild had to match the live site page for page before it could replace it. - The booking path had already failed silently once; nothing could ship without a test on it. ### Artifacts produced - **Launch edge (summer 2026)**: Strict Content Security Policy, HSTS and the full secure-header set, plus an llms.txt manifest and an MCP endpoint, on the four-Worker (edge / form / logger / email-consumer) pattern from day one. - **E2E funnel suite**: End-to-end tests that exercise the booking funnel on every deploy; a failing test blocks the release. - **Astro rebuild (September 2026)**: The nine hand-edited pages rebuilt as an Astro project, deployed from CI, and checked page by page against the live site before cutover. - **Staged rollout**: Releases go out in stages and roll back automatically when a gate fails. ### Verification notes 1. Before cutover, every page of the Astro build was checked against the live site. 2. Every release is gated on a mobile Lighthouse comparison against the live site before it reaches customers. 3. The booking funnel is covered by end-to-end tests that must pass before any deploy reaches production. 4. Header posture verified against an external scanner after the CSP and secure-header rollout. ## The problem A Toronto executive-transportation company — a fleet business whose bookings come in by phone and web — launched its website on our hardened edge in the summer of 2026. The edge was right from day one: a strict Content Security Policy, HSTS and the full secure-header set, plus an `llms.txt` manifest and an MCP endpoint for AI agents. The site behind it was not. It ran as nine hand-edited HTML pages, copied into place on each deploy, and nothing tested the booking path end to end. That gap showed. The booking form wasn't sending its Turnstile token, so the booking path broke, silently, for about three weeks around the launch before it was caught and fixed. The brief for the rebuild was not "make it prettier." It was: make the site something that can be *operated* — safely changed, measured, and trusted — without the owner holding their breath every time. ## The constraint Three constraints shaped the rebuild. 1. **The booking line is revenue.** For an executive-transport operator, the website's booking path is a sales channel, not a brochure. The cutover could not take the site dark. 2. **No visible change.** The rebuild had to match the live site page for page before it could replace it. 3. **The booking path had already failed once.** Nothing could ship without a test on it. ## The approach ### First, a test on the booking path After the fix, the booking funnel got end-to-end tests, and a failing test blocks the deploy: if the booking path breaks, the release does not ship. That is the largest difference between the site at launch and the site now — not how it looks, but that it can be changed without fear. ### The rebuild, checked against the live site On September 23, 2026 the nine hand-edited pages were replaced by an Astro build, deployed from CI. Before cutover, each page of the new build was checked against the live site, so the switch changed how the site is built, not what visitors see. ### Staged releases Releases now go out in stages, with automatic rollback. Each release is compared against the live site on mobile Lighthouse before customers see it, and one that is markedly slower, or less accessible, is rolled back automatically. ### Less JavaScript The same day, a second release cut the JavaScript in the build from 980 KiB to 216 KiB. ### Already in place at launch The strict CSP, HSTS, the secure-header set and the agent surface were there from the launch, so they aren't counted as outcomes of the rebuild. The agent surface is an addition, not a visibility lever: Google Search ignores AI text files and reads the pages themselves, which is why the pages carry the same facts. ## The outcome - **Front-end**: nine hand-edited HTML pages → an Astro build, deployed from CI. - **Booking funnel**: untested, and silently broken for about three weeks → tested end to end; a failing test blocks the deploy. - **Releases**: one-shot deploys → a staged rollout with automatic rollback. - **JavaScript in the build**: 980 KiB → 216 KiB. The site the owner has now can be operated: changed on a pipeline, measured on every release, and trusted on the one path that brings in the work. ## What we'd say to another operator A hardened edge protects your visitors; it doesn't notice when your booking form stops working. If your website is hand-edited HTML, the risk isn't that it looks dated — it's that nobody can change it safely. The first upgrade is not a new design; it's a tested booking path, a real build step, and staged releases, so that the next change is a routine deploy instead of a held breath. The design follows from there. ## The evidence - **Front-end**: Nine hand-edited HTML pages, copied into place on each deploy → Astro build, deployed from CI - **Booking funnel**: Untested; it broke silently for about three weeks → Tested end to end; a failing test blocks the deploy - **Releases**: One-shot deploys → Staged rollout with automatic rollback - **JavaScript in the build**: 980 KiB → 216 KiB