Hotel Grande Bretagne in Athens has a 9.3/10 on Booking.com.

Here's what that score hides:

• Small rooms appear in 22% of reviews across all traveler types. Guests still give 10/10. The pattern is consistent: acknowledge the room, pivot immediately to the Acropolis view to justify the score.
• The rooftop restaurant closed without warning for months in 2024. Zero impact on the overall rating.
• Three specific staff members are named positively across reviews written in English, Turkish, and Polish. One department is carrying the entire experience.

Star ratings are broken. Not because they're gamed (though they often are), but because averaging thousands of opinions into one number destroys the signal.

So I built WrongStay — an AI platform that extracts what's actually in hotel reviews. Persona scores, buried complaints, staff patterns, temporal signals. Athens and Zurich live now, 39 hotels analyzed.

Here's exactly how I built it.

The Stack

• Replit — development and deployment (Reserved VM)
• Express + TypeScript — backend API
• React + Vite — frontend
• PostgreSQL via Neon — database
• Claude API (Sonnet 4) — AI synthesis
• Outscraper — Booking.com review collection
• Serper.dev — hotel cover photos
• Chart.js + react-chartjs-2 — radar charts
• Plausible — privacy-friendly analytics

Total infrastructure cost to run: under $50/month.

Getting the Data

The first problem: where do you get hotel reviews without building a scraper?

I chose Booking.com over TripAdvisor for one specific reason: verified guests only. You can't review a hotel on Booking.com unless you actually booked and stayed there. Less noise.

Booking.com also pre-labels reviewer type which feeds directly into persona scoring without any NLP.

And also: they split pros and cons into separate fields. The review_disliked_text field alone is where most of the real signal lives.

For data collection I used the Outscraper API:

const response = await axios.get(
  'https://api.outscraper.cloud/booking-reviews',
  {
    params: {
      query: hotelUrls, // up to 1000 in one request
      limit: 200,
      sort: 'f_recent_desc',
      language: 'en',
      region: 'GR',
      async: true
    },
    paramsSerializer: params =>
      qs.stringify(params, { arrayFormat: 'repeat' }),
    headers: { 'X-API-KEY': process.env.OUTSCRAPER_API_KEY }
  }
);

Key insight: Outscraper supports batching up to 1000 queries in one request. I submitted all 40 hotel URLs simultaneously, got one job ID, and polled for completion. Total cost for 40 hotels × 200 reviews: $16.

The Database Schema

Five tables: hotels, reviews, synthesis, persona_scores, translations.

The reviews table captures everything from Outscraper:

CREATE TABLE reviews (
  id SERIAL PRIMARY KEY,
  hotel_id INTEGER REFERENCES hotels(id),
  review_liked_text TEXT,
  review_disliked_text TEXT,
  review_score NUMERIC,
  author_type VARCHAR(100),
  author_country VARCHAR(100),
  review_date DATE,
  review_id VARCHAR(255)
);

The Synthesis Prompt

This is the core of the product. The prompt took multiple iterations to get right. The key insight: don't ask the AI to summarize. Ask it to find what standard review systems miss.

Here's the actual prompt used in production:

You are a hotel intelligence analyst. You extract 
signals from guest reviews that standard review 
platforms miss. You always respond with valid JSON 
only. No preamble, no explanation, no markdown.

Analyze these hotel reviews and return ONLY a JSON 
object with this exact structure:

{
  "traveler_mismatch": "Which specific traveler type 
    consistently loves this hotel and which consistently 
    doesn't — and the precise reason why. Be specific, 
    not generic.",

  "buried_complaint": "The complaint that appears in 
    15-40% of disliked fields but that positive 
    reviewers always rationalize or excuse. Name the 
    exact pattern, not just the complaint.",

  "star_agreement": "One specific thing that both 
    low-scoring AND high-scoring reviewers mention, 
    despite disagreeing on everything else.",

  "temporal_signal": "Do reviews from the last 6 
    months differ meaningfully from older ones? What 
    specifically changed and approximately when? If 
    no meaningful change, say so.",

  "marketing_gap": "Something the hotel implies or 
    that positive reviewers praise, that negative 
    reviewers experienced very differently.",

  "staff_pattern": "Any specific staff role, 
    department, or named individual mentioned 
    repeatedly — positively or negatively.",

  "verdict_book_if": "Complete this: Book this hotel 
    if you are [specific traveler type and reason]. 
    Max 20 words.",

  "verdict_avoid_if": "Complete this: Avoid this 
    hotel if you are [specific traveler type and 
    reason]. Max 20 words.",

  "persona_scores": [
    {
      "persona": "Couples",
      "score": "A|B|C|D|F",
      "reasoning": "One specific sentence based on 
        actual review patterns.",
      "review_count": N
    }
    // Couples, Families, Solo Travelers, 
    // Business, Foodies, Active/Outdoors
  ]
}

If a persona has fewer than 5 reviews, set score 
to null and reasoning to 'Insufficient data'.

Reviews:
[INSERT_REVIEWS_JSON_HERE]

The instructions that made the biggest difference:

