Rentslam

Status

active

Built with

Scraping pipeline, Matching engine, Notifications, Subscriptions, Mobile apps

Links

rentslam.com

The problem

Rental markets, especially in competitive cities, are fragmented across dozens of listing sites, agency portals, and classifieds - and the good listings disappear fast, sometimes within minutes of being posted. Someone looking for a place has two bad options: manually refresh a dozen tabs all day, or rely on a single platform’s own alerts and miss everything posted elsewhere. Neither works when the search is urgent, and it usually is.

Rentslam exists to close that gap: it scans a large number of rental sources continuously, matches new listings against what each user is actually looking for, and notifies them fast enough that the notification is still useful.

Who it’s for

Home seekers - people actively searching for a rental, usually under time pressure, often in a market where demand outstrips supply. The urgency varies (someone relocating for a job in three weeks behaves differently than someone casually browsing), but the underlying need is the same: don’t make me do the searching myself, and don’t make me wait.

My role

I’m CTO and co-founder. I’ve been building and operating Rentslam for around ten years, which means I’ve been on both sides of the same decisions - the one who designed the architecture and the one who got paged when it broke at 2am. That combination shapes a lot of how I think about tradeoffs now: elegant-on-paper designs that are painful to operate lose to boring designs you can still reason about half-asleep.

Constraints that shaped the system

A few constraints have been constant for most of the product’s life:

• Source sites don’t want to be scraped. Layouts change without notice, anti-bot measures evolve, and rate limits are a moving target. The scraping layer has to be resilient to constant, uncoordinated change on the other end.
• Freshness beats completeness. A user would rather get 90% of relevant listings ten seconds after they go live than 100% an hour later. Every architectural decision has had to be weighed against latency, not just correctness.

• Duplicates are everywhere. The same listing gets posted on multiple sites, reposted after edits, or relisted at a different price. Deduplication isn’t a nice-to-have; without it the product is unusable noise.
• Small team, real infrastructure. Operating scrapers, a matching engine, and notification delivery at meaningful scale with a lean team means every piece of complexity has to earn its place. We’ve had to say no to architecturally interesting ideas that weren’t worth the operational burden.

System architecture, at a high level

The system is organized as a pipeline, roughly:

1. Scraping pipeline - a set of source-specific collectors that continuously pull listing data from rental sites, normalized into a common internal format. Each source has its own quirks, rate limits, and failure modes, so this layer is built to isolate failures - one broken source shouldn’t degrade the rest of the pipeline.
2. Deduplication - incoming listings are checked against recently seen listings to identify the same physical unit posted multiple times or updated, so users don’t get spammed with near-identical notifications.
3. Enrichment - listings are augmented with additional structured data (location normalization, price parsing, feature extraction) so that matching can work against clean, comparable fields rather than raw scraped text.
4. Matching engine - user search profiles (location, price range, size, and other criteria) are matched against the enriched listing stream in near real time.
5. Notification delivery - matches are pushed out through the channels a user has configured, engineered for low latency since speed is a core part of the product’s value.
6. Subscriptions and mobile apps - the user-facing layer, including account and subscription management and native mobile apps, sits on top of this pipeline.

Mistakes and lessons

The biggest early mistake was under-investing in deduplication relative to how much it mattered. It looked like a backend hygiene problem when it was actually a trust problem - a user who gets the same listing three times stops trusting the alerts, full stop.

The second lesson was about failure isolation. Early versions of the scraping pipeline had more shared state between sources than they should have, so a bug or a block on one source could degrade unrelated ones. Rebuilding that layer to fail independently per source was tedious work that paid for itself many times over in reduced on-call burden.

The third, more general lesson: in a product whose core value depends on scraping data you don’t own, resilience to external change never becomes a finished engineering task. It’s an ongoing operational discipline, closer to running infrastructure than shipping features.

Current status

Rentslam is actively developed. Beyond keeping the core alert pipeline fast and reliable, current work is focused on expanding the services we offer around it.