This was launch week. The kind of week where months of planning, architecture, and incremental delivery converge into a single decisive moment — and where two production go-lives, one for our own new company website and one for a major enterprise client, run in parallel through the same seven days. Twenty-three items shipped to Done across three projects.
The headline event was the launch of our rebuilt company website at thecodeabides.co.uk. After weeks of foundational work — Azure Static Web Apps provisioning, the .NET 8 isolated-worker Functions backend, Resend transactional email, Cloudflare Turnstile bot protection, full UK GDPR compliance documentation, and a security-first architecture — this was the week to put it through its paces and pull the trigger. Phase 6 end-to-end testing covered the lot: a full Lighthouse performance pass against every page (Performance, Best Practices, SEO targets all met), a securityheaders.com grade test, an automated accessibility audit using Lighthouse, axe DevTools, and WAVE in combination, then a thorough manual accessibility audit covering keyboard-only navigation, screen-reader behaviour, reflow at 320px, 400% zoom, and reduced-motion respect — the criteria automated tools genuinely cannot verify. The accessibility audit log was dated and filed alongside the ROPA, and the privacy and accessibility statements were cross-checked against the spec for content accuracy.
Functional testing surfaced (and we promptly fixed) the items any honest pre-launch cycle should — including a subtle bug where the contact-form honeypot rejection path was writing an audit row contrary to spec, and a separately-incorrect Outcome value being emitted on a related path. Both fixed and re-verified. We also delivered four supplementary tickets that emerged during test entry: editorial corrections to main-page body copy, a code-callout component fix where the line-number gutter wasn't flowing to full height, a responsive mobile navigation menu (a meaningful UX improvement at mobile breakpoints), and a fix for an unwanted horizontal scroll into empty space at narrow viewports. BUILD_VERSION is now populated on the SWA Function App at deploy time, so GET /api/health returns a meaningful version field tied to the commit SHA — proper production observability.
Then came the cutover itself. The day before launch we lowered DNS TTLs at IONOS to 300 seconds — a five-minute rollback window rather than hours, if anything went wrong — completed the pre-cutover verification of every required SWA Application Setting (defence in depth against any value slipping through the gaps), re-verified the Data Privacy Framework certifications for both Resend and Cloudflare immediately before the switch (the DPF underpins the legal basis for the US data transfers, so it has to be re-checked at cutover time), and completed the GoDaddy domain-ownership hardening pre-flight: transfer lock on, auto-renew confirmed, contact details current. Domain loss would be catastrophic; ten minutes of pre-flight checks prevent the worst-case outcome.
— On launch week —Months of careful planning, architecture decisions, and incremental delivery — converging into a single decisive moment.
Then we added the custom domain to the SWA resource, captured the validation target, switched the apex record at IONOS to point at Azure (leaving MX and SPF records untouched so M365 mail flow continued uninterrupted), and waited for SSL provisioning. The site went live. The contact form sends through Resend successfully. The function endpoints respond. Traffic is being served from Azure's edge. External uptime monitoring on the apex and /api/health is being configured to keep an eye on things from the outside.
In parallel, the enterprise e-commerce client engagement reached its own production cutover milestone. After the previous week's cutover dry-run and the start of go-live activities, this week the cutover completed successfully. Alongside that, we delivered a genuinely interesting piece of performance work: converting a set of Salesforce API integrations from composite-style calls to graph-style calls. Salesforce composite requests bundle multiple sequential API calls into a single HTTP round-trip but still execute serially server-side; graph requests, by contrast, execute related operations as a unit with explicit relationship traversal — meaning fewer round-trips, lower API consumption against Salesforce limits, and meaningfully faster response times. Targeted input hardening on a promotion-configuration code path landed alongside, tightening validation against malformed or oversized payloads.
For a retained client, we delivered an enhancement to their registration form: email-alert notifications, so the team is notified the moment a new client registers rather than discovering it on the next manual check. A small change; an immediate operational benefit.
Looking ahead, the post-launch phase begins. A 7-day live observation window before we decommission the old IONOS WordPress hosting. The annual WCAG 2.2 AA re-audit cycle to schedule. An X-Forwarded-For parsing harden to verify behind SWA's edge proxy. A refactor to emit more granular audit Outcome values for the §9.11 input-hardening rejections. And the final piece of the registrar/DNS-host realignment — migrating DNS authority from IONOS back to GoDaddy, now that the cutover is complete.
Two production launches. Twenty-three items to Done. A company website that is properly engineered, statutorily compliant, and accessibility-audited — and an enterprise e-commerce platform that just went live with measurable performance improvements baked in. A week to bookmark.