Taking “Blue” out of the domain model
The Blueprint · shipped 2021–present
- Role
- Platform Architect / Sole Engineer
- Timeframe
- The refactor followed several years of the product being used as built.
- Technologies
- Strapi
- Skills
- Product and technical architecture
- Strapi schema design
- Domain refactoring
Replaced the two content types that still carried placeholder names, Spreadsheet and Blue Sheet Event, with Main Event and Activation, only after accumulated use showed what the domain actually was. The curation layer, Bluelist and Bluelist Item, kept its names: the community had already renamed that lineage before the software existed.
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
When the model outgrew the festival
The first Blueprint content model inherited names from the tools the editorial team used. A Spreadsheet contained Blue Sheet Events. That was understandable for the original festival guide, but the same model later supported a studio tour and other programming.
I renamed those two types to Main Event and Activation after seeing the relationship hold across those uses. I kept Bluelist and Bluelist Item because they described an editorial concept the community already recognized.
Two sheets with different purposes
The When Where What Spreadsheet organized events by time. Its day tabs, start and end times, and venue columns helped someone find what was happening during the festival.
The Bluelist organized a selection by judgment. Its annual tabs included RSVP status and High or Medium priority, helping someone decide what to attend and whether they could still get in. Both were spreadsheets, but they supported different decisions for the reader.
The initial software carried both into the content model. Spreadsheet and Blue Sheet Event described the event inventory. Bluelist and Bluelist Item described the curated selection drawn from it. The relationship was useful even though the names came from different places.
The community had already given the VIP-list lineage its own name before I built the software. The public guide retained the name of its file format. I carried that temporary description into the schema.
Using a festival model elsewhere
East Austin Studio Tour, When Where What Week, and Spurs Week used the model while its types still had the original names. A program could contain individual happenings without requiring a different record structure for each use.
The mismatch was in explaining those records. When I worked on a studio tour, I still had to treat the containing program as a Spreadsheet. The translation followed me into queries, admin screens, and conversations about the system.
Leaving the names in place was viable. The product had already supported these uses, and no immediate failure forced a rename. I chose to change them because the repeated relationship had become clearer than the original vocabulary. I had more evidence for the name than I did when the only example was one festival.
Solution
Naming the relationship
Main Event names the container with its dates and identity. Activation names an individual happening within it. Those names retain the distinction between the program and what someone can attend inside it.
The curation types kept their names and continued to sit over that inventory. Removing “Blue” everywhere would have erased a distinction people actually used. I only changed the pair whose names still referred to the original tool.
This was a change in vocabulary around an established relationship. I did not need the studio tour or other programs to acquire a new shape to fit it. The admin dashboard's separate activation and staff-pick counts also reflected the difference between available events and editorial selections.
- Spreadsheet
- ContainsBlue Sheet Event
Following the old names downstream
Changing a content type reaches beyond its definition. The old vocabulary can remain in exports, saved queries, URLs, integrations, and the habits of people who learned the earlier system. A cleaner schema does not automatically update those uses.
I accepted that migration cost because I was already doing the translation repeatedly. It still needed to be treated as a change to a used system, with its earlier names accounted for. I do not have a measured reduction in integration or editing time to attach to the rename.
Reflection
Clearer names still leave migration work
Working on the later uses made the mismatch visible to me directly. I could see that the relationship continued to fit even when the name did not. That gave the refactor a narrower purpose than designing a general events platform from the beginning.
Waiting preserved a working model until I had examples to compare. It also meant more people and code had learned the earlier vocabulary by the time I changed it. Both consequences belong to the decision.
The result was a model that described what the product already supported while retaining its editorial language. The evidence came from the team and community using the system across cycles. My contribution was recognizing which names needed to catch up with that use and carrying the change through the model.