Forty Years of Bass, Finally Written Down

The "database" was a Google Sheet. That was exactly the right call to launch on. It let one person edit anything, instantly, with no deploy, and it turned a fifteen-year gig log into a live site in days. But in the span of a single spring the site had outgrown it: a personal record had quietly become a platform, and the spreadsheet was being asked to behave like a database it was never built to be. By mid-2026 the tell wasn't any single failure. It was the scar tissue: pre-built JSON snapshot files rebuilt on a timer (with a write-allowlist that silently went stale; the pipeline was once broken for 17.8 days before a monitor caught it); a published-CSV cache that lagged reality; mixed date formats every consumer re-parsed defensively; venue-alias plumbing and dedup guards bolted on to compensate for a store with no real keys; rate limits forcing debounced rebuilds. None were bugs, exactly. They were the cost of pretending a spreadsheet was a database.

You don't migrate off a tool when it breaks. You migrate when the work to keep it from breaking outgrows the work it was saving you.

The risk in any replatform is the big-bang cutover that takes the live site down with it. The v7 build refused that. A canonical database on Supabase (Postgres) and a read-only Cloudflare Worker API stood up alongside the untouched production site. Every page got a second, DB-backed version served at /beta/, reading from the Worker, never from the Sheet. Production kept running on Sheets the entire time; the beta proved the database against real data, page by page, with nothing to roll back because nothing in production had moved yet.

Build the new engine next to the running one, not under it. Cut over only when the parallel version has already earned it.

One by one, every public page was rebuilt to read the database: Upcoming and Archived shows, the show detail page (with a pop-out audio player), Bands and Band pages, Musicians and Musician profiles, the global Songbook, Venues and the On-The-Road map, Discography, Insights, Press, Video, Images, Alumni, the Career Timeline, Play-a-Random-Show, the curated Hall of Fame, and The Shared Stage, the relationship graph that had been the whole point. Each verified against the data before it shipped; each Worker change version-stamped so a deploy could be proven to have landed.

A migration is done right when the reader can't tell it happened, except that everything is faster and nothing is stale.

The public read-side is the easy half. The real definition of the v7 build is the unification of the admin tools and the harmonization of data across BillTaylorBass.com and B. Taylor Artist Management. Two sites and three logins (the BTB archive admin, the BTAM management admin, and the BTAM musician portal) collapse onto one canonical dataset with one set of admin tools: a unified admin for the people who run things, and a separate, lower-privilege musician portal for the people documenting their own history. The Core and Wolves, Lower already live in the shared database; BTAM simply views the same truth through a management lens. The v7 build doesn't go live on either site until the admin is unified, the data is clean, and the portals work.

The archive's last reinvention isn't a feature. It's making two sites, three logins, and forty years of data finally tell one story.

The cutover landed. With the database proven page by page, the write side finally moved off the spreadsheet and onto two purpose-built consoles. Booth is the operator's cockpit: events, setlists, rehearsals, roster, venues, accounts-payable, confirmations, runsheets, newsletters, dashboards. Greenroom is the musician's portal, a lower-privilege view where each player signs in with Google or a magic link to see their own shows, money, calendar, songs, and a per-band message board. One canonical database now feeds four surfaces at once: the two public sites plus the two consoles. The archive was no longer something kept on the side. It had become the system the band actually runs on.

A record you keep is a hobby. A system people log into to run their week is a platform. The difference is who else depends on it.

The flagship of the summer. The platform learned to watch a show sell, and to pay the band when it was over. A per-show ticket model pulls daily sales from multiple platforms (Freshtix and Ticketmaster, with Eventbrite next), including an automated tracker that reads the venue's daily report email, follows an expiring link to the real file, reads the numbers off it, and files one snapshot a day with no human touch. Those snapshots drive a pacing view that compares a show against the last comparable one, and a cumulative sales curve, the hockey-stick, drawn against the venue's capacity so you can see how much room is left to fill. When the night is done, one click settles it: gross in, house skim and shared expenses out, a penny-accurate split written to the band bank and the payables ledger. The archive that used to only remember shows now helps sell them and closes the books on them.

Data earns its keep when it stops describing the past and starts changing a decision you make today.

