Case study · our own

We run this site on Azure Static Web Apps. Here is exactly how, and what it costs.

No client permission needed for this one: the client is us, the system is the page you are reading, and every number below is something you can re-check yourself.

next production Lighthouse re-measurement due ·

javascript shipped, content pages

0 KB

 · Measured in the built output — PROGRESS.md

Open dev tools on this page and you will find 0 KB of JavaScript: the nav is a details element, the FAQ is a details element, the motion is CSS, and there is no framework runtime to ship.

What's actually running

This site is a static Astro build, checked into git, deployed to Azure Static Web Apps by GitHub Actions. There is no server rendering anything on request, no database, and — on every content page — no client-side JavaScript at all. The table is every load-bearing fact about the stack, as it stood on the day this page was written.

What's actually running, as of the last build
LayerWhat it isDated
FrameworkAstro 7, static output, zero client JavaScript by defaultSTACK.md §3.4, 2026-08-17
HostingAzure Static Web Apps — Free plan, $0/monthSTACK.md §0, 2026-08-17; provisioned 2026-08-18
DeployGitHub Actions, on every push to main, with a preview URL per pull requestDEPLOY.md §3, 2026-08-17
JavaScript shipped0 KB on content pages, in the built outputPROGRESS.md, 2026-08-18
CSS5.5–6.6 KB gzip per pagePROGRESS.md, 2026-08-18
Fonts42.2 KB total across 2 self-hosted WOFF2 files (IBM Plex Sans + Mono)src/assets/fonts/README.md, 2026-08-18
Monthly Azure spend$0, with a $5/month budget alert as the smoke alarmDEPLOY.md §11.1, PROGRESS.md, 2026-08-18

The apex-versus-www split above is deliberate, not an accident of DNS: it is the one item in the not-fixed list below that is a platform constraint rather than a choice.

The score, and the gate that keeps it

An earlier version of this page said, plainly, that no production Lighthouse score existed yet and that we would rather show nothing than a staging number wearing a production label. The site went live on 18 August 2026; this is the production measurement, taken the next day, and you can re-run it yourself against the same URL.

Lighthouse report header for https://www.asdataworks.com/: four category gauges all reading 100 — Performance, Accessibility, Best Practices and SEO.

lighthouse, production, mobile · 100 · 100 · 100 · 100 ·  · Lighthouse 12.6.1 run against https://www.asdataworks.com/

The gate that keeps it there: every pull request runs a strict Lighthouse budget (mobile Performance ≥95, Accessibility 100, SEO 100), an accessibility pass over every built route, byte budgets, a broken-link check, an SEO-integrity check and the honesty scanner — eight jobs, verifiable by reading .github/workflows/ci.yml and this repository's Actions history. A red check stops the merge. One honest nuance, carried in the not-fixed list below: that stop is our working discipline, not a platform-enforced rule.

How it is actually built and shipped

The same five steps run for every change, whether it is a typo fix or this page.

  1. Write. Every page and every template lives as a component or a Markdown-shaped file in this repository. Nothing is hand-edited on a server, and nothing renders that is not in git.

  2. Open a pull request. Azure Static Web Apps generates a real preview URL for every PR, so a reviewer looks at the actual rendered page before anything merges — not a diff.

  3. CI gates the merge. Eight jobs run on every pull request: typecheck, the token-contrast/design-system rule tests, the build, byte budgets, a strict Lighthouse budget, an accessibility pass on every route, link, SEO-integrity and honesty checks. A red check stops the merge — by discipline rather than platform enforcement, as the not-fixed list below discloses.

  4. GitHub Actions deploys on merge. Azure's static-web-apps-deploy action uploads the build to the Static Web App the moment main changes — a one-to-three-minute run, visible in the Actions tab.

  5. Azure Static Web Apps serves it. The Free plan puts www.asdataworks.com on Azure’s global edge at $0/month, with a $5 budget alert standing in as the smoke detector for anything that starts costing money.

What is not fixed — and one thing that briefly wasn't

Four things, in the order we found them, none hidden:

The CI gates run on every pull request — but nothing forces them

An earlier version of this item reported the Lighthouse, accessibility and link gates as a named TODO. They are wired now — eight jobs on every pull request, green on the run that shipped this page. What is still not fixed is enforcement: on GitHub's free plan a private repository cannot mark checks as required, so a red check stops a merge because we stop, not because the platform refuses. Upgrading the plan (or making the repository public) closes that gap; until one of those happens, this line is the disclosure.

 · .github/workflows/ci.yml

The apex domain is a single-region A record

asdataworks.com (no www) resolves through a single-region A record rather than a globally distributed edge, because the domain's DNS is Microsoft-hosted from the M365 admin center, and that surface offers neither ALIAS/ANAME records nor CNAME flattening — the two mechanisms Azure Static Web Apps needs to put an apex domain on its global edge properly.www.asdataworks.com is the canonical host and carries all real traffic on the full edge; the apex exists only to redirect to it, and pays the single-region penalty on that one redirect hop, once per visitor session.

 · STACK.md §2

There is no SLA on the Static Web Apps Free plan

We are selling reliability and running our own marketing site on a plan that carries no service-level agreement. That is a real, accepted trade against $9/month for the Standard plan's SLA, made because the operational load at this traffic and this team size does not currently justify it. The trigger to upgrade is written down rather than left to feel: the first of paid traffic going live, a third custom domain being needed, or a client contract requiring us to state an SLA for our own web presence.

 · STACK.md §1.4

The sans font briefly missed its own budget

For part of one build day, the self-hosted variable sans font shipped unsubset — the full weight 100–700 axis, at 45.7 KB — before axis-instancing and a Latin-only feature-prune brought it down to 27.5 KB the same day. It never breached the sitewide font ceiling (55 KB across both files together), but for that window it ran heavier than the 34 KB we had budgeted for that one file. We are noting it because "we caught it and fixed it the same day" is a real thing worth disclosing, not because it is still true.

 · src/assets/fonts/README.md

Start with a call about what you are trying to fix.

Book an assessment call

30 minutes · with the engineer who would scope the work

one-page recap within 2 business days of a call that progresses