DEV Community: Paweł Mazur

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.