Giving the spreadsheet a new job

The Blueprint · shipped 2021–present

Role: Platform Architect / Sole Engineer
Timeframe: Web application from 2021, across several generations.
Technologies: Strapi
PostgreSQL
CSV
Skills: Technical architecture
Strapi schema design
CSV import and export
Admin tooling

Separated the editorial workflow the spreadsheet encoded from the delivery medium that had become unreliable, moved event data to a structured backend, and when CMS forms damaged bulk editorial work, restored tabular editing through CSV templates and batched imports rather than reverting or telling the team to adapt

About the project

The Blueprint is a free SXSW event guide for Austin whose community, editorial voice, and trusted spreadsheet predate the software. I began building the web application in 2021 and have owned its product and technical implementation end to end since.

Organization: When Where What
Timeframe: 2021–present

80,382
Registered users: 4,304
Activations across years: 358
Staff picks

Overview

Editing the guide and delivering it

The Blueprint began with an editorial team publishing event information in a spreadsheet. As the audience grew, the sheet was carrying both the work of assembling the guide and the work of delivering it to readers.

I moved the delivery into a web application and later migrated the data to Strapi and PostgreSQL. That gave me a structured model and API, but the CMS forms made bulk editing harder. I brought tabular editing back through CSV templates and batched imports, keeping the backend responsible for storing and serving the records.

Reading the existing workflow

The 2019 When Where What Spreadsheet had a tab for each festival day, a Master tab, and a tab called “The days before...” Each event had a name, start and end times, venue, and notes. Editors could compare a day's listings without opening each one separately.

The “Free Booze?” and “Free Food?” columns also carried uncertainty. Entries such as “Not sure,” “Pretty sure yes,” and “Yes, lunch til 2” told readers more than a checkbox would. The sheet held judgments about what the team knew and what a visitor could expect.

That workflow belonged to the editorial team. My job was to support it while changing how the information reached a much larger audience. Replacing the file required understanding which parts of the work depended on its shape.

The original Friday March 8 tab shows event times, venues, free-food and free-booze judgments, and working notes. — The 2019 day tab keeps times and uncertain answers in the same working grid. Courtesy of When Where What & The Dirty Team.

The original The days before tab groups March 4 through March 7 events, with times and qualified food and drink notes. — The days before tab uses the same columns while grouping several dates in one view. Courtesy of When Where What & The Dirty Team.

Improving delivery and slowing editing

The first separation kept the sheet as the source of truth. An Apps Script layer normalized and shaped its rows for a mobile web client. Editors continued working in the same place while readers received a different presentation. The script source has not been recovered; this part of the history is my account of the work.

Later, I moved the records to Strapi with PostgreSQL on Heroku. Content types, relations, and validation made the data easier to use consistently. CMS forms gave editors a way to work on individual records.

The difficulty appeared across records. Scanning many events, spotting an incorrect time, or making several related corrections had been straightforward in a grid. Working through separate forms added navigation and removed that shared view. I had improved the data structure while making a frequent editorial task slower.

Solution

Returning the grid as an input

I added CSV templates and batch imports so editors could prepare multiple activations at once. The importer associated them with the relevant main event and validated the input. The interface exposes a mismatch in the error handling: the preview says invalid rows will be skipped, but the backend rejects the entire invalid batch. Correcting the missing name allows both rows to be imported as drafts.

The template made the expected columns explicit. It also created a contract I had to maintain as the model changed. Editors could still use CMS forms for individual records; the import added a path for work that benefited from seeing many entries at once.

The blank activation template records that input format and contains only column headings. The upload sequence below shows both the failure and the corrected outcome with representative records.

I applied the same approach to other recurring tasks: user exports, bulk activation uploads, and scheduled geocoding became admin operations. Those tools needed to express the task in terms someone could operate without manually intervening in the database.

The import preview warns that one row has errors and says it will be skipped. — The warning promises to skip the invalid row; the backend instead rejects the entire batch because one row is missing a name.

The import dialog remains open after the batch is rejected. — The warning promises to skip the invalid row; the backend instead rejects the entire batch because one row is missing a name.

The corrected import preview proposes creating two activations as drafts. — After correcting the same row, the preview offers two representative draft activations.

The results table shows two newly created activations, both marked Draft. — The corrected import created two drafts. This list and the recorded response establish successful correction, not partial success from the invalid batch.

Cropped data import panel displays CSV import, template download, Force re-geocode, and geocoding controls. — The admin panel shows the import and geocoding controls before either operation runs.

Batch import restores tabular editing. Forms remain available for individual records, alongside routine admin operations.

The team, data store, API, and public product keep their positions. The marker identifies the observed delivery or editing problem—not every possible failure. CSV validation still has the preview/backend mismatch described above.

Reflection

Keeping the workflow without restoring the old delivery

The CSV path let me retain the structured backend without requiring the team to do all of its work through individual forms. It also left two ways to change the same records, with templates, validation, and error messages to maintain alongside the CMS.

The earlier Apps Script step had preserved editing while changing delivery. During the CMS migration, I changed both and only recognized the editing cost through use. That correction matters more to me than the choice of file format: I had to account for the team's work as part of the system I was building.

I can point to the importer and admin tooling as implemented changes. I do not have a measured before-and-after editing time. The basis for this decision is the workflow regression I observed and the input path I built in response to it. The capture also leaves a concrete issue to address: the preview and backend need to describe the same failure behavior.