DEV Community: Paweł Mazur

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

Paweł Mazur — Tue, 27 Oct 2026 13:26:41 +0000

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.

RouteFlow — What Happened When I Finally Tested the Whole MVP

Paweł Mazur — Wed, 09 Sep 2026 21:34:03 +0000

In my previous RouteFlow post, I ended with a fairly simple goal: stop adding features and run the application from an empty account as if I were an actual climbing gym.

So that's what I did.

It didn't take very long to find the first problem.

Testing from an empty account

Until now, most of RouteFlow had been tested while individual features were being built.

This time I wanted to start from scratch and follow the actual process:

And I added one rule.

If I had to open Django Admin or manually fix something in the database to make the normal workflow possible, then v0.1 wasn't ready yet.

Simple enough.

The first test passed

I registered a completely new Gym Manager account.

The application logged me in correctly. The gym name appeared in the interface. The user had the correct role. There was no data leaking in from another gym.

Everything looked fine.

So initially, I marked the first step as passed.It wasn't.

When I checked the backend, I realised that registration had created the user, but it hadn't actually created the corresponding Gym.

The UI knew the name of the gym.

The database didn't know the gym existed.

gym_name is not gym

This came from a distinction I had deliberately made earlier in the project.

The user model contains both a textual gym name and an actual relationship to the Gym model:

gym = models.ForeignKey(
    Gym,
    null=True,
    blank=True,
    related_name='users',
    on_delete=models.SET_NULL
)

gym_name = models.CharField(
    max_length=150,
    default="VertiGym Warszawska"
)

That distinction itself wasn't the problem.

The registration serializer was.

It could store gym_name, and it could accept an existing gym:

gym=validated_data.get('gym'),
gym_name=validated_data.get('gym_name', 'VertiGym'),

But it didn't create a Gym when a new manager registered one.

So I effectively had this:

User
├── gym_name = "RouteFlow Test Gym"
└── gym = NULL

when what I actually needed was:

Gym
└── name = "RouteFlow Test Gym"
↑
│
User
└── gym =

This was surprisingly easy to miss because nothing immediately broke.

Registration worked. Login worked. The frontend displayed the gym name. From the user's perspective, the account looked valid.

Only when I tested the application as a complete system did the difference between displaying a string and having an actual domain object become important.

The fix was small

The solution wasn't particularly complicated.

During registration, if no existing gym is supplied, the serializer now creates one using the submitted gym name:

gym_name = validated_data.get(
    'gym_name',
    'VertiGym Warszawska'
)

gym = validated_data.get('gym')

if not gym:
    gym = Gym.objects.create(name=gym_name)

The newly created Gym is then assigned to the user:

user = User.objects.create_user(
    email=validated_data['email'],
    username=validated_data.get('username')
        or validated_data['email'],
    first_name=validated_data.get('first_name', ''),
    last_name=validated_data.get('last_name', ''),
    role=validated_data.get('role', 'gym_manager'),
    gym=gym,
    gym_name=gym_name,
    password=validated_data['password'],
)

Then I repeated the test.

New user: created.

New gym: created.

User assigned to that gym: yes.

Problem solved.

Then the actual workflow worked

After fixing registration, I continued through the complete workflow: creating setters, planning a Setting Session, assigning tasks, logging in as a Route Setter and eventually publishing completed work as a Route.

That part worked.

So did the less visible parts I was particularly interested in testing: role-based permissions, persistence after refresh and data isolation between gyms.

A Route Setter could work with their assigned tasks without getting access to manager-level operations. A Head Setter could manage the setting workflow without getting access to gym-level user administration.

And a user from Gym A couldn't suddenly access Gym B's routes, setters, sessions or tasks.

Most importantly, the core relationship I've been building RouteFlow around finally worked as one continuous process:

Sector → Setting Session → Setter Task → Route

Then I hit the second problem.I still had to open Django Admin.Sectors.

The backend already understands them. Routes and Setting Sessions use them. Gym isolation applies to them.

But there currently isn't a way for a new Gym Manager to create the initial sectors from the frontend.

