I'm building a SaaS for independent record labels. But do they actually need it?

I've already started building the backend.

Django, Django REST Framework, PostgreSQL. Multi-tenancy works. Labels can have members, releases, formats, orders and transactions.

So naturally, this seems like a good time to ask a slightly inconvenient question:

Does anyone actually need this?

The project is called Label Mechanics, and it sits somewhere between my work as a developer and the amount of time I've spent around independent music and small record labels.

Like many software ideas, it started with a problem that looked much simpler at first than it does now.

Running a small label creates a lot of data

Let's say you're putting out a record.

You pay for manufacturing. Maybe mastering. Artwork. Promo copies. PR. Some ads.

You also spend time posting on social media, sending emails, contacting press, updating Bandcamp and doing all the other small things that come with releasing music.

Then the record comes out.

Now you have sales on Bandcamp or your store. Streaming numbers somewhere else. Social media metrics. Maybe results from an ad campaign. Costs sitting in a spreadsheet.

And after all of that, some surprisingly basic questions can be difficult to answer.

How much did this release actually cost?

Did the promotion make any difference?

Was spending money on ads worth it?

Was PR worth it?

What should I do differently with the next release?

Of course, labels do answer these questions somehow.

Spreadsheets exist for a reason.

So does experience.

Someone who has released 50 records probably has a pretty good feeling for what works for their label.

But "I have a feeling this worked" and "I can actually see why this worked" aren't quite the same thing.

My first assumption was probably wrong

My initial idea was fairly straightforward.

Build software that connects the operational side of a label with release economics and marketing.

Catalog. Releases. Costs. Sales. Promotion. Results.

Put the data in one place and the problem is solved.

Except there is an obvious issue with that idea.

Software like this already exists.

Once I started looking properly at the market, I found products covering label management, royalty accounting, distribution, marketing analytics and various combinations of all of them.

So "labels need a place where all their data lives" isn't a particularly interesting hypothesis.

It also made me rethink what I was actually trying to solve.

Maybe a small label doesn't need another dashboard.

Maybe it needs a better answer to a much simpler question:

What is actually worth my time and money?

That changes the product quite a bit.

Small labels don't necessarily need more marketing

This is another assumption I'm interested in testing.

A lot of marketing software is naturally designed around doing more marketing.

More campaigns. More data. More optimization.

But imagine a label run by one or two people with a limited budget and limited time.

Maybe the correct recommendation for a particular release isn't:

Spend another €200 on ads.

Maybe it's:

Don't.

Maybe a Bandcamp announcement, an email to the existing audience, a few posts and some direct outreach would produce almost the same result.

If so, that's useful information too.

Time matters here as well.

If one release required 15 hours of promotion and another required five hours for a similar result, the difference isn't visible if you're only looking at ad spend.

That's the direction I'm currently exploring with Label Mechanics.

Not necessarily how to make labels do more marketing, but how to help them understand how much marketing is enough.

What Label Mechanics is becoming

The current idea can be reduced to something like this:

RELEASE
   ↓
ECONOMICS
   ↓
MARKETING
   ↓
RESPONSE
   ↓
INSIGHTS

For every release, I eventually want to connect a few basic things.

What did it cost?

What did the label do to promote it?

How much money and time went into that promotion?

What happened afterwards?

And, most importantly, what can be learned from it before the next release?

That last part is where I think the project might become interesting.

After several releases, the useful comparison isn't necessarily against some generic "music marketing best practices".

It's against the label's own history.

Maybe €300 of paid promotion makes sense for Label A.

Maybe Label B repeatedly gets similar results without it.

Maybe press coverage matters a lot for one type of release and almost nothing for another.

I don't know yet.

And that's rather the point.

There is already a backend

This isn't only an idea sitting in a notes file.

I've already been building the backend in Django, Django REST Framework and PostgreSQL.

The current domain includes:

• labels and memberships
• releases
• physical formats
• tracks
• contacts
• orders and order items
• transactions
• release-level economics

It's multi-tenant, so users only have access to data belonging to their labels.

At a very simplified level, part of the domain currently looks like this:

Label
 |
 +-- Releases
 |     |
 |     +-- Formats
 |     +-- Orders
 |     +-- Transactions
 |
 +-- Members

A release can already be connected to its costs, income, formats and sales.

The next development step is the marketing side: campaigns and the activities around them.

One thing worth making clear here: I'm not building all of this alone.

I'm using ChatGPT extensively throughout the project. Not just for generating bits of code, but as a working partner for discussing architecture, reviewing decisions, researching the market, challenging product assumptions and planning customer discovery.

I still make the decisions, write and understand the code, test it and decide what actually goes into the project. But pretending there isn't an AI sitting next to me for a large part of the process would be a fairly strange way to document how I'm building this in 2026.

It also makes this experiment more interesting to me. I'm not only trying to find out whether Label Mechanics should exist. I'm also learning what building a real product with AI as part of the workflow actually looks like - where it helps, where it gets things wrong, and where I still need to stop and think for myself.

But I'm deliberately trying not to build too far ahead.

For example, I could create a large Performance model today with Spotify streams, Bandcamp sales, Instagram followers, wishlist numbers and twenty other metrics.

That would be easy enough.

It would also mean I'm deciding what labels need before asking them.

I'd rather not do that.

So now comes the less comfortable part

Talking to people.

I'm starting customer discovery with small independent labels to understand how they actually handle this today.

Not how I imagine they handle it.

I'm particularly interested in how labels answer questions like:

• How do you know whether a release was successful?
• How do you track its real cost?
• How do you decide how much promotion it needs?
• How do you know whether PR or paid promotion worked?
• Do you use data from previous releases when planning the next one?
• How much time do you spend collecting all this information?

There are still plenty of assumptions behind Label Mechanics.

I don't know whether this problem is painful enough for labels to change their workflow.

I don't know which data actually matters to them.

I don't know whether the smallest labels want software for this at all.

And I definitely don't know whether anyone will pay for it.

Those seem like fairly important things to find out before spending the next six months building features.

Why I'm writing about it here

I want to treat Label Mechanics as a real product experiment rather than another project where I build the application first and start wondering about users afterwards.

So I'll write about the process here as it develops.

There will be Django and backend work, because that's what I'm using to build it.

But I'm more interested in the decisions around the code.

Why does a particular model exist?

Why didn't something make the MVP?

What changed after talking to actual label owners?

Which assumptions turned out to be wrong?

How much does working with AI actually help when building something like this?

And eventually: does anyone actually want the thing?

If it works, great.

If it doesn't, I'd at least like to know why it didn't.

For now, that's where Label Mechanics is.

The backend exists.

The hypothesis exists.

Now it's time to see whether the problem does too.

Comments

[Neeraj Bhakta]

Good question to ask early. I'd suggest interviewing 5-10 labels about how they handle the problem today (spreadsheets, email threads). If they already spend time or money on a workaround, that's a strong demand signal. If not, it's probably a nice-to-have.