1. "Not just the complaint — the exact pattern" forces specificity instead of generalities
2. "15-40% of disliked fields" gives the AI a statistical frame rather than anecdotal
3. "Positive reviewers always rationalize" is the mechanism that makes the buried complaint actually useful
4. Letter grades (A/B/C/D/F) instead of numbers — they communicate judgment, not false precision

What the AI Actually Found

Here's a real example from Athens Was Hotel (10/10 on Booking.com):

Buried complaint: "The split-mattress double bed complaint appears in roughly 20-25% of couple reviews with lower scores, where one mattress sits higher than the other making shared sleeping uncomfortable. Positive reviewers either don't mention it or describe the bed as 'very comfortable' — suggesting room assignment variance. Negative reviewers name it explicitly as a physical discomfort issue, while positive reviewers who got proper beds praise comfort without knowing the problem exists for others."

Staff pattern: "Anna (breakfast service) is the most frequently and specifically named individual, praised by name across multiple reviews in multiple languages (English, Turkish, Polish) for warmth, language skills, and making the à la carte breakfast easy to navigate. Themis (front desk) and Katerina (restaurant) are also named positively in multiple reviews."

Neither of these appear in the star rating. Both are immediately useful to someone deciding whether to book.

Translation Pipeline

After synthesis I translate all 8 text fields into German, French, Spanish, and Italian — one Claude API call returning all four languages simultaneously:

const prompt = `
Translate all fields below into German (de), 
French (fr), Spanish (es), and Italian (it).

Preserve the specific, analytical tone. Do not 
soften or generalize. Keep named people and 
places in their original form.

Return ONLY this JSON structure, nothing else:
{
  "de": { "traveler_mismatch": "...", ... },
  "fr": { ... },
  "es": { ... },
  "it": { ... }
}

English source:
${JSON.stringify(englishFields)}
`;

Four languages in one API call. Stored in a translations table, fetched via ?lang=de param on the frontend.

pSEO Architecture

40 hotels generates a large URL surface:

/athens                               → city page
/athens/hotel-grande-bretagne         → hotel page
/athens/hotel-grande-bretagne/couples → persona page
/athens/best-hotels-for-couples       → aggregate page

The sitemap is fully DB-driven — new hotels appear automatically within 1 hour (cache TTL) of having synthesis run. No manual sitemap edits ever.

The critical SEO problem with React SPAs: every URL returns the same index.html to Googlebot, which means every hotel page has identical meta tags.

Fix: bot detection middleware that returns server-rendered HTML with correct meta tags for crawlers, while regular users still get the React SPA:

const BOT_AGENTS = [
  'googlebot', 'bingbot', 'twitterbot',
  'linkedinbot', 'facebookexternalhit'
];

function isBot(req) {
  const ua = (req.headers['user-agent'] || '')
    .toLowerCase();
  return BOT_AGENTS.some(bot => ua.includes(bot));
}

if (isBot(req)) {
  const hotel = await getHotelWithSynthesis(city, slug);
  return res.send(renderBotHTML(hotel));
}
res.sendFile(REACT_INDEX);

Each bot response includes correct title, meta description, Hotel schema, and FAQ schema as JSON-LD. Unknown slugs return HTTP 404 with noindex.

The Design

I wanted editorial authority, not another AI dashboard.

Key decisions:

• Playfair Display serif for headings — signals trusted publication, not tech startup
• Amber accent (#BA7517) — warmer than the typical blue/green SaaS palette
• Two dark inverted sections: verdict cards and buried complaint spotlight — creates visual hierarchy and makes the intelligence feel premium
• Radar chart for persona scores — the polygon shape communicates the hotel's personality at a glance before you read anything
• Bento grid for insights — varied card sizes encode importance without explicit ranking

The Admin Pipeline

A single admin page runs the full pipeline:

Import → Synthesize → Translate → Photo fetch

With the Outscraper API integration, the full pipeline for 40 hotels runs unattended. Server-Sent Events stream progress to the admin UI so I can watch it without the HTTP connection timing out. When done, cache is automatically invalidated.

Distribution Strategy

Building was the easy part. Distribution is where most projects die.

The approach that worked: lead with the insight, not the product.

The LinkedIn post that drove the first wave of traffic started with the buried complaint finding — not "I built a thing." Nobody clicks "I built a thing." People click specific, surprising data.

The long game is pSEO. "Is [Hotel Name] good for couples?" has real search volume and almost no competition for AI-synthesized answers. That's 240 pages from 40 hotels, each targeting a specific high-intent query.

What I'd Do Differently

Start with the prompt. The synthesis prompt is the product. Everything else is infrastructure. Test the AI output quality on day one before building anything else.

Test the data source immediately. I built the full pipeline before verifying the API worked. Backwards. One test call on day one would have saved hours.

Build pSEO from the first commit. Adding the prerender middleware after launch is harder than including it from the start.

Live

wrongstay.com — 39 hotels, Athens and Zurich, free to use.

The full synthesis prompt is above — adapt it, use it, let me know what patterns you find in your own data.

What cities should I add next?