An operating platform has to reach people, not just store rows. This phase wired in the connective tissue: show confirmations that go out by text, email, and push and reset themselves when a date moves; mileage and year-to-date earnings with a year-end tax PDF built from the same tax form the platform already had on file; a per-musician calendar feed each player can subscribe to; and a fan side where someone can follow a band, confirm by email, and get alerted when a new date drops. Each one is a small integration on its own. Together they turn a database into something that talks to the people who depend on it.

The last mile of any system is the humans. Storing the truth is half the job; getting it to the right person at the right moment is the other half.

Early on, shipping a change meant dragging files over FTP, and for the engine, pasting a 1.5 megabyte script into a dashboard box by hand. That worked until it didn't: a hand paste is a step you can forget, and once the deployed code drifts from the saved copy, you can no longer trust what's live. The fix was real continuous delivery. The public sites now deploy on a git push through GitHub Actions, which syncs the files to the host automatically. And the engine itself, the last thing still deployed by hand, moved to the same model: push to the repository, and a workflow logs into Cloudflare, deploys the worker, keeps every secret and setting intact, then checks the live version against what was shipped before it calls the deploy good. The repository became the single source of truth, and the scariest manual step in the whole operation was retired.

The most dangerous part of any system is the step a human has to remember to do by hand. Automating it isn't polish; it's removing a way to fail.

A platform people rely on has to survive its own bad days. Media moved off a third-party image host onto Cloudflare's own object storage, with a direct-upload pipeline from Booth. The database backs itself up to a separate storage bucket on a schedule, so a mistake is recoverable rather than fatal. Health monitors watch the jobs that are easy to forget about, the same class of silent failure that once left a data pipeline broken for nearly eighteen days before anything noticed. Sensitive values, an API token, a signing key, the encryption key that protects a tax ID, live as encrypted secrets, catalogued so it's clear what each one does and what would break if it were lost. None of this shows up on a page. It's the quiet difference between a project and something you can actually depend on.

Backups, monitors, and a plan for the worst day aren't the exciting part. They're what let you sleep while the thing keeps running without you.

Settlement taught the platform to close the books on a show. This phase taught it to call the show before it happens. Every upcoming date now paces against more than one leading indicator: the daily ticket curve where a feed exists, a once-a-day read of each show’s Facebook-event interest, and, for reserved-seating rooms, a seat-map count taken straight off the venue’s chart. Those signals fold into a single projected-attendance grade for each show, weighted toward real ticket sales but leaning on social interest where tickets are thin, or, for a door-only room with no feed at all, standing in as the only signal there is. The grade carries a confidence that tightens as the date nears, and a daily snapshot so you can watch it move. A short morning routine captures the whole set in one pass. The archive that learned to remember, then to sell, then to settle, has now learned to forecast.

A record that only remembers is a library. One that tells you how tonight is trending is a decision you can act on this morning.

For its whole life the site led with the shows. It’s a performance archive, so the calendar sat at the top and the person behind it was somewhere a few clicks in. This phase turned that around at the front door. The homepage now opens with a short bio and a rotating carousel of live photos of Bill on stage, managed from Booth like everything else, upload, caption, photo credit, reorder, with the upcoming-shows grid right below. A small change next to a replatform, but it reframes what the site is: not just a ledger of dates, but a portrait of a working bassist and the forty years of playing the rest of the archive documents.

The data was always about the work. The front door finally puts the person who did it first.

For most of a year the repository carried tests that nothing ever executed. They sat in a folder, passing or failing invisibly, while the deploy pipeline shipped code to the live API without once asking them anything. In September that changed: nine guards now gate every deploy, and a change that breaks one never reaches production. The same week turned up nine real defects, and every one of them had the same shape. A fact would be written once, correctly, and then quietly become false, with no code path responsible for ever revisiting it. A message log said a text was still held when it had been delivered three hours earlier. A daily digest counted forty-one shows as awaiting an answer when thirteen were real. Five confirmations were erased by a routine date change and survived only in an audit trail nobody reads. None of it was broken at the moment it was written. All of it was wrong by the time anyone looked.

A number that was true when it was written is not the same thing as a number that is true.

