Owning Our DNA

The bottleneck we keep hitting

Every SpaceMusic interface is driven by what we call its DNA — structured tables describing every parameter, page, and control. Today that DNA lives in a Google Sheet, and getting a change from the sheet into the actual product is a manual relay: download a CSV, drop it in the right folder, rebuild.

That was fine while everything ran locally and one person drove it. As we move to web interfaces, a shared cloud library, and more people touching the configuration, the relay becomes the thing that slows us down — and the data we depend on most isn't really ours. It sits in a spreadsheet we rent from Google, with no live link to the product and no real ownership of its history.

This memo lays out a direction we have now tested end to end, not just sketched: move the DNA into a database we host, edit it live, let changes flow to the product automatically — and keep the friendly visual tools we already built at diagram.spacemusic.tv.

What the DNA is, and how it flows today

The DNA is two linked things. First, a list of parameters — every slider, button, and dropdown, each with a type, a default, a range. Second, a layout that places those parameters into a hierarchy of pages, zones, sections, and groups — what becomes the on-screen interface. The same parameter shows up in both: defined once in the list, then positioned by the layout.

Today these live as tabs in a Google Sheet, and the flow runs one way only: someone edits the sheet, downloads it as a CSV, commits that file to the repository, and a code generator turns it into the running app. There is no live connection, no edit history beyond the sheet's, and the visual tools we built can only ever look at a snapshot someone exported by hand. Every new dataset we want to manage this way inherits the same manual pipeline.

The decision: own the data, keep our face

The shift is simple to state. Put the DNA in a proper database that we host — at dna.spacemusic.tv. People, and AI assistants, edit it there, live. The visual tools we already built stay exactly as they are and read from it. When the data changes, a trigger rebuilds the product. The database becomes the single source of truth; the spreadsheet retires.

Read it left to right. Editors — and an AI assistant through Directus's built-in MCP connector — write to the store. Our SvelteKit app stays the everyday face: the same diagrams and a familiar table view, in our own look, talking to Directus over its API. On change, a build trigger fires the code generator, and the product updates. And because it is just a database, the same store can hold any other dataset later, not only the SpaceMusic UI DNA.

Why Directus, and what we'd have done instead

We did not want to build a database-with-a-nice-interface from scratch — that is reinventing Airtable, the single largest piece of work here and a permanent maintenance burden for the data our builds depend on. So we surveyed the self-hostable "Airtable-like" tools, plus a build-it-ourselves baseline, scored against what we actually need: linked records, an API our tools and our code generator can read, edit-history we can trust, and automation to trigger a build.

1. Grist — the runner-up. Excellent linked records and the most spreadsheet-like editing for non-technical people, with a cleanly open-source core. We'd pick it if a familiar spreadsheet feel mattered more than API and audit strengths. strong fit · would-choose-if editing-comfort is the priority
2. Teable, NocoDB, Baserow — capable, but gated. All three handle linked records well, but the safety net we need (edit history, fine-grained permissions) or the build automation sits behind paid tiers, or the licence and maturity gave us pause for a system-of-record. partial fit · key safeguards behind paywalls
3. Build our own — most control, most cost. By far the largest effort, and we would own every bug in the source of truth our product is generated from. What we'd reuse from the existing tool is the surface (the diagrams, the shell); the hard core would all be new. rejected · highest effort + permanent upkeep
4. Directus — chosen. API-first, with the source-of-truth safeguards in its free core, a built-in AI connector, and free use at our scale. strong fit · best safety net in the free tier

Directus won on three things. It is API-first — our diagrams and our C# code generator read the same clean interface, no exported file in the middle. The things that make a source-of-truth safe — a full audit log, per-record history with one-click revert, and an optional draft-then-publish workflow — are in its free core, not a paid add-on. And it is free to self-host for an organisation our size (under their Open Innovation Grant). The one capability it lacks — auto-computed roll-up columns — does not matter for us, because our code generator already does that assembly. Nothing locks us in either: the data lives in plain SQL and exports to CSV any time, so Grist (or anything else) remains a fallback.

What we already built and tested

This is not a paper plan. We ran a working spike end to end, against the real SpaceMusic DNA, and the parts that carried real risk are now answered. Concretely, we:

