BoulderBuddy — full-stack bouldering platform
A full-stack bouldering platform — Next.js admin + Prisma/PostgreSQL backend + Expo mobile app for climbers.
- Role
- Creator
- Year
- 2025
- Stack
- Next.js · TypeScript · PostgreSQL
- Status
- In progress
Where this lives
BoulderBuddy is a personal full-stack project shaped around how indoor bouldering actually works. Climbers go to a gym, find a wall, pick a sector, try boulders, log sends and likes. Gym staff curate that content — set new routes, retire old ones, tag grades. The split between climber-facing and gym-facing software in this space is usually bad on at least one side; BoulderBuddy is the attempt at building both from the same Prisma schema.
It's a school-and-side project mash-up: started as part of an applied development course, kept going because the architecture got interesting. There's no launch date — the value is in the platform shape, not a version number.
Consumer climbing apps tend to ignore the operator side: they assume gym content magically appears. Gym-admin tools tend to ignore the climber side: they're spreadsheets with a login. Neither understands that the same gym → wall → sector → boulder hierarchy lives on both ends, and that it has to stay in lockstep.
The Prisma model is the bridge. One schema, generated client used by both Next.js (admin) and the API layer the Expo app talks to. Add a boulder in the admin → mobile sees it on next pull. Change a grade → both surfaces update. The data model becomes the contract, not a translation layer.
Auth is the second contract: roles decide who edits what (admin / gym staff / climber). Demo data is the third: realistic seeded content with real images so the platform looks like a product when it boots, not a blank schema waiting for input.
One schema, two surfaces
BoulderBuddy is small on purpose. Four layers, each with one clean responsibility, all sharing the same Prisma model so the admin and the mobile client never drift.
Operator surface
Next.js App Router admin panel for managing gyms, walls, sectors, boulders, users and roles. Server actions handle mutations, the Prisma client owns persistence, Tailwind keeps the UI quiet and operator-shaped instead of consumer-flashy.
Shared data model
One PostgreSQL database, one Prisma schema. The model encodes the real climbing hierarchy — gym → wall → sector → boulder — plus accounts, route interactions, media, likes and comments. The generated Prisma client is the same on both ends, so types stay aligned.
Mobile climber surface
Expo + React Native client for the climber-facing flow. Browse gyms and walls, see boulders, interact with routes, react to other climbers' sends. Shares its data shape with the admin via the generated Prisma types — the API contract is one source of truth.
Who can see what
Role-based access threaded through both surfaces. Admins manage the whole content tree; gym staff scope to their own gym; climbers see public content and their own route history. The same auth identity works across web admin and mobile.
One platform, two interfaces
The admin surface on the left, the mobile climber app on the right — both rendering the same gyms, walls, sectors and boulders from the shared Prisma schema. Each loop preserves its native aspect ratio so neither surface is stretched.
Built today
The current shape of the platform — not a wishlist. Auth, the content model, route interactions, media and social are all in the demo dataset; mobile renders the same data the admin curates.
Auth + roles
Account model with role-gated access. Admin vs gym-staff vs climber permissions enforced at the API layer, not just hidden in the UI — both surfaces respect the same boundaries.
Climbing content model
Gyms, walls, sectors, boulders — modelled the way climbers actually talk about them. Grades, tags, photos and short descriptions per boulder; the hierarchy makes navigation in both UIs feel obvious.
Route interactions & media
Climbers record how they interact with each boulder — tried, projecting, sent — and can attach media. The model ties each interaction to a climber, boulder and date, enough to render a personal history and feed any future analytics.
Likes + comments
Lightweight social on the climbing content. Climbers can react to a boulder or another climber's note. Kept deliberately small — this is a tracker with a community layer, not a social network.
Demo dataset with real media
Seeded data with realistic climbing photos and a backend demo capture. Means the platform looks alive on first boot — both surfaces render production-shaped content rather than placeholder skeletons.
What this taught me
The schema is the product. Every time the admin and mobile started drifting it was because the data model was wrong somewhere. Fixing it once in Prisma fixed both surfaces — cheaper than parallel patches on either side.
Roles deserve real boundaries. Hiding admin-only controls in the UI feels safe until you remember the API is the actual boundary. Server-side role checks are the only ones that count; everything in the UI is just polite.
Demo data is part of the build. A working seed with realistic content turns 'is the platform working' into a question you can answer at a glance — for me, for visitors, for any future collaborator.
Mobile + web from one stack pays compounding interest. Sharing the Prisma client means a backend change ripples through both clients in one PR. The alternative (separate type generation per surface) would have cost real time.
BoulderBuddy is still in progress, but both surfaces now run on the same data: the admin loop on the left of the showcase, the mobile loop on the right, both reading from one Prisma schema and one auth identity.
The bet is that climbing software gets better when both sides share a model. Even as a school-and-side project, the platform shape teaches more than another single-purpose tracker would.