Skip to main content

Wishlist

Things we want but have not committed to. Nothing here is scheduled; nothing here has been decided. The point of writing them down is that an idea nobody has recorded gets designed out of the architecture by accident, and then costs ten times as much to add later.

This page is the pool. When an item here becomes real work it is promoted into a band on the backlog, which is also the moment it gets a phase on the roadmap and — if it carries a technical commitment — an ADR. Several items that used to live on this page have made exactly that trip: multi-pitch and alpine routes, route lines on the live camera, 3D sector renders, drawing a route in the app, and trip-planning wishlists are now roadmap phases 2, 10, 11, 6 and 3 respectively.

Each entry says what it is, why it is interesting, and what it needs from the architecture today so we do not paint ourselves into a corner.

:::note This page is not in priority order, on purpose

It is a capture surface. Ranking a list of things nobody has committed to mostly produces an argument about the ranking, and a rank recorded here would be mistaken for a decision — which is exactly what this page is not for.

Ordering lives on the backlog, and an item acquires a position by being promoted onto it. If this page ever grows past the point where it can be read in one sitting, the answer is a pass that promotes the obvious ones and deletes the ones nobody believes in any more — not a column of numbers here. :::

Bolt condition and inspection history​

A first-class record of the fixed gear on a route: when it was placed, what it is made of, when somebody last looked at it, and what they thought.

Why: it is the one piece of information a printed guidebook structurally cannot carry, because it changes after printing. Bolts fail. Sea-cliff and limestone hardware corrodes on a timescale much shorter than a guidebook edition, and "the second bolt is spinning" currently travels by word of mouth and forum post.

What it needs from us today: nothing structural, but it should be modelled as its own record from the start rather than as prose appended to gear_notes. A report needs a reporter, a date, and a severity, because the display rule is "how old is this information" as much as "what does it say".

What is genuinely hard: liability. Publishing "this bolt is fine" is a claim, and the framing has to be that we report what climbers observed, dated, not that we certify anything.

The conditions answer​

Not a forecast widget — an answer. "Will Stanage be dry and in the sun at 2pm on Saturday?"

Why: rock type, aspect and recent rainfall determine whether a day out is worth having, and all three are things we either store or can fetch. Aspect plus sun position is trigonometry; seepage by rock type is a lookup; recent rainfall is an API call. Nobody has assembled the three into a sentence.

What it needs from us today: Crag.aspect and Crag.rockType are stored, and sector-level aspect too, because half a crag can be in the sun while the other half is not.

What is genuinely hard: being wrong confidently. This is principle 3 territory — an answer of "probably dry" that sends someone on a two-hour drive is worse than no answer.

Access alerts you did not ask for​

A push notification when the access status changes at a crag you have pinned, downloaded, or have routes wishlisted at. Nesting restrictions, ownership changes, temporary bans.

Why: access information is only useful if it reaches you before you set off. A dated banner in the app is a passive channel; a bird ban that starts on 1 March needs to be pushed, not waited for. This is also the strongest argument to a landowner or the BMC that the app is worth cooperating with.

What it needs from us today: access_status and its date are already on the crag record. The notification path itself needs identity, so it is downstream of that decision.

Sharing a crag with the person next to you​

Your mate arrives at the layby with the app installed and no signal and no crag. You hand it to them over AirDrop or a local connection.

Why: it is the offline-first principle taken to its logical end. The moment somebody needs a crag most is the moment they cannot download one.

What it needs from us today: nothing, but it argues for a crag download being a self-describing bundle rather than a set of rows scattered across the local database. Worth knowing before phase 4 fixes the download format.

A web tool for contributors​

Not a consumer web app — a contributor one. Tracing sixty route lines onto a set of photos is tolerable on a phone and pleasant with a mouse and a large screen.

Why: the people who will document a whole crag properly are the people who will sit down for an evening and do it. Asking them to do it on a 6-inch screen loses most of them.

What it needs from us today: nothing, provided the contribution API is a real API rather than something entangled with the mobile app's assumptions. The same argument applies to the moderation queue, which is already expected to be a small web app.

Crag ethics, etiquette and who else is there​

The things a local knows that no guidebook writes down: whether that boulder is brushed or scrubbed, whether topping out is fine or the farmer minds, whether the parking is a bus stop at weekends, whether it is a good crag with kids or a bad one with a dog.

Why: the difference between an app that a local trusts and one they roll their eyes at is almost entirely this. It is also the sort of content contributors are best placed to write and publishers never do.

What it needs from us today: nothing. It is text on a crag, and it fits the contribution model exactly.

Route history and first ascent stories​

Who put it up, when, in what style, and what happened. The thing books do well and apps do badly.

