Bouldering Beta

Problem

Climbing shoes are sold across a lot of retailers at prices that move constantly, and finding the cheapest pair of a specific model means opening a dozen tabs. The information exists; it is just scattered, and it is stale the moment you write it down.

Approach

The hard part was not scraping — it was agreement. Five retailers list the same shoe under different names, split across gender variants, in different size systems. Ellis Brigham's "Vapour V — Men" and BananaFingers' "Vapour V — Unisex" are the same product to a buyer and different rows to a database. Getting to one canonical shoe with five prices attached meant matching listings across sources rather than trusting any of them.

From there:

• Price history. Prices are stored as a time series rather than overwritten, so each product carries a chart of every vendor's price over the last 60-120 days. Seeing that a shoe just dropped £15 is more useful than seeing what it costs.
• Faceted search. Filters on price range, brand, vendor, style, skill level, gender and size, with sortable columns and pagination over the result set.
• Fuzzy search. Typing "kronos" finds the Evolv Kronos. This meant reading properly about string matching and ranking rather than reaching for LIKE '%' and hoping.
• Size availability. Sizes are collected per listing and normalised across EU and UK systems, so the filters only offer sizes that someone actually has in stock.

React, Vite and Tailwind on the front, an Express API in the middle, PostgreSQL underneath.

The infrastructure

Which is what I actually got out of the project:

• Docker for the whole stack, so the thing that ran locally was the thing that ran in production
• GitHub Actions deploying automatically on push, driving an up.sh script on the server — my first proper continuous deployment rather than copying files
• A VPS I provisioned and hardened myself, rather than a platform that hides the server from you
• A real domain bought through Cloudflare, with DNS I had to understand rather than click through
• HTTPS via Caddy, which handles certificate issue and renewal

That list is why this project matters more than the site did. Working through it meant owning every layer between a git push and a stranger loading a page over TLS.

Getting it in front of people

A comparison site nobody has heard of has a marketing problem before it has a technical one, so I treated that as part of the build rather than something to worry about later.

I designed the identity — the climbing shoe mark, the orange and charcoal palette — and had posters and business cards printed, both carrying a QR code straight to boulderingbeta.co.uk. Physical collateral for a website sounds like a category error until you remember where climbers actually are: standing at a wall, about to notice their shoes are worn through.

Outcome

Live at boulderingbeta.co.uk.

It has not run continuously. I took it down once, and the reason is worth stating plainly: the only route to revenue was affiliate marketing, and the affiliate programmes for the brands worth comparing would not accept a site without traffic numbers I did not have. Running costs were real and accumulating, and continuing purely on optimism would have been sentiment rather than judgement.

It is back up because the thing works and I would rather it existed than not — which is a different decision from expecting it to pay for itself, and I am clear about which one I am making.

The infrastructure work carried straight into my day job either way. The Docker, deployment and TLS habits here are the same ones now keeping an archive online.