When I launched carwashin.co.uk, I thought I was building a fairly straightforward local directory product.
The problem space was simple:
- help users find car wash businesses in the UK
- make browsing easier by city and location
- reduce the friction of searching generic maps and messy directories
That part worked.
But then a different type of user question started showing up:
“Can I quickly check whether this car wash phone number looks valid before I call it?”
That question turned into a second project: whocallme.co.uk.
This post is about why I built it, what data I used, what I deliberately didn’t try to do, and why I think there’s room for practical lookup utilities built on top of official public data.
The product idea came from a verification gap
Directories solve discovery.
But for a lot of local-service use cases, users also want verification.
Finding a listing is one thing. Deciding whether to trust the phone number attached to it is another.
The user intent is usually pretty practical:
- Is this a real-looking UK number?
- Is it a geographic landline, mobile, or non-geographic number?
- Does the area code make sense for the business?
- Is there any official numbering context behind it?
- Are there already community notes about this number?
That’s not the same as “tell me exactly who this person is.”
In many cases, users don’t need perfect identification. They just want enough signal to decide whether to call, ignore, or double-check elsewhere.
Why I didn’t want to build a generic spammy reverse-lookup site
There are already plenty of phone lookup sites that feel like they were built by generating huge numbers of low-value pages and hoping search engines sort it out.
I wanted a different approach.
The goals for whocallme.co.uk were:
- Use official/public-interest sources wherever possible
- Explain what can actually be inferred from a number
- Avoid pretending digits alone reveal private identity
- Keep lookup pages useful even before heavy community activity exists
- Prefer structured context over empty “who called me?” fluff
That led me to build around UK numbering structure first.
The core data source: Ofcom numbering data
That data is useful because it helps answer questions like:
- what type of number range this is
- whether the number sits in a geographic or non-geographic space
- which provider allocation is relevant at the range level
- how area code hints work for 01/02 numbers
- what kind of pricing/range guidance may apply
I also used official public guidance around scams, nuisance calls, and phone-number interpretation to make the non-number pages more useful, instead of relying only on raw lookup mechanics.
Cursor made the first version much faster to ship
I used Cursor heavily during the build.
Not in a “AI built everything for me” sense, but in the practical sense that matters to solo builders:
- parsing and normalising source data
- scaffolding lookup logic
- cleaning up edge cases in number formatting
- generating content structure for range/type/help pages
- accelerating iteration on small product decisions
The main productivity gain wasn’t just code generation.
It was the ability to move quickly between:
- data understanding
- schema design
- transformation logic
- lookup-page UX
- internal content structure
That made it much easier to go from “I think users want this” to “there is a working version online.”
What the site actually does
At a practical level, whocallme.co.uk is designed to let someone search a full UK number and get a more structured answer than they would from raw digits alone.
A lookup can surface things like:
- line type
- dialling-code location hint
- provider allocation label where relevant
- supporting range/cost guidance
- community reports, where available
There are also browseable sections for:
- area codes
- provider blocks
- number ranges / cost guides
This makes the site useful both as:
- a direct lookup tool, and
- a lightweight UK phone-number knowledge base.
One important product decision: don’t auto-claim private identity
This is probably the most important design constraint.
I didn’t want to build something that implies every UK phone number can be resolved to a private person’s name from public digits alone.
That’s a bad product promise and a bad trust signal.
So the site is intentionally framed around:
- what can be inferred from numbering structure
- what official/public information can support
- what community reports add
- where uncertainty remains
In other words:
useful context > fake certainty
I think that tradeoff makes the product more credible long term.
Why this pairs well with a local directory site
What surprised me is how naturally this phone lookup tool complements a vertical directory.
carwashin.co.uk helps users discover car wash businesses.
whocallme.co.uk helps users evaluate the phone numbers attached to those businesses — or any other UK number they encounter.
That pairing creates a simple but useful user flow:
- find a business
- inspect the phone number
- decide whether to call
- verify through an official or trusted channel if needed
I think this pattern can work beyond car washes too.
Any local-service or directory product eventually runs into the same issue:
discovery is not enough — users want confidence signals.
What I’d recommend if you build something similar
If you’re thinking about building in this space, my practical advice would be:
1. Start with the official structure layer
Use public numbering information first. It gives you a trustworthy baseline.
2. Don’t overpromise identity resolution
Most of the internet is too willing to imply certainty where there isn’t any.
3. Build the knowledge pages, not just the lookup box
Area code pages, provider pages, and number-type guides do a lot of work.
4. Treat community input as an enhancement layer
Community reports are valuable, but they shouldn’t be your only source of usefulness.
5. Keep the product honest
A smaller but clearer promise is better than a flashy but weak one.
Final thought
This project started with a very unglamorous user need:
“Can I check whether this business phone number looks right before I call?”
That was enough.
And honestly, a lot of the best small products start exactly there.
If you want to see the two projects:
Top comments (0)