• Confirmed the model fits the real data. 710 unique parameters, 521 of them shared across both DNA files, 612 layout placements — and every placement resolved to a parameter, zero loose ends. The "define once, link everywhere" idea isn't theoretical; it's already how the data is shaped.
• Stood up Directus and loaded the real DNA (710 parameters + 612 placements) over its API, with the parameter-to-placement link live: ask the API for a placement and it returns the placement's layout plus the linked parameter's definition.
• Proved the build contract round-trips. We regenerated the product's Pro UI CSV straight from the database and compared it to the real file: identical on 612 / 612 rows, on every field the code generator reads.
• Showed edit-once-propagates. We changed a single parameter in the master, and the rebuilt product file changed with it — automatically, through the link.
• Confirmed the AI connector is in the free core — Directus's MCP server ships with the version we'd run, no upgrade required.
• Rendered the Directus data in our own tool. We pointed the actual diagram tool at the database's data and drew it — the full sunburst and the table — in the diagram.spacemusic.tv look, with no Directus interface visible anywhere.

In plain terms: the questions that could have sunk this — does the relational model fit our real data, can we rebuild a product file the generator accepts, and does our diagram tool still look like ours? — are all answered yes. What remains is product work, not unknowns.

How we'd roll it out, and where it goes next

Three steps, increasing effort, each usable on its own. We compare effort relative to each other rather than in calendar time — most of the building is done by AI agents, so wall-clock estimates would mislead. The bars show the shape of the work:

Set up + white-label. Install Directus at dna.spacemusic.tv, import the DNA (already scripted in the spike), and theme it to our design system — logo, colours, trimmed interface — so even its admin screens don't shout "Directus". Small.

Hybrid — where we start. Our diagram tool reads live from Directus; the common edits (the table, the values) happen in our app, in our look; the long tail (schema changes, bulk operations) happens in the white-labelled Directus. We get the win early without building a complete editor first. Medium.

Headless — if and when we want it. Pull every editing surface into our app so Directus becomes invisible to the team, and wire the automatic build trigger. Larger, and genuinely optional — we move toward it only if the hybrid leaves something wanting.

Where it goes next is the part worth holding onto: because it is just a database, it is not limited to the SpaceMusic UI DNA. The design-system tokens, other product configurations, future datasets — each can live in the same store, cross-reference each other, and cost almost nothing extra on the backend. And the built-in MCP connector means an assistant can edit the DNA on request — "bump the header font size" — writing through the exact same permissions a person has. Whether each dataset gets a bespoke diagram, a plain table, or its own small tool is a question for later; the foundation is shared.

Why this matters

"The DNA stops being a spreadsheet we download and becomes a system we own — edited live, with history and permissions, that we can point anything at."

Today, changing the product means a manual relay through a file we don't really own, and every new dataset inherits that same chore. After this, a change is an edit in a tool that looks like ours, with a record of who changed what, the ability to undo, and a button-free path to the running product. We keep everything we built, rent only the boring middle, stay free at our scale, and remain free to leave. If we don't do this, we keep paying the spreadsheet tax — and rebuild the same fragile pipeline the next time we have data worth managing.

Glossary

Terms used in this document, in plain language.

DNA

Our name for the structured tables that define a SpaceMusic interface — its parameters and their layout. The data this memo is about owning.

Directus

An open, self-hostable platform that turns a database into an editable admin interface plus an instant API. The backend we've chosen to host the DNA.

MCP

Model Context Protocol. A standard way for AI assistants to connect to a tool. Directus ships an MCP server in its free core, so an assistant can read and edit the DNA within set permissions.

Linked records

A database relationship: a row in one table points at a row in another instead of copying it. Editing the original updates everywhere it's linked.

Headless

Using a backend purely through its API, with our own interface on top — so users see our app, never the backend's own screens.

White-label

Re-skinning a third-party tool with our branding so it looks like ours rather than the vendor's.

Code generator

The existing step that turns the DNA into the actual app code (the "codegen"). It currently reads a CSV file; it would read from Directus instead.

Round-trip

Taking the data out of the database, rebuilding the product file, and getting back exactly what we started with — proof nothing is lost in the move.

Pro UI

The SpaceMusic interface layer the DNA describes — the pages, zones, and controls a user sees.

Flow

Directus's built-in automation — e.g. "when the data changes, call the build". How the rebuild gets triggered automatically.

Open Innovation Grant

Directus's free, full-featured self-hosting licence for small organisations (under their revenue and headcount thresholds), which we qualify for.