Studies
Anchorpoint
A dive-trip marketplace taken all the way through search, filters, reviews and a full price breakdown.
The brief
A study. Anchorpoint is not a real company. It was built to answer a specific question: how far can a marketplace be taken before it needs a backend?
Marketplaces are the hardest common brief, because the interesting problems only appear at depth. Anyone can lay out a grid of listings. The difficulty is search that narrows without dead-ending, a price the customer trusts, and the moment of booking — where most demo builds stop and real products begin.
The constraints
- No server. Everything runs in the browser, so state, routing and persistence all had to be solved client-side.
- It has to survive being used, not just looked at. Filters that return nothing, a booking taken to completion, a saved list that is still there tomorrow.
- Fifteen listings had to feel like a catalogue, which means varied prices, real-sounding operators and reviews that don't read as filler.
The decisions
The price is shown in full, before the booking step
A nightly rate is not a price. The breakdown shows the rate, the ten-percent service fee and five-percent tax as separate lines with the total underneath, on the listing rather than at checkout.
Marketplaces routinely hide this until the last screen because the total converts worse. It also produces the abandonment they then spend money fixing.
What it costs: the headline number looks higher than a competitor's. The customer arrives at checkout unsurprised.
An empty result is a route forward, not a dead end
Over-filtering is the normal outcome of a good filter set. Anchorpoint answers it with a stated reason, the filters that caused it, and a single control to clear them — rather than an empty grid and a shrug.
What it costs: an entire state to design and maintain that most of the flow never reaches.
Trust signals that a real marketplace would have to earn
Verified-operator marks, top-rated badges, review distribution bars, scarcity notes and trip status chips. Each is the kind of signal that decides a booking — and each is clearly part of a study rather than a claim about a real operator.
What it costs: in a real product every one of these needs a verification process behind it. Designing them made obvious how much of a marketplace is operations rather than interface.
A sign-in with no password
The demo sign-in takes a name and an email, keeps them in the browser, and uses them to personalise the booking confirmation. It never asks for a password, because a demo that collects credentials is teaching visitors a bad habit.
What it costs: it cannot demonstrate a real account system — the honest limit of a study with no backend.
Built with
- Vanilla JS
- Hash router
- localStorage
- Inline SVG
- Cloudflare Pages
The static markup under the app is real content, not an empty shell, so the page has a heading and a description before any JavaScript runs — for crawlers and for anyone whose script never loads.