To continue the test, I had to create them manually through Django Admin.

And that breaks the rule I set for myself before starting this test.

In the previous post I wrote:

If it requires developer intervention along the way, v0.1 isn't ready yet.

Well.It did.So v0.1 isn't ready yet.Not quite.

Working features aren't necessarily a working product

This was probably the most useful result of the whole test.Most of RouteFlow worked.The task workflow worked. Route publishing worked. Authentication worked. RBAC worked. Gym isolation worked. Setting Sessions worked.

But a completely new customer still couldn't get from registration to actually using those features without me stepping in.

That's a very different kind of failure from an API returning 500 or a React component crashing.

And it's also much easier to miss when development consists of implementing one feature at a time.

While building a feature, the database already contains the objects you need. You already have test users. Sectors exist because you created them weeks ago. Your account is already attached to a gym. The application slowly accumulates the environment it needs to work. A new user gets none of that.

Starting again with an empty account removes all of those assumptions.

In this case, it exposed two of them almost immediately.

One was a bug: registration didn't create the actual Gym.

The other was a missing piece of the product: there was no frontend workflow for creating the first sectors.The first one is now fixed.
The second one is next. So, is the MVP ready? Almost.

And "almost" means something much more concrete now than it did before running this test.

The core workflow survived. The three user roles behave as expected. Data isolation between gyms works. A completed setting task can travel through the system and become a real Route without manual database work.

What didn't survive was the onboarding around that workflow.So I'm not adding another major feature yet.

The next job is much less exciting: let a Gym Manager create and manage sectors without Django Admin. Then I'll delete the test data, create another completely fresh account and do the whole thing again.

If I can get from registration to a published route without touching the backend manually, then I'll be much more comfortable calling RouteFlow v0.1 usable.

After that, I want the next bugs to come from people who actually work in climbing gyms. I'm fairly sure they'll find some. That's the point.

The code

RouteFlow is still under active development, and the source code is available on GitHub.

This is the second post about building RouteFlow. In the first one, I wrote about the architecture, gym-level data isolation, the setting workflow and why a completed Setter Task isn't automatically a Route.

This time I stopped building long enough to actually use the thing.

Turns out that was useful.

RouteFlow — Building a Route Setting SaaS with Django and React

Paweł Mazur — Tue, 01 Sep 2026 09:59:04 +0000

Route setting in a climbing gym seems fairly straightforward when you're looking at it from the outside. Old routes come down, new ones go up, somebody grades them and the wall opens again.

There is quite a bit more going on behind the scenes.

Routes get old. Sectors need regular resets. Setters have to know what they're supposed to build. Someone needs to decide how many new routes are needed and which grades are missing. Then all of that has to be planned around people, dates and the fact that the gym still needs to operate.

You can manage a lot of this with spreadsheets.

Up to a point.

That's basically where RouteFlow started.

What I'm building

RouteFlow is a SaaS application for managing route setting in climbing gyms.

I'm deliberately focusing on the operational side of the gym rather than building another app for climbers to log their ascents.

At the centre of RouteFlow is a fairly simple relationship:

Sector → Setting Session → Setter Tasks → Routes

A manager or head setter plans work for a sector, decides how many routes should be created and assigns individual tasks to setters.

The setters work through those tasks, the routes get tested, and finished work can eventually become an actual Route in the gym's database.

That last part turned out to be more interesting than I initially expected.

Django on the backend, React on the frontend

The backend is built with Python, Django and Django REST Framework, with PostgreSQL as the database. The application runs in Docker.

The frontend is React with TypeScript and talks to Django through the REST API.

There isn't anything particularly exotic about that stack, and that's intentional.

I'm building RouteFlow as something that should eventually be used by actual climbing gyms. I would rather have boring technology with understandable behaviour than introduce another piece of infrastructure just because I can.

A gym has to actually own its data

Once RouteFlow started moving beyond basic CRUD, one of the first things that needed sorting out properly was data ownership.

The natural boundary is the gym.

