I've owned local-hotel.com for 27 years. Twice over those decades I tried to turn it into a real business, and twice I stalled — not on the idea, but on the distance between “idea” and “a working, safe, competitive product.” For one person, that gap was always too wide.
The domain was never the problem. The team I didn't have was.
What changed in 2026 isn't the idea. It's that I could finally build the thing with Claude as the engineering team — architecture, code, debugging, security reviews — while I did the steering. A team in a box. The opportunity was always sitting on the domain; the missing piece was the people to build it, and now the people are a model.
First commit was 4 April. The apex went live, taking real bookings, on 21 June. Call it eleven weeks from empty repo to a live OTA. In that window: 2,321 commits — 186 in April, 1,185 in May, 883 in June. The shape of it is right there in the numbers: a slow start finding the architecture, a manic May, then a June grind of the unglamorous 80%.

More test code than app code. The line I keep coming back to: the app is about 118,000 lines, the tests about 173,000 — 12,338 of them passing. That ratio isn't vanity. It's the only way one person trusts a surface this large. I can't hold a booking engine, an FX layer, sixteen releases and a payment flow in my head at once, so I made the machine prove itself on every change instead. The tests are the trust.
Most of June went on the parts no user will ever notice. A security pass — rate-limiting, URL allowlisting, secrets hygiene. A full WCAG-AA accessibility sweep run against real browsers, which started at roughly 2,100 contrast failures and ended near zero. Payment flows, foreign-exchange handling, idempotent webhooks so a retried callback can't double-book or double-charge. None of it demos well. All of it is the difference between a prototype and something I'd hand my own card to.
I launched on a single supplier — LiteAPI, a meta-aggregator with about 2.6 million properties — rather than waiting months on direct hotel contracts I couldn't yet win. But every supplier-touching feature was built multi-supplier from day one, so Hotelbeds or direct deals slot in later without a rewrite. The model is deliberately boring: net rate plus a flat 8% markup. I can't outspend the giants; I can undercut the opaque fees they bury.
The honest constraint of a new domain is that Google won't let me rank for “hotels in London” for a long time. It might, though, let me rank for “hotels near the 2027 total solar eclipse,” or “where to stay for the Tour de France Grand Départ.” So I built an events section as a deliberate SEO wedge — around 1,800 gigs and matches auto-ingested from Ticketmaster, plus a curated set of time-boxed blockbusters: the eclipse, Rugby World Cup 2027, the Tour, even the Bayeux Tapestry's loan to the UK. High intent, low competition, expiry dates. Whether it actually works, I genuinely don't know yet.
On how the AI actually worked: it wasn't autocomplete. Claude proposed the architecture, caught its own bugs, ran multi-agent security reviews over the code, and — the part I didn't expect — talked me down more than once. It flagged a “critical” XSS, then, when I went to panic-fix it, walked me through why React 19's default escaping made it a non-issue. I was product and judgment; it was the team that could hold the whole codebase at once. It's not always right, and I overruled it plenty — but the division of labour was real.
Now the part launch posts lie about. Two weeks in: roughly 1,500 search impressions a month, average position around 54 — that's page five — a handful of clicks, and about eight users a week. Google has discovered around 11,600 pages and indexed only a few. That's not a bug; it's the new-domain trust gate, and there's no clever code that skips it. Realistically it's three to six months before any of this becomes meaningful organic traffic, and that's if the events bet pays off and the links come.
The server logs, though, tell a more encouraging story than the search console does. Here’s a recent 24 hours of Googlebot, aggregated:
| Signal | Count / 24h | Reading |
|---|---|---|
| /hotel/ requests | ≥1,600 | sustained ~10/min all day — saturating even 1.5-hour windows |
| /events/ requests | ≥1,600 | bursts over 25/min — the new surface being actively chewed |
| /landmarks/ requests | ≥183 (~225 est.) | globally spread — Asia, Europe, LatAm, Middle East |
| 308 redirects followed | ≥400 | URL-migration digestion; matches GSC’s “566 with redirect” |
| Sitemap fetches | 129 (exact) | all six sitemaps, re-pulled roughly every 90 minutes |
| robots.txt fetches | ≥145 | a crawl session every few minutes, multiple bots |
| 404s | 50 (exact) | a tidy-up list |
| 5xx | 19 (exact) | one of them user-facing |
The rhythm is bursty rather than steady — big pushes mid-morning and early afternoon UTC, near-silence overnight. That’s classic crawl-budget pacing for a young site, and the bursts should widen as trust builds. Which reframes the problem usefully: discovery isn’t the issue — Google is all over the site, re-reading the sitemaps every ninety minutes. The slow part is promotion from “crawled” to “indexed,” and that queue is the trust gate doing its job.
And one subtraction I can’t resist: at least 3,700 crawl-shaped page requests a day, against roughly 183 human pageviews a day — and that human figure is generous, since analytics is consent-gated. Call it what it is: my readership is currently ≥95% robot. Every launch curve starts somewhere.
So here's where it actually stands: 27 years of owning the right domain, eleven weeks of finally being able to build on it, and a live product that almost nobody has found yet. The interesting question isn't whether one person can build this any more — plainly, now, they can. It's whether one person plus an AI can get discovered in a market owned by giants who buy the top of every search result. I don't know. Ask me in six months. In the meantime, the site is live at local-hotel.com — go and poke at it.