· How I run this site as a product
This site as a product: what I built, what I didn't, and what's next
A CV says I can run operations and build things. This site is meant to show it, and to show the judgement behind it: what to build, what to leave out, and when to stop.
The job it does
It's built for two users. The first has thirty seconds to see what I do and whether it fits what they need, so the site shows the work rather than describing it. The second is me, as its operator. For me it's a system I learn from by running it: it keeps a record of its own behaviour, and I improve it from that record. So it has to be cheap and quiet to run, and honest when something is wrong. Everything on it answers to one of those two. If a feature helps neither, it doesn't ship.
The constraints
- One person. I design it, build it, run it and write it up.
- A free tier. The site runs on Cloudflare's free plan, and on 2 October I ran out of its daily database writes. The budget is real, so the design has to respect it.
- An hour or two a week from here on. That decides what's worth keeping as much as what's worth building.
Deterministic by default
I use AI to build software, and I'd rather it helped me build something solid than performed on the page. So the site itself is plain, deterministic code: a scheduled job, a store of its own records, an outside monitor, and pages that say exactly what those records show. The one place that uses live AI is the incident desk, where a model proposes a priority and drafts an update for a real failure. It never decides. Every step after intake is a person's command, and since 1 October the model can't even set the priority on its own. More AI on the page would have defeated the point.
Decisions, and what each one ruled out
Thirty decisions are recorded in the decision log, each with the option it rejected. These shaped the site most.
| Chose | Instead of | Because |
|---|---|---|
| Objectives only on a path I own: a heartbeat the site keeps itself | A status page of the hosting provider's uptime (the first version had one; I deleted it) | Measuring someone else's uptime is theatre |
| An incident desk that reports, with a human gate | Letting the model act, or letting visitors raise incidents | A confident wrong call is the failure that matters |
| Four proof items, no more | A full portfolio | A reader with thirty seconds needs a short list |
| A page-view count hidden until it means something | A public counter from day one | Small numbers read as "nobody looks" |
| No leaderboard on the game | Scores and accounts | A public score is spoofable, and it's a product I don't want to run |
| Running out of a free allowance is said plainly, never paged | Treating capacity as an incident | A budget isn't a fault, and false alarms teach people to ignore real ones |
| Scope on the homepage, outcome numbers on the CV | Percentages from past roles on the site | The site is the evidence; it shouldn't argue from memory |
What I won't build
- AI theatre. No chat assistant and no agents talking to agents. The incident desk is the only live AI, and it only proposes. AI earns a place by doing a job, not by being there.
- More games. Two small ones exist because they measure something: what a browser experiences, and how long a move takes on the server. A third is ruled out.
- Claims ahead of evidence. No "industry-leading", and no figures nobody can check.
- A template for others. Readers would become users, with their own needs. The hours don't allow it.
The one thing I'd undo
I'd have frozen the multiplayer game at its job. It was built as a bounded test of server latency, after I'd written a rule against a second game and then overruled it. Then it grew: chat in any language, names, rematches, full screen, bots, late joiners, rooms that end when everyone leaves. Each step made sense on its own. Together they made it the busiest part of the site. By late afternoon on 3 October it had written 12,091 of the 14,678 database rows the day had used so far, and its records crowded the site's own failures out of view. It still earns its place as the server-side sensor. It just took more than its share, and I let it.
Done building, not done running
The site is feature-complete as of today. Three things are left: the first full 30-day window of its objectives closes on 30 October, when the error budget chart appears on its own; the first monthly reliability note follows it; and the write-up of the second game day. After that, changes come only from running it: an incident, a game-day finding, a renewal the dependency board flags, or a change to my CV.
What grows from here isn't features. It's the record: the plan is a note each month, a full year of objectives, and every failure written up. One-off projects can't show that.
Publishing plan
- A reliability note each month, starting 30 October: budget spent and why, and what changed.
- A write-up for every game day and every real incident, like the first game day.
- A note when the site finds something about itself, like the dependency board's blind spot.
That's the whole plan. It's small enough to keep.
What this is not
It isn't a product with customers, and it isn't a claim about running anything at scale. It's one person's site, built and run the way I'd want a team to run a product.
Decision log · Live reliability · How this site is run · All notes