Shipping an app from a backup drive in one night

June 10, 2026

Last year my main machine got wiped and rebuilt, and everything I'd ever worked on went to a 7.3 TB drive labeled BACKUP — never format. Somewhere in there was a little React prototype I'd built and abandoned: a bingo card generator for concerts. Type in a band, get a 5×5 grid of similar artists, spot their shirts in the crowd. Cute idea. Dead code.

Last night I resurrected it, rebuilt it, and shipped it to concertshirtbingo.com before I went to bed. Here's what that actually looked like, because the process says a lot about how building software works now.

The archaeology

The prototype was 255 lines of React in a single file, sitting in a backup of a backup. It still ran. Even the Last.fm API key in the .env still worked — I checked it before writing a line of new code. Lesson one of infrastructure work applies to side projects too: verify what you have before you rebuild what you don't need to.

The research fleet

Before rebuilding, I had AI research agents fan out in parallel: one auditing whether Last.fm was still the right music-data source in 2026 (it is — but Spotify's API is now effectively closed to hobby apps, which I didn't know), one evaluating concert-data APIs, one pricing out LLM-generated content at the edge, and one sweeping prior art. An hour later I had a verified picture I'd have spent a weekend assembling by hand — including live-tested fallback chains: Last.fm → ListenBrainz → Deezer, so no single provider's death kills the app.

The build

The rebuild went from one file to a proper little architecture: seeded deterministic shuffles (so a shared link reproduces your exact card), genre detection driving per-genre visual themes — a Slayer card looks nothing like a Chappell Roan card — and curated square packs with rarity tiers. Tested end-to-end in a real browser against live APIs before deploy.

The DNS gauntlet

Then the fun part. The site deployed to Cloudflare Pages in seconds, the registrar nameserver change went through cleanly — and the domain still showed a parked page. For the next hour I got to peel the most complete stack of stale DNS caches I've ever personally encountered, in order: the public resolvers (flushed via Google's and Cloudflare's purge tools), my router — which it turns out hijacks all port-53 traffic on my LAN and answers from its own cache, lying to every dig @8.8.8.8 I threw at it — then macOS's own mDNSResponder, and finally Chrome's private resolver cache. Five layers. The site was live on the internet for half an hour before my own house would admit it.

What it means

Total wall-clock time from "what's on this backup drive?" to a working product on its own domain with valid SSL: one evening. The bottleneck wasn't writing code — an AI pair of hands wrote most of it while I made decisions. The bottleneck was judgment: which data sources to trust, what the product should feel like, and knowing that when DNS lies to you, you check the registry's whois before you believe any resolver.

Thirty-five years in IT and the job is still the same: it's always DNS.