Origin & Vision
Project Journey
How a personal gig log became a data platform, and the part that still feels improbable: it all happened in about eight months. It began on Thanksgiving week 2025 with a single prompt, "List all the shows I've ever played", and grew, phase by phase, into a database-backed archive, an operating platform for a working band, and the seed of The Shared Stage. This is how.
The part that isn't on the screen
I've spent my entire career in technology, at software and hardware companies, so none of the vocabulary was foreign: databases, domains, APIs, deploys. But I was always adjacent to the building, never the one doing it. I had never been a hands-on coder or created an application. Modern web design, Google Apps Script, schema design, Cloudflare, backups, how a domain actually resolves. I knew them as concepts, not as things my own hands could make. Every page in the story below was something I built for the first time, in real time, by building it.
And the pattern repeated at every turn: each time the project hit a wall in the data model or the architecture, the only way through was a jump to a more capable technology: a spreadsheet to a real database, a published CSV to an edge API, a single site to two harmonized ones. Each jump solved the old limit and introduced a steeper learning curve than the one before it. The site climbed; so did what I had to understand to keep building it.
This is the part I'm proudest of. Not the platform itself, but that AI finally closed the distance between understanding technology and actually creating it. I spent a career on the near side of that line; this is the first thing I've built across it. What's here could not have been done without AI. That's not a disclaimer. It's the whole point.
For about fifteen years there was a spreadsheet. A musician keeping a running list of his own shows (original projects, tribute work, sit-ins, one-off bills), mostly so he could stop losing the record. It covered the recent years reasonably well, and honestly, Bill figured that was all he really wanted: a tidy list of where he'd been lately. No platform, no ambition beyond "don't forget." That spreadsheet is the before, the raw seed everything else grew from.
Over Thanksgiving week 2025, almost on a whim, Bill opened a ChatGPT prompt and asked it to list every show he'd ever played. Over the next few days the AI kept surfacing little artifacts of his musical past scattered all across the internet: old club flyers, festival listings, setlists, reviews, audience recordings, photos. The fifteen-year spreadsheet he'd thought was "enough" suddenly had a long tail he'd never collected. That's what lit the fuse: not the want for a website, but the want to compile all the orphaned bits (every fragment of a forty-year career, scattered and decaying in a hundred places) into one trustworthy record. Within days the gig log became a public site: BillTaylorBass.com.
Accuracy beats polish. The discipline of pulling scattered fragments into one clean record is what later made Songs, Insights, and Shared Stage possible.
Once the archive was reasonably complete, the obvious question was: what does it tell me? The v2 era introduced analytics: shows per year, most-played venues, song frequency, band activity over time. For the first time the data was being queried rather than just stored. Deterministic IDs, normalization, and repeatable import pipelines became priorities. Every new page increased the cost of changing the schema.
Features create debt fast. Every new page made it harder to change anything underneath.
The original data model baked in one assumption: one show, one band. It worked fine for solo-headliner entries. It fell apart the moment the archive reflected real-world live music: multi-band bills where Tribute ABB, The Core, and other acts share a stage the same night. The "stabilization war" of early 2026 forced a structural decision: repeated regressions across the editor, the canonical tabs, and the public site made it clear that patching symptoms wasn't an option.
The multi-band problem wasn't a bug to fix. It was a signal that the model needed to describe live music as it actually works.
The v4 canonical model introduced a properly normalized, time-aware schema: Events (the show), Performances (each band's slot at that event), and Participants (each musician's role in each performance). That separation (event from performance, performance from personnel) is the architectural foundation everything else builds on. With it came deterministic IDs, alias resolution, and a strict contract: canonical tabs are the only write surface; EXPORT_* tabs are generated compatibility views; the public site reads only published EXPORT_* feeds, never directly from canonical.
Separate write complexity from read stability. The public site can be boring and reliable while the canonical engine evolves aggressively behind the contract.
Something unexpected happened when the v4 model was applied to the archive: the data stopped being a list and started being a graph. When you correctly model who played what, at which event, in which band, alongside whom, relationships between musicians, bands, and venues emerge naturally from the structure. Bill has shared a stage with hundreds of musicians across forty years; the canonical archive doesn't just record that, it maps it. Degrees of separation. Co-occurrence networks. Time-aware band membership.
The archive stopped being a list of shows. It became a map of relationships.
BillTaylorBass.com isn't the destination. It's the proof of concept and the seed. Nearly 1,000 documented shows, hundreds of musicians, dozens of venues across the Southeast. That network, properly modeled, is the first node cluster in a much larger graph. The vision is additive: other musicians, bands, and venues bring their own documented histories, and the graph grows outward from Bill's network to the broader scene.
Bill's archive is Node Zero. The platform starts here and expands outward from a known, trusted dataset.
With the v4 model in place and the public site reading from a stable contract, attention turned from storing the data to surfacing the stories already inside it. Show Significance, Rarity scores, Milestone counters, First/Last flags, Anniversary markers, per-musician shared-stage totals, venue lifecycles. Each is pure derivation from data the archive already had. "10th show with The Core at Smith's." "Bill's 50th show with Kyle Bryant." "Rare lineup: only 2 shows ever." Each pill turns a row of data into a sentence about the work.
An archive becomes a story not when you write narrative on top of it, but when the structure of the data already implies one.
Up to this point the archive had been almost entirely retrospective. Phase 8 was the first time it was used as a forward-looking tool: what should we book next, and which dates are at risk? A deep analysis of three years of BTAM touring data revealed that two of the four worst-performing shows were structurally explained by external calendar conflicts nobody had checked for: a top-10 Georgia Tech home game, and a UGA Spring Break / tornado window. Both looked like venue problems; both were calendar problems hiding in plain sight. The same canonical discipline now drives a Trends dashboard, a Conflict Calendar, and a forward-looking Booking Outlook.
The archive stopped only remembering. It started planning.
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. v7 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 v7 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. v7 production 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.
The AI Evolution: From Prompt to Partner
This project has always been AI-assisted, but what that means changed across the build versions. What shifted was the depth and complexity of what those conversations could handle.
Early AI Era
ChatGPT for architecture decisions, schema design, and code generation. Effective for isolated tasks and focused conversations.
The Limitations
As complexity grew (multi-file builds, cross-session continuity, architectural consistency), context limits and session-memory gaps created friction that slowed the build.
Claude
Longer context, stronger cross-session consistency, complex multi-file architecture held across a full session. The v5.50 site (all pages, components, and UX) was built in Claude.
From Build Partner to Migration Engineer
Claude doing systems work: standing up the Supabase schema and the Worker API, porting the entire public site to the database, and writing the verification harnesses that proved each page before it shipped. The replatform became a sequence of verifiable, same-day ships.
From Migration Engineer to Operations Partner
AI moved from building the platform to helping run it: standing up the CI deploy pipeline, debugging a live deploy through the browser, writing the automated ticketing tracker, answering questions with text-to-SQL, and generating the per-band strategic analyses. The partner that built the system now helps operate it.
What I Learned to Use: From Zero
A career in technology meant I knew most of these names. I had never actually used any of them to build something. Every item below was learned hands-on by building this, with AI as the teacher and the pair. The list, more than any feature, is the real achievement.
Web & Front-End
Data & Databases
Back-End & APIs
Infrastructure & Ops
AI & Workflow
The Data Model: v7 Architecture
One canonical database, four surfaces. The public sites read a versioned Worker API; the two consoles write through it. Everything ships on a git push, and the spreadsheet, with every workaround built to prop it up, is retired.
Public Site (read-only)
Every page (shows, bands, musicians, songs, venues, discography, shared stage, insights, media) fetches JSON from the Worker API. No direct database access; no pre-built snapshot files.
bt-canonical-beta-api (Cloudflare Worker)
Versioned, edge-cached endpoints: public reads for both sites, the authenticated write API behind the consoles, and the full cron suite. Deployed automatically on a git push now, no longer pasted in by hand.
Canonical Database (Supabase / Postgres)
Events, Performances, Participants, Venues, Bands, Musicians, Songs, Releases, and Media, with real keys, types, and constraints. Media lives in Cloudflare R2 object storage, and the database backs up to a separate bucket on a schedule. No spreadsheet.
Unified Admin (write layer)
Booth, the operator console, and Greenroom, the musician portal, both write to the canonical DB through the authenticated API. Role-gated: one view for the people who run shows, a lower-privilege one for the people who play them.
Jobs & Automation
Daily ticketing pulls, one-click show settlement, confirmation and fan-alert dispatch, setlist.fm ingestion, integrity checks, and scheduled backups. DB-native, no longer rate-limited by a spreadsheet.