A sector belongs to a gym. Routes inside that sector belong to the same gym. Setting sessions and the tasks created within them need to respect that boundary as well.

And simply hiding Gym B's data from somebody logged into Gym A wasn't enough.

The API itself has to enforce it.

So the Django querysets are scoped to the authenticated user's gym, and I've been testing the API by deliberately trying to retrieve and modify resources belonging to another gym.

Those requests return 404.

The same rule applies when creating relationships between objects. For example, a setter belonging to one gym shouldn't be assignable to a setting session in another one.

This is the kind of work that isn't particularly exciting in a screenshot, but it's much closer to the problems I expect a real SaaS application to have.

The setting workflow

A Setting Session describes a planned reset or setting operation for a sector.

It contains things such as the date, lead setter and target number of routes. From there, individual Setter Tasks can be created and assigned.

A task currently moves through:

Todo → In Progress → Testing → Done

It can also contain a target grade, hold colour, setter and due date.

Originally, getting a task to Done looked like the natural end of that workflow.

It isn't.

A finished task means the setter has finished the work. It doesn't necessarily mean RouteFlow has a new Route in its database.

So publishing became a separate backend operation.

Once a completed task is published, Django creates the Route and links it back to the original Setter Task. The operation is atomic, so if part of that process fails, it doesn't leave half-created data behind.

It also means the same task can't accidentally produce two routes.

That's a relatively small feature from the user's point of view — essentially an action in the interface — but it forced me to think much more carefully about where one part of the workflow actually ends and another begins.

Then I built the dashboard

The most recent part of RouteFlow is the operational dashboard.

By this stage the application already knew about setting sessions, tasks and published routes. The problem was that knowing something and making that information useful are two different things.

I wanted the dashboard to answer fairly mundane but important questions:

What's being set right now?

How far along is it?

What's coming next?

Is anything late?

Are there enough tasks assigned to actually hit the planned number of routes?

So an active session now shows its sector, lead setter, planned date, target route count and the current state of its tasks.

Task progress is split between Todo, In Progress, Testing and Done.

The dashboard also compares the target number of routes with the number actually published.

That distinction caused one small change in how I thought about completion.

At first it would have been easy to calculate session progress from tasks marked Done. But a done task isn't necessarily a published route.

If a session is supposed to produce 10 routes and six tasks are done but only four routes have actually been published, calling the session 60% complete would be misleading.

So RouteFlow considers it 40% complete.

It sounds like a minor detail, but those are exactly the details that start appearing once separate features have to work together as one system.

Things that need attention

The dashboard also has an Attention Required section.

Currently it catches things such as overdue tasks, overdue setting sessions and sessions where the number of assigned tasks is lower than the target number of routes.

I actually considered adding an alert for sessions without a lead setter while building this.

Then I realised the application already requires a lead setter when creating a session.

There was no point adding dashboard logic for a state the system doesn't allow to exist.

Removing that check was probably more useful than adding another dashboard card.

Where it is now

RouteFlow isn't finished, and I don't want to present it as if it is.

What works now is the core operational chain:

Setting Session → Setter Tasks → Task Workflow → Route Publishing → Operational Dashboard

The next milestone is mostly cleanup.

There is still some demo and fallback data left from earlier stages of frontend development. I'm removing that and checking the application screen by screen to make sure the API is the actual source of truth everywhere.

After that I want to run the whole thing the way a new gym would: start with an empty account, create the gym structure, add setters and routes, plan a session, assign the work, publish the resulting routes and see whether anything requires developer intervention along the way.

If it does, v0.1 isn't ready yet.

Once that works, the useful part starts: putting RouteFlow in front of people who actually run climbing gyms and seeing which assumptions were right and which ones weren't.

For me, RouteFlow is also a good example of the kind of development work I want to do more of: Django, REST APIs and applications where the interesting problems aren't just about displaying data, but about defining what should happen to it.

The code

RouteFlow is still under active development, but if you'd like to take a look at the project itself, the source code is available on GitHub:

I'll be sharing more of the technical decisions, mistakes and lessons from building RouteFlow as the project moves toward its first usable release.