Five Sites in Three Days

Almost everything I write here is about work. This one is not.

Over three days in September I put five small sites on the internet. They are card makers for tabletop games, the kind of thing where you fill in a form and get a print-ready card at the right physical size for a sleeve. The first one existed because I wanted to print cards that afternoon, and I did. The second existed because a friend mentioned that the tools for his game were not great. By the third day there were five.

I want to look at why that was possible, because the answer turned out to be more interesting than the sites.

The stack is barely a stack

Each one is static HTML and JavaScript. A small script turns a data file into a few dozen pages. Pushing to the main branch deploys it. One of them refetches its public data source on a weekly schedule and rebuilds itself, which is the most sophisticated thing in the entire group.

There is no server. No accounts, no login, no database, no sessions. Nothing to migrate. Nothing that can be lost, because nothing is stored. If one of these sites went down for a day, the correct reaction would be to notice eventually.

Working that way for a weekend is startling if your day job has shape. Features that would take a sprint take an evening, and it is tempting to conclude that something about professional software is bloated.

The constraints are real, they are just different ones

That conclusion is too easy, and the weekend had its own obstacles.

One site is called The Loot Table rather than the name of the game it supports, because the licence that makes it legal to build explicitly forbids putting the game's name in the title. That is a genuine product constraint arriving from a direction I never meet at work.

A data source I wanted was blocked by my own network's filtering, which took a while to work out because the failure looked like the site being down. A free content delivery network declined to serve one of the repositories, with no explanation and no appeal. The cheapest database tier I could find comes with a catch I will get to.

None of that is slower than enterprise process. It is just not frictionless either, and the friction arrives in unfamiliar places.

Then one of them grew up

Two weeks later I wanted the first of those sites to run an actual league. Registration, match results, standings, player advancement, injuries carried between games.

That required a database, and the moment it had one it stopped being the same kind of thing. Now there are records that belong to other people. There is a schema that has to survive its own changes. There is a login, because some actions should only be available to the person running the league. None of that existed the week before, and all of it arrived together.

I put it on the free database tier, which pauses itself when idle. The first request after a quiet period gets an error for about a minute while it wakes up.

That is funny, because I wrote a post two weeks ago about systems used too rarely to stay warm and how the first visitor pays for everyone. I then went and built one on purpose, read the catch, and took the trade anyway. On a league site for a handful of people, a one minute wake-up is a shrug. The same behaviour on something people depend on is the subject of a different post entirely.

What it says about the day job

Hobby projects are not fast because the code is simpler. Most of the code is roughly the same code.

They are fast because nothing can hurt anyone. No one's money moves. No one's data exists to lose. Nobody is waiting on it to do their job, nobody gets paged, and there is no version of a bad afternoon that ends with an apology to a customer.

Every slow thing in professional work is the price of mattering to someone. Authentication exists because the data belongs to a person. Migrations exist because you cannot throw away what people have already put in. Staging environments, review, release discipline, all of it is the cost of consequences, and I have written enough posts about those costs to be clear that I am not complaining about them.

What the five sites gave me was not a lesson about moving faster at work. It was a reminder of what the speed costs, and therefore of what you are buying when you give it up. That is worth an occasional weekend, and worth printing a few cards.