Five Client Sites, One Platform, No Team

Where this started

A client site was compromised. It ran WordPress, and it was breached through vulnerabilities in its plugins.

At that point I had never written HTML or CSS. My background is economics and statistics, then ten years of marketing operations, which meant I had spent a decade specifying systems for other people to build and watching organizations fail to adopt them. The first commit on the earliest of these sites is dated September 2025.

Eleven months later there are four sites in production, a fifth in build, and 860 commits across the platform. What follows is what actually happened in between, including the parts that went wrong.

The stack decision, and the obvious objection

Everything runs on Astro with server-side rendering, deployed to Cloudflare Workers, with a headless CMS for content and a Cloudflare D1 database per client for customer data.

The obvious criticism is that this is overkill for a neighborhood bar, and it is correct. A restaurant does not need edge rendering. I chose it anyway for two reasons, and only one of them is technical.

The technical reason is that the incident that started this was a plugin vulnerability. Hardening WordPress means continuing to run plugins and hoping each advisory lands before the matching exploit does. A compiled site on an edge runtime removes the category. There are no plugins to exploit.

The other reason is that I wanted to learn a real stack, and the client work was the only place I had to do it. I would rather say that plainly than pretend every decision was driven by requirements.

The cost of that choice is that everything a plugin would have handed you now has to be built. That cost is the rest of this project.

The second site is where the real project starts

The first site is a website. The second one is a decision.

Building the second site meant either copying attribution capture, consent bootstrapping, form handling, SEO helpers, and email templates into a new repository, or extracting them somewhere both sites could share. Copying works fine right up until the first bug fix, at which point there are two versions and only one of them is correct.

So everything shared moved into a private library, consumed by each client site as a pinned dependency. It is now 5,695 lines of TypeScript across 21 modules with 23 public entry points, covering attribution, consent, analytics, forms, email, SEO, commerce, the data store, the admin console shell, security headers, and bot protection.

A new client site inherits all of it before it has a single page.

Commerce, because nothing off the shelf fit

The instinct on any build is to look for the existing solution first. For WordPress, online ordering is a plugin install. For this stack, it does not exist.

Astro’s own documentation lists three commerce options: two hosted checkout overlays and one rented third-party cart. No dedicated Stripe integration is documented at all. Searching the package registry, the only relevant community package was last published in October 2023 at version 0.1.35 and describes itself as a work in progress.

So the commerce layer is 1,315 lines across ten modules:

• The CMS is the catalog source of truth, syncing to Stripe products, coupons, and promotion codes. Product IDs are stored separately per environment, so test and live never collide. That detail exists because they collided once.
• Checkout prices are computed server side. Client-supplied prices are never trusted.
• The order store belongs to the client, in their own database, with an eight-status fulfillment vocabulary the payment processor does not model, each status stamping its own timestamp.
• The library carries no payment SDK. It defines the minimal interface it needs and the caller passes its own client, which keeps the edge bundle small and the library independent of SDK versions.

The honest version of the build-versus-buy call: a rented cart would have worked for the smallest shop. The reasons against it were the per-transaction fee, not owning the order data, and no connection to the CMS catalog the client already edits. Those are real reasons. They are not proof that building was the only option, and I am not going to claim they were.

Integration depth is the part that transfers

The platform talks to Stripe, Sanity, Cloudflare Workers and D1 and Access and Turnstile, Google Analytics, Google Ads, Search Console, Google Business Profile, Google Sheets, Brevo, Resend, and a reservations platform.

Listing integrations is not very interesting. Two pieces of it are:

Service-account authentication implemented directly. Signing a JWT and exchanging it for an OAuth access token, rather than pasting an API key into an environment variable.

JWT verification against a JWKS endpoint with per-application audience validation, which is what replaced the admin console’s original authentication after I found out how weak it was.

Those two are the difference between connecting to APIs and understanding how the authentication underneath them actually works.

The drift problem, and the instrument for it

A shared library does not guarantee anything. A site can pin an old version. It can import the right module and never call it. It can look correct in source and behave differently in production.

So there is a conformance audit: 39 parameters across four sites, spanning foundation, identity and SEO, analytics, forms, data storage, the admin console, email, commerce, secrets and CI, and CSS.

Every row carries two grades. Severity, which is standard. And rigor, which is not: a record of how that check was established.

A pass established from a config file is weaker evidence than a pass established against live behavior. Recording them as the same green cell is how an audit becomes theater. This is the piece of the project I am most pleased with, and it comes more from the statistics training than from anything I learned building websites.

The matrix currently contains failures, warnings, and unknowns. They stay in. An all-green audit proves the instrument is not measuring anything.

Then the question I did not want to ask

Removing the plugin attack surface solved the problem that started this. It did not answer whether what I built was any safer, or whether I had just moved the attack surface somewhere I could not see.

So I audited my own three production sites against their source. The worst finding was mine: the admin console rendering customer orders, revenue, and complete customer records authenticated on a forgeable header, with the read-side pages checking nothing at all. In production it was fine, because the gate sat in front of it. That is precisely the problem. The security was a property of the deployment configuration, not of the application.

That audit is written up separately, including how the fix was verified by attacking it, and what is still open.

Measurement, since that is what the sites are for

These are marketing platforms, so attribution is not decoration.

First-touch and last-touch are captured in a first-party cookie with a canonical source taxonomy, carried through checkout into the payment session metadata, and read back on the confirmation page. One shared lead-stage to analytics-event mapping applies across every client, so a qualified lead means the same thing on all of them. Consent mode is bootstrapped before the tag manager loads.

One detail worth keeping because it was a real bug: a cart containing multiple item types was reporting revenue correctly while item-level reports came back empty, because a single metadata key was missed. The fix was a single configuration listing every item type, read by both the checkout and confirmation paths, so adding a type is one entry rather than three places to forget.

On one client, a warehouse-based reporting stack was replaced with a spreadsheet as system of record and an automated pipeline, taking recurring tooling cost to approximately zero without losing reporting.

What I would tell a skeptic

“Four restaurant sites is not scale.” Correct. This is not a scale story. It is a breadth, rigor, and ownership story, and I would rather be precise about that than inflate it.

“AI wrote it.” AI was central to how fast this happened and I am not going to be coy about that. It also produced the worst defect on the platform, because velocity is exactly how a spoofable admin console reaches production. The architecture decisions, the audit, and the rigor grading are the work. Typing is not the work.

“Solo means nobody checked you.” True, and it is why the conformance audit and the security review exist at all. They are the substitute for a team, and they are an imperfect one.

Where it stands

Four sites in production, a fifth in build. The shared library is at its 31st minor release since June. The conformance matrix has open failures in it that I have not closed. The security audit has two items still pending, including a full content security policy that needs a report-only rollout before it can be enforced.

All of that is written down, with severity, in a place I will actually look. That is a different state from finished, and it is the state I would rather be in.