Airtable for the music business.
If you have built release tracking and invoicing in it, you built something real. The question is who maintains it next year.
Stop maintaining the system you built.
The same records — deals, invoices, catalog, splits, releases — in something where the music logic is the product's job rather than yours.
Credit where it is due
A team that has built working release tracking in a database tool has done real systems work. It usually means someone on that team understood the workflow well enough to model it, which is rarer than it sounds and worth more than the build.
We are not going to pretend that base does not work. It does. What we would ask is a different question.
What you became responsible for
Every rule you encoded is now yours to keep. When a deal type appears that the base was not shaped for, someone adds a field. When a collaborator needs to see one client and not the others, someone works out the permissions. When the person who built it moves on, the base is still there and the reasoning is not.
That is not a flaw in the tool. It is what building on a general-purpose database means: the flexibility that let you model your workflow is the same flexibility that makes you its maintainer.
What is the product's job here instead of yours
The music model is built in. Compositions and recordings are different things. Writers, publishers and the identifiers linking them are their own records. Publishing and master splits are separate pools that never inherit from each other.
Invoices start from deals. Record, publishing, master, brand and catalog deals carry their invoices, with line items, quantities, multi-currency, VAT and payment terms already in the shape a music invoice needs.
Contract terms come out of the contract. Drop the agreement in and the terms are extracted, rather than read once and retyped into fields.
Catalog data is enriched for you. Registrations and identifiers are filled in from industry data rather than pasted in by hand.
Cross-company access is a feature, not a workaround. A client's manager, business manager, label contact and lawyer each get the right level in that client's workspace.
Releases have a real shape. Tracks, artists, assets, credits, territories and dates, with what is still outstanding visible rather than remembered.
Why teams move off it
The base works. What tends to end it is not a failure but an accumulation — the same four things, in roughly this order.
Nothing flows in on its own. A general-purpose database has no idea where a registration or a royalty statement comes from. Every row is somebody's import, so the base is as fresh as the last time a person sat down with a CSV.
Permissions were built for your team, not the industry's. A client's attorney and a label contact need different slices of one client's records. Modeling cross-company access inside a tool that thinks in bases and workspaces is a project of its own.
The maintenance never ends. New deal type, new field. New collaborator, new permission puzzle. Whoever designed it owns it forever, and when they leave the base survives and the reasoning does not.
It was never built for this. That is the root of the other three — and the reason the work compounds instead of settling down.
The switch is the part people dread
Fair. It is also the part we do rather than ask you to. Bringing an existing base across and setting the workspace up is white-glove, and the goal is that the team feels the change within days rather than after a quarter of data entry.
Nothing about your base has to be thrown away to evaluate this. It stays exactly where it is until you decide otherwise.
Common questions
We already built this and it works. Why move?
Because the build was the easy half. The maintenance, the permissions for people outside your company, and what happens when whoever designed it moves on are the parts that get expensive later rather than now.
Can we bring our existing base across?
Yes, and we do it rather than hand you an importer. Importing from a spreadsheet or database tool and setting up the workspace is white-glove.
Is this less flexible than what we have?
In the places where flexibility was costing you, yes, deliberately. You cannot reshape what a composition is, because the point is that you no longer have to decide. Where the work genuinely varies — deal types, currencies, terms, line items — it flexes.
What about the reporting and views we built?
Bring the questions, not the views. Most of what teams built views for — what is unbilled, what is outstanding, what a client's catalog is missing — are questions the system answers directly rather than layouts you assemble.
You proved the workflow. Let something else maintain it.
