Day 7 — Damn the torpedoes, full speed ahead!

I played World of Warships for a little while. Here I am in the French Tier 10 Destroyer 'Kléber'. I used to organize my competitive team, focusing on the largest and most prestigious WoWS tournament called 'King of the Sea'. I don't play any games anymore, I'm too focused on software development these days. It was fun while it lasted, and I made quite a few good friends during my time playing that game. Teamwork was essential and crucial for success. It's a little bit of a joke, but due to the low gameplay pace and the need for collective strategic thinking, it was called 'The thinking man's action game'.

Day seven was the kind of day that starts with one clear goal and ends with six things done that you did not plan to do.

The goal was simple enough: give the project an address on the internet and stand up the infrastructure behind it.

By the time I was done, I had also written two specification documents totalling fifty-one acceptance criteria, pushed a logo through to final approval, set up Google OAuth, and consumed an alarming amount of coffee.

Damn the torpedoes

I registered fret-o-matic.com at eleven in the morning for eleven dollars — the kind of money that feels almost insultingly small for something that now officially exists on the internet.

I have bought a lot of domains over the years and never quite lose the small satisfaction of watching the nameserver respond to your name for the first time.

The sensible thing, at eight days into a project with a working engine scaffold but no deployed services, would have been to defer the infrastructure until the engine was further along.

I did not do the sensible thing.

A Railway Pro workspace went up: twenty-four cores, twenty-four gigabytes of memory, enough headroom to run a documentation system, a landing page, and a deployment API without ever thinking about resource pressure. Two services, both behind Railway's automatic SSL and DNS routing. I have used Railway on other projects and it earns its keep by handling the operational tedium — certificate provisioning, reverse proxy, process restart on crash — so that I do not have to think about it.

The two services that went live that day:

fret-o-matic.com — the public landing page. An Express server with a React front end, a contact form routed through nodemailer, and a design system built around the logo palette that had not yet been drawn. That order of operations — building the design system before the logo — sounds backwards and probably was.

lds.fret-o-matic.com — the Living Documentation System, rebuilt for Fret-o-Matic from the version I first wrote for another project. The private back end where every specification, decision record, and session handoff gets indexed and made searchable in milliseconds.

The database that lives in git

The documentation system runs on SQLite. That is not the unusual part.

The unusual part is how it deploys. Most database-backed applications need a separate, persistent database host — a managed Postgres instance, a Docker volume, some external state that survives between deployments. I did not want any of that complexity.

Instead, the database is built locally, seeded with the current project documentation, and committed directly to the git repository as a pre-built binary file. When Railway deploys the service, it wakes up with a fully populated, fully indexed database already sitting inside the image. No migration step. No initialisation risk. No external connection string.

The deploy-prep flow is four commands:

node scripts/deploy-prep.js   # seeds SQLite, runs WAL checkpoint
git add db/fom-lds.db
git commit -m "chore: deploy-prep — $(date +%Y-%m-%d)"
git push                      # Railway auto-deploys from the push

It sounds slightly unconventional until you reason through the constraints: the data only changes when I commit new documentation, the database is effectively read-only at runtime, and the entire state needs to be reproducible from git.

At that point, SQLite-in-git is not a workaround. It is the correct answer. I wrote it up as a formal architecture decision record so I could not quietly talk myself out of it at two in the morning.

The logo

I made the logo on the same day, which mostly explains why the session clocked thirteen and a half hours.

I have spent time in my life running cinema operations, painting huge billboards by hand, managing theatre productions, handling marketing for Norway's sixth largest cinema — and back in 1999 I actually managed to pass the Adobe Photoshop exam earning the title ACE (Adobe Photoshop Expert) just for the fun of it. I don't consider myself a graphic designer at all, but it's fun and useful to try a lot of things in life.

I loved messing around in Photoshop. I still enjoy it, but it's a pain in the neck that it's SaaS software now... like so many other software products these days. I miss the old days when you purchased a license, and then the product was yours for life.

I can produce visual identity work when a project needs it, even though it may not be top notch quality. It will have to do, I can't afford paying a visual design team to do that job for me.

The Fret-o-Matic logo is built around a wordmark and a mechanical illustration: gears, a guitar body, exhaust pipes, something that looks like it could pull a recording apart and write down what it finds.

The colour palette is inspired by the late sixties and seventies era, with a touch of steampunk elements. I like line art, so that's what I went for.

I was never very Illustrator-savvy, so I cheated a bit — wrote a descriptive prompt and fed it to e.g. NanoBanana 2 and a couple of other generative AIs — made a composite image of the output in Photoshop, and thought that it was at least something that didn't look too shitty.

The logo was a done deal the same afternoon it was drawn. Version 1.01. Then 1.03 for the transparent-background variant. It has not changed since. I had more pressing stuff to attend to.

Anyways, it was a good speed run — and it produced some decent results.

Fifty-one acceptance criteria

With the infrastructure standing and the logo locked, I wrote two specifications before midnight.

Twenty-seven acceptance criteria for the documentation system. Twenty-four for the landing page.

Both went through my standard QA routine and came back clean.

Day seven was, by any reasonable measure, too much for one day for a guy in his fifties — but I do not regret any of it. Being on a flow is always satisfying. It's been a long time coming for me, as I've been dealing with some rather shitty stuff that's been preventing me from being productive the way I used to in my younger years.

I think that my initial work on this project might be a sign that I'm on my way to be back on track.

---

Written by Torgrim Nyerrød — May 7, 2026