The harder lesson was about the questions the system could not answer. Asked whether an advertisement was running, it checked the table meant to record ad spend, found it empty, and said no. The buy was real, a hundred dollars of it, fully documented in a file the query never touched. Asked whether a band had ever been filmed at a particular room, it checked the media catalogue, found nothing, and said no. Two hours of footage were sitting on a drive in the next room. In both cases the table held no rows because nothing had ever been responsible for writing to it, and silence read as fact. The response was to stop relying on a single reader. The work now splits three ways: one model with reach across the database, the mail, the browser and the drives; a second working from a terminal, where the code and the tests and the version control actually live; and a third given nothing but read access and an instruction to disagree. The third one, on its first assignment, found that a feature about to be built already existed.

An empty table is not an empty world. Before concluding that something does not exist, find out whether anything was ever responsible for recording it.

Every surface here was built and then had things bolted onto it, which is how working software actually accumulates. By late summer that was the limit: Greenroom in particular had grown feature by feature until it worked well and hung together poorly. Version two was the answer, and it was a design decision before it was a build decision. BTAM became a proper public-facing site in cream and rust; Greenroom was rebuilt in Midnight, the deep navy this archive has used since the beginning, because the room a musician checks at midnight before a drive home should not be lit like a dashboard.

The harder half was moving in without anyone noticing. Both redesigned (v2) apps went live at the original addresses: BTAM at the root, Greenroom at /greenroom/, the run sheet at its same URL. Every bookmark, every texted link, every emailed confirmation and every home-screen install kept working and simply got the new app. That matters more here than it would on a normal site, because Greenroom is an installed application on the band’s phones, and the one real trap of the cutover lived there: the new app had no notification handler of its own and had been quietly borrowing the old one’s. Replacing the old app wholesale, the obvious move, would have silently killed push for the entire roster with nothing anywhere to say so. So the cutover replaced the markup and deliberately kept the old service worker, manifest and icons underneath it. The same pass made both apps genuinely installable for the first time, including on Android, where BTAM had a manifest and icons but no service worker and so had never once been offered as an install. Sign-in gained a typed six-digit code alongside the emailed link, for the people for whom the link was the thing that kept failing.

A rewrite the users have to be told about is a migration that went badly. The measure of this one is that the band’s phones kept working and nobody had to do anything.

Nothing shipped this month that a visitor can see, and it was one of the more consequential months here. The platform had reached the age where its weak points stopped being missing features and started being things it had quietly never owned.

The first was memory it was renting. The newsletter provider’s free plan deletes a campaign’s per-person report after exactly thirty days. One send was already unreadable; the next was three weeks from going the same way. The reading code had existed for months, running on every request, computing an answer and throwing the underlying rows away, so the entire per-person engagement history of this project lived inside somebody else’s retention policy on a timer nobody was watching. Two tables and a capture job later it belongs here, and the capture is checked against the provider’s own published percentages rather than against its own success flag, which is the difference between knowing a job worked and knowing it got everything. The same principle sent the platform after the Facebook guest lists, which have no interface to ask at all: 936 RSVPs across eleven shows, now rows in a database rather than a number on a screen that expires.

The second was subtler and more embarrassing. The system turned out to answer the question is today in the past or the future in several independent places, and on the morning of a show in Athens two of them disagreed with reality at once. The date fell off Upcoming while the band had not played a note, and the archive’s On This Day card announced that night’s show as a past performance and an anniversary of itself. Neither was difficult to fix. Both existed because the same question had been answered more than once, in more than one place, by more than one person-hour of past work. The deploy guards that gate every release went from nine to twenty-seven over the same stretch, and the one still owed is the one that would have caught both of these.

A number you can only read on someone else’s dashboard is a number you do not have. And a question your system answers in more than one place is a question it will eventually answer two different ways.

A year in, the question changed from "does it work" to "is it true." Every public page was walked in a live browser, one at a time, against the data underneath it, and nothing counted as finished until Bill had looked at it himself and signed it off. The walk found real things: dates printing a day early, a 1991 album marked "Coming Soon", a night's recording offered on the wrong band's set, a band page counting years two different ways. Each fix shipped with an automated check that fails the deploy if the problem ever comes back. The check suite went from a handful to 78.

It also changed what the archive keeps. Press clippings now save their own text, a Wayback copy and the article's photo, so a story survives the site that published it. Play a Random Show became a real player. The rig rundown was corrected bass by bass.

A page is done when its owner has looked at it live and said so, not when the code says it should work.