I’m building RouteFlow - a small SaaS for climbing gyms and route setters.
I started working on it because route setting involves a lot more than putting holds on a wall. Someone has to keep track of routes, sectors, setting sessions, setters, tasks, rotation and eventually what needs to come down and be replaced.
A lot of this can still end up scattered between spreadsheets, notes and people’s heads.
RouteFlow is my attempt to put the operational side of route setting in one place.
Right now it includes:
route and sector management
route age and rotation tracking
setting session planning
setter management and workload
Kanban-style setting tasks
grade distribution planning
route analytics
QR tags for climber feedback and ascent logging
There’s a working demo online:
It’s currently deployed on AWS as a test/demo environment, so it doesn’t have a proper domain yet. I’m deliberately keeping it this way while I’m still building and testing the product.
This is also a learning project for me. I’m building it with Django and React, using AI quite heavily along the way, but I’m trying to understand what I’m building rather than just generating code and hoping it works.
I’m currently looking for feedback from people who actually work in climbing gyms or set routes.
If you’re a setter, gym manager, or just someone who has dealt with the operational side of route setting, I’d be interested to hear what I’m missing - or what I’m overcomplicating.
Still early, but it’s working and I’m continuing to build it.
Climbing gyms are a really underserved niche. Most gym software is generic fitness management that doesn't understand climbing-specific workflows. This kind of vertical specialization is where SaaS gets built. Curious what drove the choice of climbing over other sports?
Pretty simple reason actually - I climb. :) I spent quite a lot of time in climbing gyms, so when I was looking for an idea for a project to build while learning Django and React, climbing was a natural place to look.
I started thinking about how route setting and rotation are managed, liked the idea and basically started building it from there. As I've mentioned in a few comments here, I probably did some of it backwards - built what I thought made sense first and now I'm finding out how gyms and setters actually work and whether there's a real product in it.
Solid update. I have been fighting the same discovery problem on a Discord directory side project — quality supply beats more listing sites. Thanks for writing this up.
How are gyms deciding a route’s rotation date today—fixed intervals, climb traffic, or setter judgment? Capturing the reason a route is due for replacement could make the analytics useful beyond a task list and help you validate which signals managers actually trust.
From the feedback I've had so far, it seems to be a mix. Age is often the baseline, but setters have also mentioned traffic/popularity, how dirty a route has become, grade distribution and even needing the holds for another set. And every gym seems to do it a little differently.
I like the idea of tracking why something was actually taken down though. Right now RouteFlow treats age as one of the main signals, but recording the reason for the decision could be much more useful over time than simply marking a route as old.
Opened the demo, and the landing page explains the product well. Two small things I noticed as a first-time visitor, since your first impressions right now come from cold outreach:
The browser tab title says "Belay Route OS — Alpine Minimal Pro", not RouteFlow. That title is what shows up in tabs, bookmarks and some link previews, so a gym manager who saves the link later won't find it by name.
The label above the demo accounts is in Polish ("Konta demonstracyjne") while the rest of the page is in English. Minor, but it reads like a leftover, and at this stage people judge the whole product by details like that.
For the outreach itself, a one-minute screen recording of the rotation view filled with that gym's own sectors (usually visible on their website or Instagram) tends to get more replies than a demo link. People answer things that are obviously about them.
Yeah, the first version was in Polish, but the plan from the beginning was for RouteFlow to be available internationally. It's been translated to English, although, as you noticed, there are still some Polish leftovers. Thanks for catching that.
And the idea with the short video is interesting. I can see how showing something already filled with a gym's own sectors would make the outreach feel much more relevant than just sending a generic demo link. I'll definitely test that approach.
Excited to see final look
This is a solid use case for a lightweight operations system. One thing I’d consider adding is the customer/user feedback loop alongside the internal workflow.
For example, you could track feedback coming in from QR codes and move it through something like New → Reviewing → Action needed → Resolved, while keeping notes and follow-ups attached to each route. That way, feedback doesn’t just get collected—it becomes an actionable task.
As you get more gyms testing it, tracking leads, conversations, demos, feedback and follow-ups in the same kind of structured pipeline could also make the business side much easier to manage while you’re still focused on building the product.
Good that you are asking what they would replace. One test: ask a gym what happened the last time a rotation ran late and what it cost them (a rerun, an argument). Write down their exact words.
That's a good one. Asking about the last time it actually happened is probably much more useful than asking whether late rotations are a problem in general. I'll add that to the questions I'm using with gyms.
Niche communities like climbing are great for this. Do you plan to add any social or friendly-competition features for the gym members?
Not at the moment. I've been trying to keep RouteFlow focused more on the operational side for gyms and setters rather than turning it into a social app for climbers.
The QR feedback is probably the closest thing to the climber side right now. I wouldn't rule out social or competition features later, but first I want to find out whether the core route-setting workflow is actually useful enough on its own.
Clean, practical project. Using AI as a learning accelerator for Django and React while maintaining ownership of the architecture is a great way to build. How are you handling offline mode or spotty connectivity inside the gyms, or is it strictly desktop/tablet for the staff right now?
Right now it's online only. I haven't built an offline mode into the MVP, and initially I was thinking mostly about staff using it on desktop/tablet.
But spotty connectivity inside gyms is a good point and honestly something I haven't really considered yet. I'll add that to the things I want to ask about when talking to gyms and setters.
This looks like a really useful idea, especially for keeping route setting tasks and rotation organized in one place. The combination of route tracking, workload management, and feedback logging makes a lot of sense.
The fact that you’re building it while learning Django and React also makes it an interesting project. Best of luck with RouteFlow!
https://jetza.us/
Revenue milestones that looked impossible a year ago now seem achievable. The compounding effect of consistent content marketing + product improvements + word of mouth is slow at first but accelerates. Month 1-6 was painful. Month 6-12 things started clicking.
The feature list is long for a product without a paying gym yet. I'd cut it to the one screen a head setter opens every Monday (probably session planning plus route age) and sell just that to five gyms, and put it on a real domain first, since a raw IP address makes a gym owner hesitate to enter anything. What are gyms using today, and which part would they actually pay to replace?
That's fair. The current demo is broader because I initially wanted to build the whole basic workflow and use it as a learning project as well. At this point though, I'm not looking to keep adding features -I'm trying to figure out which part of it is actually worth keeping at the center.
From the conversations so far, spreadsheets still come up a lot, but I don't have enough evidence yet to say which workflow gyms would actually pay to replace. That's exactly what I'm trying to find out now. And yes, the raw IP is just the current AWS demo setup, but I take the point about how it looks from the gym's side.
Nice to see the operational side of climbing treated as the product, not an afterthought. The chalky-hands point resonates: if feedback asks too much of the athlete or coach in the moment, it won’t happen. We’re working on a related problem at Vidi AI: athletes film practice, then rarely rewatch; the app watches the clip and gives one concrete thing to work on next time. If useful, the iOS app is here: https://apps.apple.com/us/app/vidi-ai-sports-analysis/id6758360737. Curious whether you’ve considered tying route and grade context to short clips from setting sessions or climber feedback.
Nice niche. I build software for a different hands-on trade (renovation crews) and two things surprised me that probably apply to setters too.
First, people on the wall or on site won't type. Anything that takes more than a few taps on a phone with chalky or dirty hands doesn't get used, so photos and one-tap actions beat forms every time. Your QR tags are a good sign you're already thinking that way.
Second, the feature that paid for itself first for us wasn't the fancy one. It was the boring thing that stopped an argument (for us, the client signing off extra work before we did it). I'd ask gym managers which recurring disagreement or lost hour they'd pay to get rid of, and build that first. From your list, route age and rotation tracking sounds like the closest candidate.
Good luck with it.
That's a really useful comparison, especially the point about people not wanting to type while they're actually working. I've been thinking about what information RouteFlow should track, but probably not enough about how little interaction it should take to actually update it.
And the "boring thing that stops an argument or saves an hour" is a good way of framing the problem. A few people here have mentioned route age and rotation as well, so that's definitely one of the workflows I want to dig into with gyms.
Vertical SaaS built on real pain you experienced yourself is one of the cleaner paths to early customers. You know the vocabulary, the frustration points, and who to call. The scattered-spreadsheet problem in climbing gyms is exactly the kind of thing that never gets solved because the niche is too small for big software companies and too specific for generic tools.
How are you approaching the first gyms? Direct outreach to route setters you know, or going through gym owners?
I do have some background in climbing and spent quite a bit of time climbing in gyms, so I'm familiar with how they work from the climber's side. But I don't already have a network of route setters or gym owners to rely on.
So right now I'm mostly looking for gyms and setters through direct outreach and climbing communities. I'm trying to talk to both sides rather than assume too early who the main user - and eventually the buyer - should be.
The move from scattered spreadsheets, notes and people’s heads into one operational workflow really resonates. One question I’d ask early is which workflow has the highest cost of being wrong—rotation, setter workload, or feedback? That might help prioritize the smallest paid wedge. QR feedback is a promising angle; I’d also test whether gym managers need exports and history before adding more analytics. A working demo plus a clearly defined first user group is a strong starting point.
That's a useful way to look at it. I've mostly been thinking about which part of the workflow people find useful, rather than where getting it wrong actually costs them the most. That's probably a better question to bring into the conversations with gyms.
And I agree on exports/history before adding more analytics. At this point I'd rather find the small part of RouteFlow that gyms actually rely on than keep adding features to the demo.
Useful share. When retention is still fuzzy, I pause acquisition experiments and just watch what people do after the first win moment.
Makes sense. I'm probably one step earlier than that with RouteFlow though - I'm still trying to get enough gyms and setters actually using the demo to see what that first win moment even is. Once I have that, watching what they come back to should tell me a lot.
I think in future we need this type of OS which helps to maintain stress on life.
Yeah, that's part of the idea - less time spent keeping track of everything manually, and more time on the actual work.
The operational focus feels well chosen—rotation, workload, and route age are the kinds of details that disappear in generic gym software. I’d be especially curious whether setters prefer a calendar-first view for upcoming resets or a route-first view for each sector. That choice could reveal the natural unit of work for the product.
That's a good question. Right now RouteFlow has both sides of it — planning upcoming setting work and tracking routes within sectors - but I don't know yet which one feels more natural as the main view for actual setters.
That's definitely something I want to pay attention to when I get the demo in front of more people from climbing gyms.
A lot of this can still end up scattered
Sure, it's still "just" an MVP at this point. What do you mean by scattered though - the data itself, or the workflow across different tools? That's exactly the kind of thing I'm trying to identify at this stag
Nice niche. I'm building a running app, so sport tools are close to my heart. The QR tags for climber feedback are a cool idea. How are you finding gyms, cold outreach or setters you already know?
Thanks! I'm still at the stage of finding gyms and setters to talk to. So far it's mostly cold outreach and looking for relevant communities — I don't have an existing network in the climbing industry.
I'm mainly trying to get honest feedback before I build too much around my own assumptions.
Keeping route age/rotation tied to a calendar and workload view seems like a strong starting point. I’d make the route’s history (setter, grade, changes, feedback) easy to audit so a manager can spot recurring problems before resetting a whole sector. For the demo, a small import/export path from existing spreadsheets might also reduce the first migration hurdle.
Route rotation, setter workload, and QR feedback in one place feels like the right wedge; the “what needs to come down” clock is a wonderfully concrete pain point. I’d keep validating the smallest workflow a gym would retire its spreadsheet for—otherwise the Kanban board may become a very organized second spreadsheet 😄
Thanks, that's useful. The route history is already part of the idea, especially tracking the setter, grade and changes over time. I hadn't really considered the spreadsheet import/export as part of the first migration step though. That's definitely something worth keeping in mind when I test the demo with gyms.
Have early conversations with gyms or setters revealed one workflow they would actually replace their current system for, or is the demand still spread across the broader RouteFlow feature set?
Not really yet. I have a few conversations and the route-setting workflow seems to be the most interesting part so far - planning resets, assigning tasks to setters, tracking what was actually set, and keeping the history in one place.
But I don't have enough feedback yet to say that gyms would actually replace their current system with it. That's what I'm trying to find out while building it.
The route-setting workflow sounds like the clearest wedge so far. If you’re open to it, what’s the best email to reach you on?
Sure - you can reach me at efowski@gmail.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.
RouteFlow with QR tags for climber feedback is a solid ops shape. When setters or gyms get accounts, I'd check the email domain has MX at signup so invite and rotation alerts don't bounce into a black hole.
Good point. I didn't think about the MX check yet. Definitely something to add once I build the invitation flow. Thanks!
Makes sense to add it with the invitation flow. When you do, treat a Null MX or a domain that doesn't exist as a hard no, but let a lookup timeout through and log it, since a timeout tells you nothing about the domain.
When you get to the invitation flow: I built a small API that does the domain side of this in one call (does the domain exist, MX or Null MX, known throwaway providers), and it treats a timeout as unknown rather than a failure. Say if you'd like a link.
Yeah, that makes sense. I hadn't considered treating a timeout differently from an actual negative MX result. I'll keep that distinction when I add it to the invitation flow.