Projects
Bumpy
Crowd-sourced road surface quality mapping for cyclists.
Bumpy is a crowd-sourced road surface quality map for cyclists. The core idea is simple: if enough riders record accelerometer and GPS data while they ride, you should be able to build a useful picture of which roads feel smooth, which feel rough, and which are miserable enough to avoid entirely.
The original motivation was personal. Planning routes around North Yorkshire is easy enough on paper, but remembering which roads are actually pleasant to ride is much harder. Some roads look perfect on a map and feel awful in reality.
Bumpy started as a way to capture that missing layer and make route planning more honest.
The longer-term fantasy was bigger. Surface quality could sit alongside traffic as a meaningful input into route planning, and perhaps become part of a larger cycling product. But the first step was narrower: not building a whole planner, just proving that road quality could be measured well enough to be useful.
Interview
What is Bumpy in one blunt sentence?
Bumpy is a crowd-sourced road surface quality map for cyclists, built from accelerometer and GPS data.
What problem made you start thinking about it?
Planning routes around North Yorkshire is relatively straightforward, but I found it impossible to remember which roads were actually good to ride and which were horrible. You can map distance, elevation, and traffic, but surface quality is still mostly trapped in memory and local knowledge. That felt like a solvable problem.
Who was it really for?
Primarily cyclists like me. There is a possible council or infrastructure angle later on, but the first user was always the rider trying to have a better day out on the bike.
What was the original product fantasy?
At the practical end, better route planning. At the more ambitious end, surface quality plus traffic becoming part of a richer planning layer, maybe even something a bigger route planning app would want to acquire rather than build itself.
But the realistic starting point was much simpler: treat it as supplementary information cyclists could use, without trying to solve route planning in full.
What have you actually proved so far?
The main thing I proved was that I can extract a surface-quality signal that broadly lines up with subjective feel. A small-scale proof of concept using notebook tooling and simple map visualisation was enough to show that there is something real there.
What remains less clear is whether the same signal can be proxied while driving, and how invariant the metric can be made across different speeds and conditions.
What turned out to be hard?
Time, mainly. There are a lot of moving parts, but the hardest one is probably tuning the metric itself rather than the architecture. It is one thing to build a pipeline; it is another to be confident that the score actually means what you think it means.
Was the technical path clear?
Broadly, yes. The rough shape was always some form of sensor and GPS collection, map matching, aggregation by road segment, and then a website to display the results. We also proved enough in early notebook-based work to know that visualising the output was possible.
The harder part was getting from interesting prototype to something repeatable, scalable, and worth maintaining.
Why did it stall?
The usual answer: day job, limited time, too many moving parts. It never died because the idea stopped making sense. It just stopped because there was not enough room to keep pushing it forward.
What would success actually look like?
Two things. First, an app that records accelerometer and GPS data, ideally doing some processing on the device before upload. Second, a website that turns that into something cyclists can actually inspect and use.
The real commercial challenge would be the community side: data collection is likely battery intensive, so you need enough riders willing to contribute. Perhaps the exchange is free access to the high-fidelity map.
What I Learned
Bumpy reinforced a useful product truth: sometimes the hard bit is not whether the idea is good, but whether the signal is stable enough to trust. This road feels terrible is easy to say. Turning that into a defensible, repeatable metric is much harder.
It also exposed a pattern I keep running into with this kind of work. The product story is easy to explain in one sentence, but the implementation is not lightweight at all. A rider sees a coloured line on a map. Underneath that sits collection, matching, aggregation, normalisation, and enough real-world noise to make the whole thing awkward.
The project is stalled rather than finished. The underlying need still feels real. The open question is not whether cyclists would care. It is whether I can get the signal, the collection model, and the effort required into a shape that is worth carrying through.
Project Facts
- Status: Stalled
- Type: Project
- Audience: Cyclists first, with possible council or infrastructure value later
- Core input: Accelerometer and GPS data
- Proven so far: Surface-quality scoring can broadly align with subjective feel
- Open questions: Speed invariance, driving as proxy collection, contributor model, battery cost
- Likely shape: Mobile data collection plus a web map for inspection and planning