Why: it is the difference between a database and a guidebook. People climb Right Unconquerable partly because of the photograph of Brown in 1949, and an app that reduces it to "HVS 5a ★★★" has lost something a book had.

What it needs from us today: a first-ascent field already exists on routes. The wider case — photographs, an account, links to a piece of writing — argues for rich content on a route rather than a single line of text.

Partner finding​

"Who else is going to the Peak this weekend and climbs E1?"

Why: the actual limiting factor on most people's climbing is not fitness, it is a belayer.

What it needs from us today: nothing. Deliberately parked — it is a different product with different safety and moderation obligations, and bolting it onto a guidebook is how guidebooks become social networks. The feed makes it adjacent, which is a reason to be more careful about it rather than less.

Guidebook licensing and publisher content​

Paid, licensed guidebook content sitting alongside the free community data.

Why: it is one way the coverage problem gets solved quickly, and it is the model the incumbents already understand.

What it needs from us today: nothing structural, but note the deliberate absence of a "guidebook" entity in the data model. If licensing happens, attribution attaches to crags and routes rather than reorganising the hierarchy. It also interacts directly with the revenue model decision — a two-tier catalogue of paid publisher content and free community content has a quality-perception problem that a single pool does not.

Apple platform extras​

Small things that would make the app feel like it belongs on the phone:

  • Live Activity on the lock screen while a session is in progress
  • Widgets — the next wishlist route at the crag you are heading to
  • Apple Watch — log a tick from the belay without taking the phone out
  • Shortcuts / Siri — "log Flying Buttress"
  • Handoff between phone and iPad for planning
  • App Intents so a tick, a crag and a route are things the system can search and act on

What it needs from us today: nothing, except that logging is a small, well-defined write path rather than something entangled in a screen. Keep it that way.

Training towards an objective​

Not a training app. A route, and the honest answer to "what stands between me and it".

You set a goal — I want to climb harder, I want to get on a multi-pitch, I want to climb Cenotaph Corner — and the app works backwards from what that objective actually demands to what you actually do, and tells you the difference.

Why: a generic training app knows you want to climb 7a. We know you want to climb that 7a — that it is thirty metres of sustained limestone with a crimpy crux two-thirds of the way up, on a rock type you have never touched, at a crag that is only in condition in September. The route is the training plan's input, and we are the only ones holding it. Nobody else can build this from where they are standing.

The consequence is that the answer is often not "get stronger":

  • Someone climbing E2 at Stanage who wants a multi-pitch route does not need finger strength. They need rope systems, belay management, abseil practice, and a partner. That is a curriculum, not a training plan, and almost nobody teaches it.
  • Someone whose logbook is entirely gritstone wants mileage on limestone before their trip, not a hangboard.
  • Someone who has "done E2" ten times, always seconding, has a different gap from someone who led one. Ascent.style is first-class from day one and this is one of the reasons.

The version that fits this app, if it ever gets built: the plan is a ticklist. "Here are six routes within an hour of you that build towards it" — same rock type, same style, half a grade below, similar length — generated by a query over data we already hold, dropped into the wishlist, and picked up by trip planning in the Plan tab. The version that does not fit is prescribing a hangboard protocol; that is a different company.

What it needs from us today: nothing new, which is the point. It consumes ascent history, route type, gradeBand, length, rock type and aspect. But it is a strong argument for capturing route length and the phase 1 tags properly rather than approximately — a plan that cannot tell an eight-metre boulder problem from a forty-metre pitch is worthless, and "crimpy" versus "juggy" is exactly the axis a gap analysis runs along.

What is genuinely hard:

  • It is advice about a physical activity, which carries a duty of care. This is principle 3 at its sharpest: state the gap, never issue a verdict. "You have never climbed above fifteen metres on grit, and this is forty metres of sustained limestone" is honest. "You are ready for E5" is a sentence that must never be generated.
  • Injury. Prescribed volume hurts people, and finger injuries are the sport's most common. Any plan that pushes load is pushing the highest-injury-rate activity in climbing at somebody who does not know their own limits.
  • It has a different centre of gravity. The guidebook is read at the crag, offline, in short bursts. A training plan is engaged with at home, weekly. That is a different product rhythm and it would pull at this one.

Somewhere other than the UK​

Grade systems, language, and the assumption that "access" means what it means in England.

Why: a UK climber's first sport trip is to Spain or France, and an app that stops working at Dover is an app they close in March.

What it needs from us today: already handled, mostly — grades are stored in the system they were published in and never converted, which is the hard part. See grading systems. What is not handled is that access status is modelled on UK categories, and that nothing in the app is translated.