Chris Hayden
←Showcase / Dec 2024 – Apr 2025, ongoing Live

Sloper

A climbing tracker for iOS and Android. I designed and built it, end to end.

Problem
Other climbing apps made logging a climb slow, and everything else in a climbing tracker depends on logging.
My role
Everything, solo: product, design, React Native code, the Supabase backend, and App Store releases.
Result
Live on iOS and Android since April 2025, with 500+ climbers and 10k+ climbs logged.
FIG. 1Home and Session. The session screen is where climbers spend most of their time.
Role
Everything. Product, design, React Native code, Supabase backend, subscriptions, App Store submission, support.
Team
Solo
When
Dec 2024 – Apr 2025, ongoing
Built with
React Native, Expo, Supabase, RevenueCat, TypeScript, v0, Codex, Claude Code
Links
WebsiteApp StoreGoogle Play

01Context

Sloper began as a design concept in 2020: a climbing log with the kind of tracking runners and cyclists already have. It stayed a concept until December 2024, when I started building it myself.

02The call

Logging a climb had to be better than any other app out there.

In some of the climbing apps I’d tried, you’d go through several screens before you could log a single climb. That was the standard to beat, because analytics, projects and leaderboards all depend on people actually logging. So only type and grade are required, every other field is one tap or can be skipped, and Save stays in the header so you never have to scroll to finish.

  1. Tap Add ClimbIt opens from the session you're logging.
  2. Pick a type and gradeThe only required fields. Color, height, result, and name are optional.
  3. SaveBack to the session, with the climb in the table and the stats updated.
TRY IT · THE REAL FLOW
TAPS—
SECONDS—

03Constraints

A

I had to do everything myself.

No engineering partner. Design, code, the backend, App Store submission and support were all on me.

B

A climb belongs to two things.

A climb sits in tonight's session and in a project you work on for weeks, and the two can't disagree about it.

04Decisions

Design the data before the screens.

I had never built a database from the ground up before Sloper, so a big part of the work was learning how schemas tie together and how to set up the tables I’d surface in the design. The trickiest piece was letting one climb sit in tonight’s session and in a weeks-long project without the two ever disagreeing.

The structure held up. New features layer on top without reworking the database.

Three Projects screens: the project list, a project detail with attempts, and project notes.
FIG. 2Projects: a climb you work on across many sessions. This is the object that made the data model hard.

The best feature should be free.

Sloper launched with everything behind a subscription. But logging is the best thing in Sloper, and if people couldn’t log a few climbs without paying, they never got far enough to see why the rest was worth it.

So I split it up. Logging, sessions, and basic stats are free, and analytics, projects, and leaderboards are premium. Conversions picked up after the change.

Two analytics screens: a grade distribution bar chart and a results donut with milestone badges.
FIG. 3Analytics moved into premium: grade pyramid, results, milestones.

A leaderboard that's just for fun.

The leaderboard is a way to see what your friends at the gym have been working on. Outside of a competition it’s hard to say who’s at the top in climbing, so I had to get creative about what it ranks.

The main board is total feet climbed, and three more count climbs in top rope, lead, and bouldering, so there’s something on it for everyone.

The friends leaderboard, showing total feet climbed this month and tabs for top rope, lead, and bouldering.
FIG. 4The friends leaderboard: total feet climbed, plus boards for top rope, lead, and boulders.

05Building it

From Figma file to the App Store.

I started in v0 with the Figma file open beside it, generating screens from my own designs and fixing a lot of what came back. Around version 300 the output started to degrade, and I’d hit the limit of what those AI app builders could do.

So I brought in a more professional process. I learned Git, moved the project into my own repo in VS Code, and reviewed and tweaked every change the model gave me before pushing it. The full story is in Learning to Build as a Designer.

  1. DEC 2024v0 + FigmaGenerating screens from my own designs, fixing a lot.
  2. ~V300Into VS CodeGenerated output degraded. Moved to my own repo and Git.
  3. THE HARD PARTThe data modelSessions, climbs and projects without conflicts.
  4. REVIEWApp Store reviewFour rejections, each fixed and resubmitted.
  5. APR 23, 2025Live on iOSAndroid followed. Still shipping updates.
The Share Your Session sheet in Sloper, next to three share cards in different color styles.
FIG. 5Sharing a session: the share sheet in the app, and three of the looks you can tap through.

06What happened

500+
climbers using it
1,300+
sessions recorded
10k+
climbs logged
400+
projects saved

Sloper mostly runs on its own now, with no marketing behind it. New climbers find it, and people log climbs every day.

What it gave me has carried into every project since. Usually there’s a handoff between designers and developers, and knowledge gets lost in it. Having been on both sides, I understand each role’s constraints, and it’s changed how I work at Wonderlic. I know how what I’m designing will actually get built, so I can answer a lot of the developers’ questions before they ask them. I’m not just designing the UI, I’m designing for the data.