FlatScout: real-estate market watcher

The problem

In a hot rental and property market, good listings survive for hours, sometimes minutes. Marketplace notification features are slow, coarse, and miss half the criteria that matter (price per square meter, specific districts, floor, owner vs agency). Whoever refreshes the site most obsessively wins, which is a job for a machine, not a human.

What we built

An always-on market watcher: a scraping pipeline that polls the marketplace on a randomized interval, normalizes and deduplicates listings, applies a scoring filter tuned to the buyer’s actual criteria, and delivers survivors straight to Telegram with photos, key numbers and one-tap triage buttons. A companion web UI shows the full triage board: new, shortlisted, rejected, visited.

• Polite by design. Randomized 3-10 second request delays, sensible poll intervals, and caching keep the scraper a good citizen rather than a load problem.
• Dedup that survives reposts. Listings get content-based fingerprints, so the same flat reposted under a new ID does not ping twice.
• LLM-assisted triage. Ambiguous listings (is this really owner-direct? is “cozy” code for 12 m²?) get a cheap LLM pass through our gateway before scoring.
• Human-in-the-loop. The bot takes decisions back: shortlist, reject, note. Those decisions feed the scoring, so the filter sharpens with use.

Architecture

Seven containers under one compose file: API, scraper worker, scheduler, Telegram bot, PostgreSQL, Redis, and a React triage UI, all behind a reverse proxy with the UI protected by 2FA. Ships and updates with a git pull and a compose command.

Outcome

The listing-to-notification delay dropped to minutes, and viewing appointments started landing before listings hit their first hundred views. The pattern (poll, normalize, score, notify, learn from feedback) has since been quoted for price monitoring and tender-watching use cases; it transfers to any marketplace where speed wins.