Building RouteFlow — a SaaS for climbing gyms and route setters
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.
The MCP integration is an interesting direction. Removing the repetitive form-filling step makes sense, especially for developers already working inside Claude or Cursor. I also like the 7-day cohort idea because it gives a launch more time to collect feedback instead of relying on a single-day traffic spike. The bigger test for me would be how much of that visibility turns into meaningful visits, users, or customers after the launch window ends.
This is an incredibly smart way to look at niche SaaS distribution. Building for a highly specialized, operational physical space like climbing gyms means you are solving real, tangible inefficiencies that generic CRM or management software completely miss.
I’m currently building MarketPulse (an automated competitor price monitoring and repricing platform for e-commerce), and even though our verticals are entirely different, the core SaaS scaling principle is identical: the more specific the pain point, the stickier the software becomes. When you move past generic features and build workflows specifically for the unique operational rhythms of route-setters and gym management, you build massive defensive moats.
For a vertical SaaS like RouteFlow, the real unlock is often embedding seamlessly into the daily offline routines of the staff before scaling outwards. Excited to see how you map out your beta feedback and capture this market!
Thanks! The offline routine part is something I'm starting to think about much more now. A few setters have already pointed out that a whiteboard or spreadsheet can work perfectly well, so the software can't just add another layer of work for them.
I'm still trying to figure out where the actual inefficiency is before assuming RouteFlow solves one. :] But if there is a useful place for it, I agree that it has to fit into how setters already work rather than asking them to change everything around the software.
I think working out who the buyer is, the gym owner or the head setter, matters more right now than which feature sits at the centre. The setter feels the rotation and workload mess every week. The owner signs off the spend and cares about members staying. That's where your QR logging could do more than collect feedback. Weekly challenges on new sets, leaderboards between members, even club-versus-club comps, give climbers a reason to come back after every reset. That turns a setter tool into a retention story an owner will pay for. Before building any of it, I'd put the idea in front of a few owners and see if it changes the conversation.
Of the gyms you've spoken to so far, who would actually approve paying for this?
That's probably one of the biggest unanswered questions for me right now. I don't have a good answer yet as to who would actually approve the spend - and that's something I need to start asking much more directly.
The setter vs owner distinction makes a lot of sense. The setter might be the person using RouteFlow every day, but that doesn't automatically mean the problem is valuable enough for the owner to pay for it.
I'm a bit cautious about challenges, leaderboards etc. because that could quickly turn RouteFlow into a climber engagement platform, where there are already much bigger players. But I like the broader point: the value proposition for the person using it doesn't necessarily have to be the same as for the person paying for it.
So far I've mostly been talking to setters and people around climbing gyms rather than people actually approving software budgets. That's clearly a gap in my validation right now. :]
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.
The most important line in this whole thread is buried in your reply to mabdullah_built — that no gym uses any of the eight features yet — and it suggests the next thing to build isn't a feature at all. Since whiteboards, spreadsheets and KAYA/Vertical-Life are already in the mix, the useful question isn't what you're missing but which single artifact a gym would throw in the bin first, and the cheapest way to learn that is to run one gym's next set cycle inside RouteFlow yourself, in parallel with their whiteboard, writing down every moment you're forced to leave the tool. Two concrete notes: separate the user from the buyer, because setters feel the rotation and workload pain but the manager signs, and what moves a manager is member traffic plotted against route freshness per sector — which is precisely the report your QR ascent data enables and that no whiteboard can ever produce. Also fix the demo link before you talk to a single gym manager: a bare IP over HTTPS throws a full-page certificate warning in Chrome, which is a brutal first impression for a non-technical buyer, and a cheap domain with a proxy in front is an hour of work that removes the scariest thing about your product. On distribution, this niche is small, geographically clustered and almost entirely word of mouth — head setters rotate between gyms and talk constantly — so ten in-person visits to gyms within driving distance will outperform any online channel you could build, and one head setter who likes it introduces you to the next three. If you had to put a $50/month invoice in front of one gym tomorrow, which of the eight features would be the line item, and would you be pitching the head setter or the owner?
Running one real setting cycle in parallel with whatever the gym already uses is probably the most useful experiment anyone has suggested in this thread. It would answer a lot more than another round of feature questions.
And your $50 question is uncomfortable in a useful way.:] If I had to answer it today, I'd probably put rotation/route age + setting planning on the invoice and pitch it first to the head setter, because that's where most of the concrete problems I've heard about so far sit. But I don't yet have evidence that the owner would see $50/month of value in solving them - and that's the gap I need to test.
The traffic vs route freshness report is interesting too, especially because it gives the QR data a reason to exist beyond just collecting ratings.
And yes, direct gym visits are increasingly looking like the right next step. The Reddit conversations alone have already been much more useful than trying to guess the workflow from the outside.
Since you're building with AI heavily but want to understand the code, one habit that pays off here is writing the invariants down and testing them: a route can't be in two sectors, a setter can't be in two overlapping sessions, a stripped route can't take new ascents. AI-written code tends to satisfy the happy path and quietly break those. The QR ascent logging is where I'd test first: duplicate scans, scans of a stripped route, and phones syncing late.
On the thread above about recording why a route came down: if the lifecycle (planned, set, live, flagged, stripped) is stored as states in a history table with a reason column, rotation, grade distribution and analytics all become queries over one source, and you can answer "what was on this sector in March?" later.
Which of the features have you seen a real gym actually use so far?
The invariants point is a good one. I've actually been doing some of that while testing permissions and tenant isolation, but not systematically across the whole application. The QR edge cases you mentioned are definitely something I haven't tested deeply enough yet.
And I like the lifecycle/history idea, especially being able to answer something like "what was on this sector in March?" later. Route history is already part of RouteFlow, but I need to look at whether the model I'm using actually captures that lifecycle properly.
As for real gym usage: none of RouteFlow's features yet. :] That's the honest answer. What I've learned from setters so far is that gyms do track things like route age, rotation and grade distribution, but often with whiteboards or spreadsheets, while some use platforms like KAYA or Vertical-Life. I'm still trying to find out which part of that workflow, if any, is painful enough for someone to actually replace what they're using now.
Appreciate the honest answer. One cheap way to find the painful part: ask a head setter to walk you through the last time a set ran late or went wrong, and note which step involved retyping something or chasing someone. In tools like this the pain is often in a handoff (who strips what, who sets next, what the manager approved) rather than in tracking itself, since whiteboards and spreadsheets handle tracking fine. If a setter says "I rewrite this every week", that's your wedge, even if it's small.
Since KAYA and Vertical-Life come up, it may also be worth asking whether setters would use RouteFlow for the internal ops side alongside them, instead of in place of them.
QR tags for climber feedback are the part I'd lean into. Setters get tons of data about holds and dates, but very little about how a route actually felt to the people on it, and a quick scan-and-rate on the wall is about as low-friction as feedback gets.
A small idea from building a consumer app with streaks and XP: if climbers can log ascents per route, give them a tiny reason to keep logging (a personal "routes sent this rotation" count, or a badge when a sector gets reset). The engagement side gives you the traffic data that makes your rotation analytics trustworthy, and gyms can show it to members as a reason to come back. Good luck with the setter interviews!
Thanks! The QR feedback was actually one of the ideas I liked most when I started building this. The thought was exactly that - route age tells you one thing, but it doesn't tell you whether people are still climbing and enjoying the route.
The engagement part is interesting because that's the other side of the problem: the data is only useful if climbers actually bother scanning and logging regularly. I hadn't really thought about giving them a small personal reason to keep doing it.
I'm a little cautious about going too far into streaks, badges and the social side because then RouteFlow starts becoming a climber app rather than a tool for setters. But something as simple as a personal count might be worth testing.
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.
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.