DEV Community: Caspar Bannink

What I Learned Normalizing Dublin Rental Listings from Messy Public Sources

Caspar Bannink — Tue, 02 Jun 2026 01:55:59 +0000

I started HomeScout because Dublin renting is painful in a very specific way: the market is fragmented, fast-moving, and full of near-duplicates. At first I thought the hard part would be the AI layer. It was not.

The hard part was turning messy rental listings into a dataset that was stable enough for software to reason over.

An "AI rental search" product sounds like a natural-language interface problem. In practice, the useful version is mostly data engineering: normalize listing fields, detect duplicates, infer locations, spot stale records, preserve provenance, and only then let an AI system rank or explain anything.

This is what I learned building the listing pipeline behind HomeScout.

A rental listing is not a clean object

The naive schema is simple:

title
address
price
beds
baths
description
source_url
photos

That works for a demo. It breaks as soon as you combine sources.

One source may expose the postal district as a clean field. Another may bury it in the title. One listing says "Dublin 8"; another says "Kilmainham"; another says "near Heuston"; all three may refer to the same practical search area. Some listings include BER ratings, some do not. Some include available dates. Some have "contact agent" instead of a direct email. Some silently change price without changing URL.

The first lesson: a listing is not one object. It is a current observation of a property-like thing from a source.

That distinction matters. I ended up treating each source listing as an observation, then linking observations to a normalized listing candidate.

source_observation
  source
  source_listing_id
  source_url
  raw_title
  raw_address
  raw_price
  raw_description
  first_seen_at
  last_seen_at
  raw_payload_hash

normalized_listing
  canonical_title
  normalized_price_eur
  beds
  baths
  inferred_area
  inferred_postal_district
  geo_confidence
  dedupe_group_id
  availability_state

That extra layer sounds boring, but it prevents a lot of downstream mistakes.

Deduplication is fuzzy, not exact

Duplicate rental listings rarely match perfectly.

The same apartment can appear with:

slightly different titles
reordered address fragments
different photo counts
one source saying "2 bedroom apartment" and another saying "2 bed flat"
a price changed by 50 euro
a letting agent reposting after a stale listing expires

Exact URL matching is not enough. Exact address matching is not enough either, because addresses are often incomplete or phrased inconsistently.

The dedupe approach that worked best was a scored match across multiple weak signals:

same_or_similar_address       +35
same_postal_district          +10
same_bed_count                +15
price_within_small_delta      +15
title_similarity_high         +10
shared_photo_fingerprint      +30
same_agent_or_agency          +10
seen_within_recent_window     +10

The important part is that no single signal is trusted absolutely. Address is strong, but not always present. Photos are strong, but not always stable. Price is useful, but listings change price. Agent identity helps, but large agencies list many similar apartments.

I also keep the dedupe decision explainable. If two observations are grouped, the system stores the reason and score. That makes it possible to undo bad merges later.

Bad dedupe is worse than no dedupe. If you merge two different apartments, every ranking, alert, and user note attached to that listing becomes suspect.

Stale listings need a state machine

Rental listings disappear quickly. Some are removed. Some are reposted. Some become stale without ever being explicitly marked unavailable.

The first version of my pipeline treated "not found in latest scrape" as unavailable. That was too aggressive. Sources can fail, pages can be incomplete, and rate limits can produce partial results.

The better model is a small state machine:

active -> missing_once -> missing_repeatedly -> stale -> archived
active -> price_changed
active -> content_changed
stale -> active_reposted

That gives the system tolerance for noisy crawls. A listing does not vanish because one run missed it. It only becomes stale after repeated evidence.

This also matters for alerts. A reposted stale listing is not the same as a new listing, but for a renter it might still be relevant. A price drop is not a new listing either, but it can be more important than a new listing.

So the event stream needs more nuance than "new property found."

Address ambiguity is the hardest product problem

Dublin addresses are messy from a search perspective.

Users think in areas, commutes, postal districts, landmarks, and transport lines. Listings use a mix of all of those.

Examples:

"Dublin 6"
"Rathmines"
"near Ranelagh Luas"
"city centre"
"Docklands"
"Grand Canal"
"Dublin 2"

These overlap but are not interchangeable.

I split location handling into three layers:

Raw location text from the source.
Inferred structured labels: area, postal district, locality.
Geographic confidence: exact, approximate, area-level, unknown.

The confidence field is important. If a listing only says "Dublin city centre", the system should not pretend it has precise coordinates. It can still be useful, but the UI and ranking need to know the location is approximate.

This also affects natural-language search. If a user says "near the DART", that should not be solved by an LLM inventing areas. It should resolve through a deterministic lookup table of stations, corridors, and distance bands.

LLMs are useful for translating messy user intent into structured constraints. They are not a good source of geographic truth.

Price normalization is not just parsing euros

Most listings are monthly rent, but the raw text still needs care.

Common problems:

commas and periods in different places
"per month" omitted
bills included or excluded
sharing listings mixed with whole-property listings
parking or utility fees mentioned in description
price changes on the same URL

For HomeScout, I normalize rent to monthly EUR and store the raw price string separately. If a price changes, that is an event, not just a field update.

I also avoid over-normalizing things I cannot prove. If a description says "bills included", that becomes a flag with source evidence. If it only implies bills might be included, it stays unknown.

This is where a lot of AI products quietly go wrong: they convert uncertainty into false certainty because clean fields are easier to rank.

Provenance matters more than it sounds

Every normalized field should know where it came from.

For example:

beds = 2
source = parsed_title
confidence = high

area = Rathmines
source = address_text
confidence = medium

pet_friendly = unknown
source = no_positive_evidence
confidence = low

That makes the AI explanation layer much safer.

Instead of saying:

This listing is pet friendly.

it can say:

I did not find a pet policy in the listing text.

That difference matters because users act on these explanations. If the system cannot distinguish "false" from "unknown", it will mislead people.

The AI layer should be downstream

The architecture that has worked best is:

collect observations
normalize fields
dedupe candidates
infer location with confidence
track listing state
build user-specific hard filters
rank candidates
use AI to explain, draft, and summarize

The LLM is not the database. It is not the source of truth. It sits after the deterministic pipeline.

For example, if a renter says:

"2 bed near the Luas under 2200, ideally not too far from Grand Canal"

the system should parse that into:

{
  "beds_min": 2,
  "max_price_eur": 2200,
  "transport": ["luas"],
  "soft_area_preference": ["Grand Canal"]
}

Then normal database queries and geographic lookups do the heavy lifting. The AI can help explain why a listing matched, draft an inquiry email, or summarize tradeoffs, but it should not hallucinate inventory.

What I would do earlier next time

If I were starting again, I would invest earlier in three things.

First, raw observation storage. Keep the raw payloads or at least stable hashes and extracted raw fields. You will need them when a normalized decision looks wrong.

Second, confidence scores. Not ML confidence in the fancy sense, just explicit quality labels for inferred fields. Exact address is not the same as inferred area. Unknown is not false.

Third, event history. Renters care about changes: new listing, price drop, repost, stale, reactivated. A snapshot table alone loses that.

The main lesson is that AI is only useful if the underlying data model is honest about uncertainty.

For rental search, the hard technical problem is not making a chatbot that talks about apartments. It is building a data pipeline that knows what it knows, knows what it guessed, and does not blur the two.

That is the part I underestimated.

I am building HomeScout for Dublin renters: https://homescout.io

Claude Opus 4.8 Is Not Just a Benchmark Bump

Caspar Bannink — Tue, 02 Jun 2026 00:59:13 +0000

Claude Opus 4.8 matters for a more practical reason than "new flagship model shipped."

Anthropic launched it on May 28, 2026 as an Opus upgrade aimed directly at coding, AI agents, and long-running professional work. On the official product page, Anthropic describes it as a hybrid reasoning model for coding and AI agents with a 1M context window, and says it has the consistency and autonomy to keep working on long-running tasks.

That framing is more important than the usual leaderboard chatter, because coding agents rarely fail in dramatic ways. They fail by losing the thread, using tools badly, stopping early, or quietly making the wrong edit and moving on.

If Anthropic's positioning is right, Opus 4.8 is not mainly a smarter chatbot. It is an attempt to improve the part that matters when the work gets long, messy, and expensive.

The benchmark story is real, but incomplete

There is a benchmark angle here, and it is worth taking seriously. Artificial Analysis currently places Claude Opus 4.8 at the top of its Intelligence Index frontier cluster, ahead of GPT-5.5 xhigh and GPT-5.5 high in the comparison snapshot linked below.

That is enough to say Opus 4.8 belongs in the top frontier tier. It is not enough to say it is universally the best model for every workflow.

That distinction matters because nobody actually buys "a benchmark." You buy a working system: model, provider, latency profile, tool behavior, cost envelope, and how often the thing finishes a real task without supervision.

The coding table matters more than the general leaderboard

For a release like this, the first table I want is not a general "who is smartest?" table. It is the coding-agent table.

The reported SWE-Bench Pro numbers are the clearest version of that right now:

Model	Coding benchmark	Reported score	Why it matters
Claude Opus 4.8	SWE-Bench Pro	69.2%	Strongest reported coding-agent score in this comparison
Claude Opus 4.7	SWE-Bench Pro	64.3%	Shows the direct Opus-to-Opus improvement
GPT-5.5	SWE-Bench Pro	58.6%	Still frontier-class, but behind this reported Opus 4.8 result
Gemini 3.1 Pro	SWE-Bench Pro	54.2%	Useful broad frontier comparison point

I would not overread this table. SWE-Bench is not your repo, your test suite, your code review standard, or your deployment budget.

But I would not ignore it either. A 4.9 point jump from Opus 4.7 to 4.8 on a coding benchmark is exactly the kind of thing that can matter in agent loops, especially if the model also gets better at flagging weak code instead of confidently moving on.

The price table is the other half

The second table is cost. A better model is not automatically a better default model.

Model or mode	Input price	Output price	Notes
Claude Opus 4.8 standard	$5 / 1M tokens	$25 / 1M tokens	Same standard list price as Opus 4.7
Claude Opus 4.8 fast mode	$10 / 1M tokens	$50 / 1M tokens	Research preview, roughly 2.5x faster output according to Anthropic
Claude Opus 4.7 standard	$5 / 1M tokens	$25 / 1M tokens	Useful baseline because 4.8 replaces this in the same price band
Claude Opus 4.7 fast mode	$30 / 1M tokens	$150 / 1M tokens	Reported previous fast-mode price point

That makes the release more interesting than a normal model bump. The standard price stays flat, but the fast path becomes much less painful.

For coding agents, speed is not cosmetic. If an agent is reading files, editing code, running tests, reviewing output, and doing another pass, every turn has a latency tax. Fast mode can change whether a workflow feels usable, even if it is not the cheapest way to burn tokens.

What Anthropic is actually claiming

Anthropic's own language is unusually specific. The official Opus page calls it a model that pushes the frontier for coding and AI agents, and the launch materials say it is stronger across coding, agentic tasks, and professional work.

That is a stronger claim than generic intelligence. It is a claim about operational behavior:

coding performance
agentic execution
tool use
consistency on long tasks
autonomy over multi-step work

That is the right lens for evaluating it. The useful question is not just whether a score moved up. The useful question is whether the model reduces failure inside a real coding loop.

The Opus 4.7 to 4.8 jump looks incremental, but that can still matter

Anthropic itself describes Opus 4.8 as a modest but tangible improvement on its predecessor. That reads as credible.

This does not look like a category reset. It looks like an iterative frontier upgrade with sharper emphasis on coding, better judgment during agentic work, and better behavior over long tasks. Anthropic also says early testers found it more reliable and more likely to flag uncertainty instead of overstating progress, which is exactly the kind of improvement that matters in autonomous workflows.

That kind of delta can be commercially meaningful even if it does not look dramatic in a launch graphic.

A coding agent does not need to be universally better at everything to be more useful. It needs to hold context longer, recover more cleanly, and make fewer silent bad decisions.

Claude Code is part of the release, not a footnote

The most relevant tooling angle is Claude Code.

Opus 4.8 did not arrive alone. Anthropic also pushed Dynamic Workflows in Claude Code as a research preview. The idea is simple: for a large coding task, Claude can split the job across many parallel subagents, verify work, and combine the result before reporting back.

That matters because model quality and coding-tool design are starting to blur together. A stronger coding model is useful. A stronger coding model inside a tool that can plan, fan out, check work, and recover from bad branches is more interesting.

This is also where the Codex comparison becomes relevant.

My Codex setup is already built around model routing and subagent orchestration. That means the practical comparison is not only "Opus 4.8 versus GPT-5.5." It is:

Workflow	Model angle	Tooling angle	What I would test
Claude Code + Opus 4.8	Strong coding-agent benchmark position	Dynamic Workflows, fast mode, Claude-native agent loops	Large repo migration, failing test repair, multi-file refactor
Codex + OpenAI models	Strong OpenAI coding stack and local routing	Explicit orchestrator plus subagents, review, verification loops	Same repo task with identical success criteria
Cursor or editor agents	Fast interactive coding loop	IDE-native context and diffs	Smaller edits, review latency, developer control

I have not run a controlled Claude Code versus Codex test on Opus 4.8 yet, so I would not claim a winner.

But this is the test that matters. Not which model writes the best launch demo. Which stack gets a messy change through implementation, tests, review, and cleanup with the least babysitting.

The workflow test matters more than the launch claim

Anthropic's release page says Opus 4.8 improves on benchmarks across coding, agentic skills, reasoning, and practical knowledge work tasks. That is a useful signal, and it is stronger than vague marketing language because Anthropic at least anchors the claim in a system card and named evaluations.

Still, a launch page is not the same thing as production proof.

For anyone building or buying coding agents, the real evaluation stack is broader:

benchmark position
coding-task reliability
context window
tool-use behavior
long-horizon autonomy
latency
throughput
token economics
provider quality

That last point gets underrated. The same model name can feel very different depending on where you run it.

Provider choice changes the economics

This is one of the most practical parts of the story.

On Artificial Analysis's provider benchmarking page for Claude Opus 4.8, Amazon is the fastest by output speed at 64.4 tokens per second, Anthropic follows at 62.1, and Google is close behind at 60.1. For latency, Google leads at 7.36 seconds to first token, Amazon is at 10.31 seconds, and Anthropic is at 20.02 seconds. Artificial Analysis also shows all three at the same blended benchmark price of $4.10 per 1M tokens in that comparison.

That is a useful reminder that "which model?" is only half the routing decision. "Which provider?" can materially change the experience even when the underlying model is identical.

For coding agents, that matters a lot. A sluggish provider can make a disciplined workflow feel mushy. A faster path can make repeated tool calls, verification passes, and long-context work feel much more usable.

Cost is more interesting than the headline suggests

Anthropic's official list pricing is unchanged from Opus 4.7: $5 per million input tokens and $25 per million output tokens for regular usage. Fast mode is listed at $10 per million input tokens and $50 per million output tokens.

Anthropic also says fast mode can run at 2.5x the speed and is now three times cheaper than it was for previous models. That makes the pricing story more interesting than "same price as before." The company is not just holding the base line steady. It is also trying to improve the speed-cost tradeoff for teams that care about turnaround time.

That official list pricing is separate from the Artificial Analysis provider screenshot. Anthropic's numbers are list price from the release page. Artificial Analysis's $4.10 figure is a blended benchmarking view across providers, not the official posted token rate.

In practice, the more important number is still cost per useful completed task.

A model that looks slightly expensive on paper can be cheaper in the real world if it finishes more runs cleanly, needs fewer retries, and wastes less review time. A model that looks cheap by token can become expensive if it stalls, drifts, or burns time with poor tool behavior.

What this means for GPT-5.5 comparisons

The cleanest supported comparison is the narrow one.

Artificial Analysis places Opus 4.8 slightly ahead of GPT-5.5 xhigh and GPT-5.5 high in the current frontier ranking snapshot. That supports the claim that Opus 4.8 is in the very top cluster and currently has a slight edge in that benchmark view.

It does not support a sweeping claim that Opus 4.8 beats GPT-5.5 everywhere.

That is fine, because "best model" is usually the wrong question anyway. The useful questions are narrower:

best for long coding-agent runs
best for low-latency interaction
best for strict budget pressure
best for giant context reads
best for tool reliability
best for unattended execution

Those are different buying decisions.

Why I think this release is worth watching

I spend most of my day building agentic software for HomeScout, my rental search product, so I care less about launch-day screenshots than about whether a model keeps working when a task gets long and annoying.

That is why Opus 4.8 stands out.

Not because one leaderboard moved. Not because every frontier lab says the new one is better. But because the release is explicitly aimed at coding and agentic behavior, the benchmark position is strong, the official pricing is clear, and the provider-level differences are large enough to affect real deployments.

The next useful evidence will not be another announcement thread. It will be whether agent teams start reporting fewer failed runs, cleaner tool use, and better long-horizon task completion with Opus 4.8 in production.

Until then, the practical takeaway is simple: Claude Opus 4.8 looks like a serious top-tier option for coding agents, but the real decision is still workflow fit, provider routing, and cost per completed task.

Source links

I am Caspar Bannink, founder of HomeScout (AI rental search for Dublin) and Bannink Software Development.

Check out my side project: homescout.io

Personal LinkedIn: linkedin.com/in/caspar-bannink-719440217

HomeScout LinkedIn: linkedin.com/company/homescout-io

Data Normalization Across Dublin Rental Portals: How to Make Listings Comparable

Caspar Bannink — Wed, 27 May 2026 12:26:54 +0000

Data Normalization Across Dublin Rental Portals: How to Make Listings Comparable

Dublin rental listings are fragmented even across the main portals. Daft.ie and Rent.ie use different structures, labels, price conventions, and quirks, which makes direct comparison harder than it should be.

When I built the comparison layer for HomeScout, the aggregation part turned out to be straightforward compared to normalization. Here's what the normalization problem actually looks like, and how I approached it.

The raw data problem

Consider something as simple as price. Across sources you'll see:

"€1,750 per month"
"1750 pcm"
"£1750/month" (some UK-registered portals still do this for Dublin listings)
"From €1,700" (minimum of a range)
"Price on application"
"1,750" with currency implied by context
"€1,750 per month + utilities" (you have to decide whether to strip the utility note or flag it)

That's one field. Beds has similar variation: "2 bed", "2 bedroom", "Two bedrooms", "2BR", "2+1" (2 beds plus a box room). Some sources omit beds entirely and describe the property type instead.

Area/location is the worst. Sources use different geographic taxonomies. One uses Dublin postal codes (D4, D6, D6W). Another uses neighborhood names (Rathmines, Ranelagh, Rathgar). Another uses the street address and nothing else. Some use both but inconsistently. The same property can appear as "Ranelagh, Dublin 6" on one source and "Dublin 6" on another, and you have to know those are the same area.

The normalization pipeline

Each source gets a custom extractor that produces a raw record. The raw record has whatever fields the source provides, with light cleaning (strip HTML, trim whitespace, decode entities). No interpretation yet.

The normalization step runs after extraction. It takes the raw record and produces a canonical record with typed, standardized fields.

Price normalization:

def normalize_price(raw_price: str) -> tuple[int | None, str]:
    """
    Returns (monthly_eur, price_qualifier)
    qualifier: 'exact' | 'from' | 'on_application' | 'unknown'
    """
    if not raw_price:
        return None, 'unknown'

    raw = raw_price.lower().strip()

    if 'application' in raw or 'poa' in raw:
        return None, 'on_application'

    # Extract numeric value
    amount = re.sub(r'[^\d,.]', '', raw)
    amount = amount.replace(',', '')

    try:
        value = int(float(amount))
    except ValueError:
        return None, 'unknown'

    # Weekly to monthly conversion
    if 'per week' in raw or '/week' in raw or 'pw' in raw:
        value = round(value * 52 / 12)

    qualifier = 'from' if raw.startswith('from') else 'exact'
    return value, qualifier

The qualifier field matters for display. A "from" price should be labeled differently than an exact price in comparison views.

Bedroom normalization:

Word-to-number mapping handles written numbers. The "+1" box room convention gets flagged separately so you can filter on actual bedrooms vs. "bedrooms including box room."

Geographic normalization:

This is the hard part. My approach:

Extract any Dublin postcode from the raw location string (regex for D1-D24, D6W)
If no postcode, attempt a fuzzy match against a neighborhood lookup table
If that fails, geocode the street address and assign to the containing postal district
If all else fails, store the raw string and flag for manual review

The neighborhood lookup table is a maintained JSON file with aliases. "Ranelagh" maps to D6. "Rathmines" maps to D6. "Rathgar" maps to D6. "Harold's Cross" maps to D6W. And so on. It's not glamorous but it works.

{
  "ranelagh": {"district": "D6", "canonical_name": "Ranelagh"},
  "rathmines": {"district": "D6", "canonical_name": "Rathmines"},
  "rathgar": {"district": "D6", "canonical_name": "Rathgar"},
  "harolds cross": {"district": "D6W", "canonical_name": "Harold's Cross"},
  ...
}

Deduplication

The same property often appears on multiple sources. Deduplication is a separate pass after normalization.

I use a blocking strategy: only compare listings within the same price band (+/- 10%) and same area (same district or neighboring districts). Within a block, I compute a similarity score based on:

Address string similarity (Levenshtein on the normalized address)
Price match (exact or within 5%)
Bed/bath match
Available date proximity

Score above threshold: mark as duplicate, keep the richest record (the one with more fields populated), store source provenance for both.

The threshold needs tuning. Too low and you collapse distinct listings. Too high and you miss obvious duplicates. I landed on a score that errs toward keeping separate records when uncertain, because a false merge (showing one listing when there are two) is worse than a false non-merge (showing the same property twice).

Making listings comparable in the UI

After normalization, every listing has the same fields in the same format. The comparison view is then straightforward: pick listings to compare, render their canonical fields side by side.

The useful columns for Dublin rentals turned out to be: price, beds, baths, area (with DART/Luas proximity calculated from lat/lng), included utilities, pet policy, available date, and lease term. I surface which fields came from structured source data vs. which were inferred from description text, because inferred data has lower reliability.

I wrote a more user-facing version of this at https://homescout.io/guide/how-to-compare-dublin-apartments-without-spreadsheet if you want to see what the normalized comparison looks like in practice.

The normalization work is not exciting. It's the kind of thing that takes three times longer than you expect and surfaces a new edge case every week. But it's the foundation everything else sits on.

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Building a Rental Aggregator When Daft.ie Already Exists

Caspar Bannink — Wed, 27 May 2026 12:26:43 +0000

Building a Rental Aggregator When Daft.ie Already Exists

When people find out I'm building a rental search platform for Dublin, the first question is usually some version of: "But why? Daft is already there."

It's a fair question. Daft.ie has dominant market share, brand recognition, a large team, and a listings database built over two decades. If I'm building something in the same space, I need a reason that goes beyond "I'll make it better." Better at what? By whose measure? And what's stopping Daft from just adding that feature?

Here's how I actually thought about it, and what the technical implications turned out to be.

What Daft does that I can't replicate

Before anything else: what Daft has that I don't have is supply-side lock-in. Landlords and letting agencies list on Daft because that's where renters look. Renters look on Daft because that's where landlords list. This is a genuine two-sided network effect that took years to build and can't be engineered around.

I'm not going to out-list Daft. My product doesn't have a listings CMS, a landlord login, or a monetized ad product. I don't want those things. That's not the game I'm playing.

The gap that aggregation addresses

Daft has a lot of listings. It doesn't have all of them.

The Dublin rental market has listings spread across Rent.ie, MyHome, smaller agency portals, property management company websites, and secondary platforms. Some letting agencies and landlords don't post to Daft at all. Others post there but also post to their own site with photos or descriptions that differ slightly.

When I was looking for a flat myself, I was checking six separate sites manually. That's the gap: not better listings, but a unified view of the listings that already exist.

The question then becomes: can I build a technical product that's genuinely better at aggregation than a user doing manual searches? And is that worth doing?

The aggregation architecture

The core is a crawler that runs on a schedule, pulling listing data from Daft.ie and Rent.ie. The challenges that weren't obvious until I was in it:

Source heterogeneity. Each source has its own structure. Daft has a clean API-like interface. Small letting agency sites are often hand-built with inconsistent HTML. Property management company sites sometimes generate listings dynamically in JavaScript, which complicates standard scraping. You end up with a per-source adapter layer that handles idiosyncrasies, feeding a shared normalization layer.

Deduplication. The same apartment often appears on three or four sources simultaneously. Without deduplication, a user sees the same property four times and thinks the market has more supply than it does. Deduplication based on address alone doesn't work reliably because addresses aren't formatted consistently. I use a combination of address fuzzy matching, price comparison, and image fingerprinting (when photos are available) to group duplicates. It's not perfect. False positives (merging two distinct listings) are worse than false negatives (showing a duplicate), so I tune conservative.

Change detection. Knowing that a listing is new requires knowing what was there before. Knowing that a listing is gone requires distinguishing "temporarily de-listed" from "taken." I keep a snapshot of each crawl and diff it against the previous one. Listings that are absent for two consecutive crawl cycles get marked as likely gone rather than immediately. This reduces false "this listing was taken" alerts.

Price normalization. Some sources list weekly prices, some monthly. Some include bills, some don't. All prices in the system get converted to monthly EUR before storage. This sounds trivial and took an embarrassing amount of time to get right across all sources.

Why not just build on top of Daft's data?

The obvious question. Daft has terms of service that prohibit scraping. More practically, building your entire product on one source you don't control creates a single point of failure that a cease-and-desist, a terms change, or a UI redesign can eliminate overnight.

The multi-source architecture is a risk hedge as much as a product feature. Any single source can break or become unavailable. Crawlers fall behind when sites update their structure. Source diversity means no individual source going offline kills the product.

Where this actually competes with Daft

It doesn't compete on listing volume for properties that are Daft-exclusive. It competes on:

Cross-source coverage. If a letting agency posts a property on their own site and nowhere else, my system finds it. Daft doesn't.

Search. Daft's search is filter-based: price range, beds, area from a dropdown. My search accepts natural language and handles the translation to structured filters. "2-bed near Ranelagh Luas, under 1900, pet-friendly" resolves to a structured query without the user having to manually set each filter.

Alerts. My alerts cover Daft.ie and Rent.ie simultaneously. A user doesn't have to set up and maintain separate alert logic on both portals.

Features Daft hasn't prioritized. AI lease review, application tracking, email composer. Features that are useful for the renter's workflow beyond just finding listings.

None of these make me "better than Daft" on Daft's terms. On the specific things I'm competing on, the product is genuinely different.

The strategic frame

The word "competing" is actually a bit wrong here. My product wraps publicly available listing data from Daft.ie and Rent.ie into a faster search and alert workflow. Daft is a source of inventory, not just a competitor. The relationship is asymmetric: they don't know or care I exist; I depend on continued public availability.

This creates a dependency risk I think about seriously. The mitigation is source diversity, features that add value beyond the listings themselves, and building enough user value that switching away from Daft's data specifically wouldn't kill the product.

I wrote a longer breakdown of the full comparison between portals and aggregators at https://homescout.io/guide/better-than-daft-dublin-rentals if you want the user-facing version of this.

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Building search features for users in different timezones. The remote renter problem.

Caspar Bannink — Wed, 27 May 2026 12:24:54 +0000

When I looked at who was actually signing up to HomeScout in the early months, the timezone distribution surprised me. A meaningful chunk of users were browsing and setting up alerts from outside Ireland entirely. Netherlands, Germany, Australia, the US. People who needed a Dublin apartment but weren't in Dublin yet.

That cohort has a fundamentally different set of constraints than a local searcher. Building for them forced some decisions I wouldn't have made otherwise.

The core UX problem: latency on a fast-moving market

Dublin rental listings have a short half-life. Something priced fairly in a good area will get 50-100 inquiries in 24 hours and be gone in 48. The search UX that works for a local user (check the app a few times a day, act when something looks good) fails completely for someone who's 8 hours behind or 10 hours ahead.

The design response to this is: push the user toward a decision earlier. The alert has to fire fast enough and contain enough information to act on immediately, without requiring a second step of "open the app and check."

Our alerts include:

Full listing title, address, price
Bedrooms, BER rating, available date
Commute time to the user's saved workplace (calculated at send time, not load time)
Direct link to both the HomeScout detail page and the original source listing

The goal is that a user in a different timezone, woken up by a push notification at 6am their time, can make a go/no-go decision before they're even out of bed.

Commute calculation as a core feature, not a filter

Most rental search tools treat commute as a filter you can optionally apply. You draw a radius or specify a max journey time. That's fine if you know the city's transport geography.

If you've never been to Dublin, you don't know that two neighborhoods that look equally close to city center on a map can have radically different commute times due to transport infrastructure. You don't know that the coastal DART line is reliable and fast, while a bus-dependent area of the same distance might add 30+ minutes to a commute.

We built commute as a first-class search parameter. You type your workplace, and the UI shows commute time alongside price and size rather than buried in a filter panel. When a user hasn't set a workplace, we prompt them to do it during onboarding rather than after they've already run a search.

The data layer: we use a combination of routing APIs for public transport journey planning. The challenge is that "commute time" depends on departure time, and users searching from abroad might not know what a realistic Dublin rush-hour departure looks like. We calculate using a standard weekday morning window (7:30-9:00am) and show that assumption explicitly rather than pretending we're giving a precise number.

Neighbourhood context without having visited

If I search for apartments in a city I've never been to and the listing says "vibrant area close to all amenities," I learn nothing useful. That phrase appears in listings in both the nicest and least nice streets in Dublin.

We built neighborhood context cards that try to surface genuinely useful information: the character of the area, the noise profile (especially relevant near nightlife strips), transport options, and rough price positioning relative to comparable areas.

The hard part is that this information is qualitative and changes. What was "up-and-coming" in 2022 may be settled now, or may still be rough depending on which block you're on. We've had to make editorial choices about how to characterize areas rather than purely relying on scraped data, and those choices need updating.

One approach we use: cross-referencing listing data with the distribution of listing prices and turnover rates in each area. Areas where listings disappear fast at or above asking price signal high actual demand. Areas with more inventory that sits longer tell a different story. This is less subjective than editorial characterization and updates automatically as new listings flow in.

The credibility problem for remote applicants

This one isn't a technical problem, it's a product problem. Landlords sometimes prefer local applicants because they can meet them. A remote applicant asking for special consideration (skip the in-person viewing, sign before arriving) is asking for trust they haven't established.

The product response is helping users communicate their situation well in their first inquiry. Remote renters who state their arrival date, employment situation, and reason for the remote search upfront get better outcomes. The inquiry email composer we built surfaces a "remote applicant" context option that prompts users to include that information.

What we don't have yet: any kind of verified identity or background check layer that would let a landlord have more confidence in a remote applicant. That's a real gap. It would probably require partnering with a tenant referencing service, which exists in the Irish market but adds friction that most users in early search stage aren't ready for.

Timing features vs timezone detection

We debated auto-detecting user timezone and adjusting UI accordingly (surfacing listings that were just posted vs. listings from hours ago, for example). We haven't built this. The complexity of getting timezone-aware UX right without making it feel weird to local users isn't worth it at our current scale.

What we did instead: show "listed X hours ago" very prominently on every listing card. This is simple and tells the remote user the one thing they most need to know: is this listing still worth pursuing or has it probably already gone?

If a listing is 6+ hours old in a competitive area, a remote user should know that their odds of getting a reply are significantly lower. Making that information front-and-center changes their behavior appropriately. They focus on the fresh listings and set up alerts for new ones rather than chasing cold ones.

I wrote a longer guide on the full remote apartment-hunting process in Dublin here: https://homescout.io/guide/finding-dublin-apartment-from-another-country

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

State management for real-world workflows: tracking apartment viewings and applications

Caspar Bannink — Wed, 27 May 2026 12:24:53 +0000

Apartment hunting is a stateful workflow. At any given moment, a user might have 15 listings in various stages: some saved, some inquired about, some with scheduled viewings, some attended, some applied to, some rejected. Each has associated data: emails, notes, documents, times, decisions pending.

Modeling this well is a product design problem more than a technical one. But the technical decisions you make about state structure shape what the product can actually do.

This is what I've learned building the application tracker for HomeScout.

The state machine

The viewing/application workflow has a natural state machine structure:

Saved → Inquired → Viewing Scheduled → Attended → Applied → Outcome
                                              ↓                  ↓
                                          Not Interested     Accepted / Rejected

With additional states like "Rescheduled" (a substate of "Viewing Scheduled") and "Waiting for references" (a substate of "Applied").

The question is how much of this to expose to the user. Early versions exposed the full pipeline with all substates. Users found it overwhelming. They didn't want to maintain an accurate state machine; they wanted a rough picture of where things stood.

Current version has seven states: Saved, Contacted, Viewing Scheduled, Viewed, Applied, Offer, Closed (rejected/accepted/withdrawn). That's enough structure to give an overview without requiring micro-updates to every state transition.

Data model decisions that matter

Each tracked listing needs:

Reference to the canonical listing (price, location, photos, specs)
Viewing datetime (nullable, set when scheduled)
User notes (free text, the most-used field)
Status enum
Last-action timestamp (for sorting the list by recency of activity)
Reminder datetime (nullable, for follow-up nudges)

The canonical listing reference is tricky. Listings on rental portals disappear when let. If a user is tracking an application and the listing goes dead, you need to have captured the listing data rather than holding a reference to a URL that will 404. (Most renters who are tracking 10+ properties simultaneously are also dealing with the speed problem — setting up real-time alerts is what keeps the pipeline from going stale before you can even schedule viewings.)

We snapshot the listing data at the point of save: title, price, address, description, photos (or at least photo URLs, with the understanding they may eventually 404). This creates storage overhead but is necessary for the tracker to remain useful after a listing closes.

The alternative (storing only a URL) fails silently in the worst way: the user's tracker looks fine but clicking through gives them nothing, exactly when they're trying to reference details before an interview or application.

The calendar view problem

Showing upcoming viewings in a calendar seems straightforward. The complications:

Timezone. Users searching from abroad (a meaningful chunk of our user base) may have their device in a different timezone than Dublin. We store viewing datetimes in UTC with Ireland timezone display. We show the timezone explicitly in the viewing confirmation so remote users know what "Thursday 2pm" means in their local time.

Conflict detection. Users sometimes accidentally schedule two viewings at the same time, or with insufficient travel time between them. We flag conflicts (exact time overlap) but don't try to flag "you've booked two viewings 15 minutes apart and they're across the city." That requires knowing travel time between the two viewing addresses, which we could calculate but haven't yet. Simple conflict detection catches the obvious case.

Duration assumption. We default to 30 minutes per viewing block in the calendar. Most viewings are shorter, some run longer. We let users edit duration but most don't. The 30-minute default gives enough visual separation in the calendar to make conflicts obvious.

Notes: the underrated feature

Post-viewing notes are the feature users engage with most, measured by time spent interacting. They enter them right after a viewing (sometimes before they've left the building) and come back to them when making a decision a week later.

The design decisions that made this work better:

No formatting. Early version had a rich text editor. Users wanted to type fast and didn't want to think about formatting. Plain text input with newlines is what they actually need.

Persistent draft. If a user starts typing and closes the app, the draft is saved. Property viewings happen in the real world; people are typing on their phone and getting interrupted. Losing notes because the session closed is the worst outcome for a feature whose value is capturing transient impressions.

Timestamps on notes. Each note shows when it was added. This matters when a user has multiple notes on a property across different visits or different points in the application process.

The reminder problem: where we're at

Follow-up timing is the biggest behavioral lever in rental searching. The window between "attended viewing" and "property offered to someone else" is often 24-48 hours. Users who follow up in that window have much better outcomes than users who follow up on day 3.

We know this. Our reminder system is still too manual. The right behavior is: status transitions to "Attended + Interested" trigger an automatic 24-hour reminder. We have the data model for reminders. We have the user intent signal (the "Interested" flag). The gap is that we haven't wired the automatic trigger.

The reason it's not done yet is partly scope and partly that automatic reminders require notification permissions, which add friction to onboarding. We kept onboarding low-friction early on. Notification permission prompts add a step that some users drop off at.

The resolution is probably to ask for notification permission at the point a user schedules their first viewing, when the value prop ("get reminded about this viewing") is concrete. Not at onboarding when it's abstract. That's the standard pattern for permission request timing and it applies here.

What the state machine doesn't model well

Applications are more document-intensive than viewings. For a formal application you might submit a reference letter, an employment letter, 3 months of bank statements, proof of current address, and a photo ID. Tracking which documents you've gathered, which properties you've submitted to, and whether the landlord has confirmed receipt is its own workflow.

We have basic document tracking (checkboxes for standard document types) but it's not well integrated with the per-property status. This is a real gap. The users who manage applications to multiple properties simultaneously are the ones who most need this, and they're also the users with the most acute pain if they forget to submit something.

It's also a potentially sensitive feature: these are financial and identity documents. Any feature that involves storing or transmitting them needs to be handled carefully. We currently don't store documents, just track whether you've gathered them. That's the right call for now.

The full application management problem, including document collection and submission, is probably a separate product surface from viewing management. They're related workflows but distinct enough that bundling them into one view creates cognitive load.

I mapped out the whole viewing logistics problem from the user side here: https://homescout.io/guide/managing-rental-viewings-dublin-without-losing-mind

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Why Landlords Never Reply

Caspar Bannink — Mon, 18 May 2026 21:40:11 +0000

The Dublin rental market has a response rate problem. The average renter sends a generic inquiry to 20+ properties and hears back from maybe 2 or 3. I measured this through user interviews and it tracks with what academic research on UK/Irish rental markets has found: response rates for cold rental inquiries sit somewhere between 12% and 20% depending on the area and season.

This is a signal quality problem wrapped in a UX problem. And it's exactly the kind of thing you can build against.

What the data actually looks like

When a listing goes live on Daft.ie (the dominant Irish rental portal), it typically receives 50-150 inquiries in the first 48 hours. There's no landlord-side inbox tooling beyond email forwarding. No status tags, no filtering, no templates for responses.

The landlord opens it, skims a subset, replies to whoever seems credible and convenient, and moves on. The inquiry that lands in position #78 in their inbox could be from a perfect tenant. They'll never see it.

On the applicant side, the constraint is symmetric. Renters know supply is short and competition is high. Rational strategy is to apply wide. So they send the same message to 20 places. Landlords recognize this pattern and deprioritize anything that sounds like a blast email. The market equilibrium is low signal on both sides.

The technical problem: generic text is detectable

From a signal processing standpoint, a landlord reading 150 emails is doing a classification task. "Does this person seem like they actually want THIS property, or are they spamming everything?" Generic emails fail that classifier.

What passes the classifier:

Mentions something specific from the listing (the garden, the commute distance to a named workplace, the pet policy)
Answers the implicit screening questions (move-in date, lease length preference, employment type)
Has a coherent reason for wanting that specific location

Writing this for each of 20 properties manually is O(n) effort. Most people won't do it. That's the gap to build against.

What we built and how it works

HomeScout has an AI email composer that generates property-specific inquiry drafts. The flow:

User finds a listing they want to apply to
They click "Generate inquiry"
The system reads the listing data (title, description, location, price, landlord-specified requirements if any)
It generates a draft that references specifics from the listing and includes answers to the standard screening questions
User reviews and edits before sending

A few things we got wrong in early versions:

Too formal. First drafts sounded like legal correspondence. Real inquiry emails are conversational. People don't write "I would like to express my interest in the aforementioned property." They write "I'd love to come view this, I work nearby and the commute would be ideal."

Hallucinating specifics. Early versions made up details that weren't in the listing. "I noticed the property has a south-facing garden" when the listing said nothing about the garden's orientation. That's a problem when the landlord reads it. We added a strict constraint: only reference what's explicitly in the listing data.

Missing the implicit screening questions. The questions landlords actually care about (when can you move, how long do you want, are you employed) aren't always in the listing. We built a user profile layer so those answers get included from the renter's saved preferences rather than being generated per-inquiry.

The model choice question

This is one of those tasks where the quality delta between models matters more than the cost delta. The difference between a mediocre and a good inquiry email is meaningful, and the output is user-facing in a context where the stakes are real (someone might get or not get a viewing based on this).

We use GPT-4o for this feature. We tested smaller models. The failure modes were too common: hallucinated specifics, wrong tone, missing context from the listing. 4o is measurably better on this specific task. The cost is acceptable given the feature's value.

We also considered fine-tuning on successful inquiry emails, but our dataset isn't large enough to make that worthwhile yet. It's on the roadmap once we have more throughput.

Prompt engineering notes

The prompt structure that works best for this:

System prompt establishes the persona (renter, not an AI assistant) and the tone (conversational, specific, not corporate)
Listing data is passed as structured context, not raw HTML scrape
User profile answers are included as a short bullet list for the model to draw from
Explicit negative instructions: don't fabricate specifics, don't use formal register, don't mention that this is AI-generated
Output format: plain text, no subject line, 3-4 short paragraphs

The negative instructions matter more than the positive ones. The default model behavior drifts toward formality and generic language. You have to actively constrain it away from those patterns.

What comes next

The honest answer is that email composer is a partial fix. The underlying problem is that landlord inboxes have no structure, so even a good inquiry can get lost. The complete solution involves building tools on the landlord side too: structured applicant pipelines, automated first-response, viewing scheduler. That's a different product scope.

For now, improving inquiry quality is the lever we can pull on the renter side. And it does move the needle. Users who use the composer report better outcomes than users who don't.

I wrote a longer breakdown of the full response rate problem and its market context here: https://homescout.io/guide/why-landlords-never-reply-dublin-rental

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Architecture of a Rental Aggregator: Scraping and Normalizing 90+ Sources

Caspar Bannink — Mon, 18 May 2026 21:39:55 +0000

Building a rental aggregator for Dublin means pulling data from a fragmented market: one dominant portal, a handful of mid-tier sites, dozens of letting agency websites, property management company portals, and a long tail of small sources. Here's how the system is structured and where the interesting problems are.

Why existing portals aren't enough

The standard answer for finding Dublin rentals is Daft.ie. It has good coverage and solid search. The problem is that coverage isn't complete. Letting agencies list exclusively on their own websites. Some landlords use smaller portals. A non-trivial share of listings never hits Daft at all.

If you're only searching Daft, you're seeing maybe 60-70% of what's available. For a renter in a tight market, that gap matters.

An aggregator's value proposition is simple: search everything, show results in one place. The technical challenge is that "everything" means 90+ sources with no shared API, no standard format, and varying levels of scraping difficulty.

Source taxonomy

I classify sources into tiers based on scraping approach:

Tier 1: Structured APIs or feeds. A small number of sources expose RSS feeds or have semi-public JSON endpoints. These are easy. Pull, parse, done.

Tier 2: Consistent HTML structure. Most mid-tier portals have stable enough HTML that a straightforward scraper works reliably. BeautifulSoup or Playwright depending on whether the content is server-rendered or JS-generated.

Tier 3: Letting agency sites. These are the hardest. Each one is different. Some run on estate agent CMSes (Property Hive, Agentbox, PropertyBase), which gives you a consistent structure within a platform family. Others are custom-built or use generic CMS platforms with property listings bolted on. I maintain source-specific extractors for each one.

Tier 4: Social and informal. Facebook Marketplace, some WhatsApp community channels that get scraped via publicly accessible links. Lower data quality, higher volume of noise.

The scraping layer

Each source has a scraper that handles:

Discovery: Finding listing URLs. Pagination, sitemap traversal, or feed parsing depending on source type.
Extraction: Pulling raw data from a listing page. Structured fields where available, falling back to HTML parsing.
Change detection: Tracking whether a listing we've already seen has changed (price update, status change, taken down).

For JS-heavy sources I use Playwright with a headless Chromium instance. The overhead is significant compared to simple HTTP requests, so I only use it where necessary. Most letting agency sites are server-rendered and much cheaper to scrape.

Rate limiting is handled per source. I track request timestamps per domain and enforce minimum intervals. The last thing you want is to get blocked from a source because you hammered it.

class RateLimiter:
    def __init__(self, requests_per_minute: int):
        self.min_interval = 60.0 / requests_per_minute
        self.last_request: dict[str, float] = {}

    async def wait(self, domain: str):
        now = time.time()
        last = self.last_request.get(domain, 0)
        elapsed = now - last
        if elapsed < self.min_interval:
            await asyncio.sleep(self.min_interval - elapsed)
        self.last_request[domain] = time.time()

The normalization layer

Every extractor produces a raw record. The normalization pipeline converts raw records to canonical form. I covered this in detail in the data normalization post, but the key fields are:

Price: always monthly EUR, with a qualifier (exact/from/on_application)
Bedrooms: integer, separated from "box room" counts
Location: normalized to neighborhood + postal district + lat/lng
Pet policy: boolean or null (not inferred when absent)
Available date: ISO 8601 or null
Source provenance: which extractor, when fetched, source URL

The normalization step is where most of the bugs live. Edge cases in source formatting surface constantly. A source starts using a new price format. A letting agency relaunches their website with different HTML structure. I run normalization in a separate pass from extraction so I can reprocess raw records when normalization logic changes without re-scraping.

Deduplication

Cross-source deduplication is essential. The same property often appears on multiple sources. Without deduplication, a user would see the same listing three times with slightly different data.

The deduplication approach is blocking plus similarity scoring:

Block by price band (+/- 10%) and geographic area (same district or adjacent)
Within blocks, score similarity on address string, price, beds, baths, available date
Pairs above the threshold get merged. The canonical record keeps the richest data from all matching sources.

This runs as a batch job after normalization completes for a crawl cycle.

Storage and freshness

Listings go into Postgres. I keep full history: every time a listing changes, the previous state is preserved with a timestamp. This lets me track price changes over time, which surfaces useful signals (listings that drop in price are often still available and motivated to rent).

Each listing has a freshness_score that decays over time. The score starts high when a listing is first seen or updated, and drops on a schedule tuned to how frequently that source typically updates. Stale listings get surfaced to users with a staleness label rather than hidden completely, because they might still be available.

The crawl cycle runs on a schedule per source. High-value sources (the main portals) run every 15-30 minutes. Long-tail sources run every few hours. The full catalog is refreshed within a 24-hour window at minimum.

Where this breaks down

A few honest failure modes:

Listings that go fast. A listing can be posted and let within hours. If a source is on a 4-hour crawl cycle, the user might never see it. For the highest-priority sources I push the crawl frequency as high as the site tolerates. But there's no fix for a source that updates infrequently.

Data accuracy. Scraped data is only as accurate as the source. Listings sometimes have wrong prices, wrong bed counts, or outdated availability dates. There's no reliable way to independently verify these without viewings. I surface source data as-is with the provenance visible.

CAPTCHAs and bot detection. Some sources actively block scraping. I don't fight these. If a source blocks me, I either find a publicly accessible feed or exclude that source.

I wrote a more user-facing view of how the aggregation works at https://homescout.io/guide/tools-find-apartment-dublin. This post is the technical layer underneath that.

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Managing Rental Viewings

Caspar Bannink — Mon, 18 May 2026 21:39:38 +0000

Modeling this well is a product design problem more than a technical one. But the technical decisions you make about state structure shape what the product can actually do.

This is what I've learned building the application tracker for HomeScout.

The state machine

The viewing/application workflow has a natural state machine structure:

Saved → Inquired → Viewing Scheduled → Attended → Applied → Outcome
                                              ↓                  ↓
                                          Not Interested     Accepted / Rejected

With additional states like "Rescheduled" (a substate of "Viewing Scheduled") and "Waiting for references" (a substate of "Applied").

Data model decisions that matter

Each tracked listing needs:

Reference to the canonical listing (price, location, photos, specs)
Viewing datetime (nullable, set when scheduled)
User notes (free text, the most-used field)
Status enum
Last-action timestamp (for sorting the list by recency of activity)
Reminder datetime (nullable, for follow-up nudges)

The calendar view problem

Showing upcoming viewings in a calendar seems straightforward. The complications:

Notes: the underrated feature

The design decisions that made this work better:

No formatting. Early version had a rich text editor. Users wanted to type fast and didn't want to think about formatting. Plain text input with newlines is what they actually need.

Timestamps on notes. Each note shows when it was added. This matters when a user has multiple notes on a property across different visits or different points in the application process.

The reminder problem: where we're at

The reason it's not done yet is partly scope and partly that automatic reminders require notification permissions, which add friction to onboarding. We optimized onboarding for low friction early on. Notification permission prompts add a step that some users drop off at.

What the state machine doesn't model well

I mapped out the whole viewing logistics problem from the user side here: https://homescout.io/guide/managing-rental-viewings-dublin-without-losing-mind

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Building a Real-Time Listing Alert System: Polling, Webhooks, and Monitoring 90+ Sites

Caspar Bannink — Mon, 18 May 2026 21:39:19 +0000

The alert system is the most user-critical feature in a rental aggregator. Users care most about being notified quickly when something matches their criteria. Here's how I built it, what I evaluated first, and where the interesting tradeoffs are.

The options: webhooks, RSS, polling

Webhooks would be ideal. Source site posts a listing, fires a webhook to your system, you process and alert within seconds. Zero wasted requests, minimal latency.

Reality: almost no rental portals expose webhooks. This isn't a technical limitation on their end. They just haven't built it, and in many cases scraping is technically prohibited by their ToS. The webhook path is effectively unavailable for most sources.

RSS feeds are available from a small number of sources. Daft used to have them. A few smaller sites still publish them. Where they exist they're great: structured, cacheable, low overhead. But coverage is limited.

Polling is what you actually use. You hit each source on a schedule, parse the results, diff against what you've already seen, and trigger alerts for new listings. It's the slowest and most resource-intensive option, but it's the one that works across all sources.

The system design challenge with polling is making it fast enough to be useful without hammering sources.

The polling architecture

Each source has a crawler that runs on a schedule. Crawlers are classified by priority:

High-priority sources (main portals, high listing volume): crawl every 15-30 minutes
Medium-priority sources (secondary portals, mid-tier agencies): crawl every 1-2 hours
Low-priority sources (small agencies, long-tail sites): crawl every 4-12 hours

Within a crawl, the crawler fetches the listing index (search results page or feed), extracts listing IDs and basic metadata, and compares against the stored state. Only changed or new listings trigger a full extraction. This keeps full-page requests proportional to the change rate, not the crawl rate.

async def crawl_source(source_config: SourceConfig) -> list[RawListing]:
    # Fetch listing index (search results or feed)
    index_items = await fetch_index(source_config)

    # Load stored state for this source
    stored = await db.get_listing_ids(source_config.source_id)
    stored_set = {item.external_id for item in stored}

    new_ids = {item.external_id for item in index_items} - stored_set

    # Only fetch full listing pages for new listings
    new_listings = []
    for item in index_items:
        if item.external_id in new_ids:
            listing = await fetch_full_listing(item.url, source_config)
            new_listings.append(listing)

    return new_listings

This approach means most crawl cycles result in zero full-page fetches. The overhead scales with the listing change rate of the source, not the total inventory size.

Diffing and change detection

When a listing is fetched, I store a content hash alongside the structured data. On subsequent crawls:

Same hash: no change, skip
Different hash: fetch full listing, update stored record, check if the change affects any active alerts

Price changes get special handling. A listing that drops in price might not be "new" but it becomes relevant to users who were previously priced out. The alert system checks price-sensitive alerts when price changes are detected, not just on new listings.

Listings that disappear from the index are marked as potentially taken. I don't immediately remove them from user views because sources sometimes temporarily de-list listings without them being actually let. I wait for two consecutive crawl cycles where the listing is absent before marking it as gone and stopping alerts on it.

The alert matching engine

Users set up saved searches with typed criteria: price range, beds, area, transport proximity, pet policy, and optionally a freetext description preference.

When new listings come in, each one is scored against all active saved searches. The matching is two-stage:

Structured filter check (hard pass/fail): does the listing meet the hard criteria (price, beds, area)? If not, stop. This is fast and handles most rejections.
Soft preference scoring (for listings that pass the filter): score the listing against any freetext preferences using the embedding similarity approach described in the search article. Listings above a similarity threshold trigger an alert. Listings below it go into a "possible match" digest rather than an instant alert.

This prevents freetext preferences from flooding users with weak matches while still surfacing them at lower priority.

Delivery and deduplication

Alerts go via email by default. The delivery layer handles:

Per-user rate limiting: a user with five saved searches shouldn't get fifteen emails in a minute if fifteen listings come in. I batch alerts within a short window and send a digest.
Cross-search deduplication: the same listing can match multiple saved searches for the same user. It gets mentioned once in the alert, with a note about which searches it matched.
Platform deduplication: the same physical property sometimes appears on multiple sources. After normalization and deduplication, only one record per property exists. Alert matching happens on deduplicated records, so users don't get alerted twice for the same apartment.

Where the latency actually lives

The end-to-end latency from a listing being posted to a user getting an alert is:

Time until next crawl of that source (0-30 minutes for high-priority sources)
Extraction and normalization time (~seconds)
Alert matching time (~seconds for the active alert set)
Email delivery (~seconds to minutes depending on provider)

For high-priority sources the realistic alert latency is 5-35 minutes. That's competitive with Daft's own alert system, and it covers sources Daft doesn't.

The gap I haven't solved: if a listing goes live and gets taken at 2:00am while the next crawl is at 2:20am, users will get an alert for something that's already gone. This is a fundamental limitation of polling-based systems. I note it clearly in the product rather than pretending it doesn't happen.

Infrastructure

The crawl jobs run as async workers. I use a task queue (Celery with Redis as broker) to schedule crawls, with priority queues for high-priority sources. The queue approach means I can add crawl workers horizontally when source count grows.

Postgres handles all storage. The listings table has a GIN index on the JSONB amenities column, and standard B-tree indexes on price, beds, area, and source. Alert matching queries run in under 100ms for the current dataset size.

I wrote a user-facing version of how alerts work at https://homescout.io/guide/free-rental-alerts-dublin. This post is the internals behind it.

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Finding Apartment From Abroad

Caspar Bannink — Mon, 18 May 2026 21:39:03 +0000

That cohort has a fundamentally different set of constraints than a local searcher. Building for them forced some decisions I wouldn't have made otherwise.

The core UX problem: latency on a fast-moving market

Our alerts include:

Full listing title, address, price
Bedrooms, BER rating, available date
Commute time to the user's saved workplace (calculated at send time, not load time)
Direct link to both the HomeScout detail page and the original source listing

The goal is that a user in a different timezone, woken up by a push notification at 6am their time, can make a go/no-go decision before they're even out of bed.

Commute calculation as a core feature, not a filter

Most rental search tools treat commute as a filter you can optionally apply. You draw a radius or specify a max journey time. That's fine if you know the city's transport geography.

Neighbourhood context without having visited

The credibility problem for remote applicants

Timing features vs timezone detection

I wrote a longer guide on the full remote apartment-hunting process in Dublin here: https://homescout.io/guide/finding-dublin-apartment-from-another-country

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.

Dont Know Where To Live

Caspar Bannink — Mon, 18 May 2026 21:38:48 +0000

One of the first onboarding questions we tried for HomeScout was: "Which area of Dublin are you looking in?"

It failed. A large percentage of users either skipped it, answered "anywhere," or picked one area then spent their first session clearly confused about why what they wanted wasn't there.

The issue was that we'd assumed users had a mental model of Dublin they didn't have. Asking "where in Dublin" when someone has never been to Dublin is roughly like asking "which part of the API are you trying to call" when someone is writing their first web request. The question assumes foundational knowledge that doesn't exist yet.

Fixing this required rethinking what "finding a neighbourhood" actually means computationally and from a UX standpoint.

The actual decision structure

Choosing where to live involves several loosely connected decisions:

What areas are reachable given my commute constraint?
Among those, which have apartments in my price range?
Among those, which match my lifestyle preferences (noise level, walkability, urban/suburban feel)?
Among those, which have supply available right now?

Most rental search tools treat this as a map filter: draw a shape, see listings inside it. That works if you already know which shape to draw. It fails for new-to-city users because the shape-drawing step requires domain knowledge they don't have.

The alternative framing: accept commute and price as hard constraints, treat lifestyle preference as a soft ranking signal, and generate a candidate neighborhood list rather than asking the user to specify one.

Commute as constraint: the implementation

Commute calculation is the most technically interesting part of this. The naive approach (radius from a point) is wrong for Dublin because the transport network is highly directional. A 5km radius from a workplace in the south docks includes areas with 15-minute DART connections and areas with 50-minute bus rides.

We calculate commute using routing APIs with a morning peak window (7:30-9:00am departure, weekday). The result is a travel-time isochrone: a set of points reachable from the workplace within a given time limit.

A few things we learned doing this:

Mode matters more than distance. The DART covers its route fast. Areas on the DART line that look far on a map are closer in real commute terms than areas that look near but require a bus connection. The isochrone algorithm captures this naturally, but it surprised users in early testing who expected proximity on a map to correlate with commute time.

The isochrone edge is fuzzy. A listing 300 meters outside a "45-minute commute" isochrone might actually be fine depending on departure time variance, walking pace, and platform dwell time. We show commute estimates with a "approximately" qualifier and don't hard-clip results at the edge.

Public transport is time-of-day dependent. We calculate for morning peak because that's the binding constraint for most users. Some users commute against peak or work flexible hours. We have a preference for this but don't over-engineer it since most users don't fill out detailed schedule information.

Neighborhood characterization: the data problem

Commute filters get you from 90+ possible areas to maybe 8-15. The next step is helping users evaluate those areas without visiting them.

The data sources for neighborhood characterization that are actually useful:

Listing density and price distribution. An area with 50 listings in a price band signals high supply. An area with 3 listings signals either high demand (things disappear fast) or low fit with the price range. We show listing volume alongside price median. For context on which Dublin neighborhoods actually come out cheapest for tech workers specifically, the best areas for tech workers guide has the breakdown.

Listing age distribution. Areas where listings disappear in under 24 hours have higher real demand than areas where the same listings sit for a week. This isn't available from portals directly, but we can observe it from our scraping cadence. If we see a listing at scrape time T and it's gone at T+24h, we record that.

Price trends over scraping history. If a neighborhood's median listing price has increased 8% in the last 6 months, that's a signal about demand pressure that a static price display doesn't capture.

Editorial character data. Some things can't be inferred from listing data. Noise profile, feel at night, walkability, community character. We wrote these manually for each main neighborhood based on a combination of direct experience, user feedback, and cross-referencing sources like local community boards and Google Maps review patterns. This doesn't scale infinitely but covers the 25-30 neighborhoods that account for the majority of Dublin rental activity.

The recommendation UI decision

Early version: we generated a ranked list of neighborhoods and showed it as "recommended for you."

Users didn't trust it. The main piece of feedback was: "How did you decide this?" The ranking was opaque and felt arbitrary even when it was correct.

Current version: we show neighborhoods as a filterable grid with the relevant stats visible (median price, commute time, estimated availability, character tags). Users apply their own judgment. The system does the data work; the user does the deciding.

This is less impressive as a product demo. It doesn't have a "magic recommendation" moment. But retention after first search is better, because users feel like they made an informed decision rather than following a machine.

The lesson: for decisions with high personal weight (where you live for the next year), users want tools that support their judgment, not replace it. This is a domain where explainable over clever is the right call.

What's still wrong

The characterization data goes stale. Dublin neighborhoods change. The manual editorial layer needs periodic updates and we don't have a good automated signal for when a neighborhood's character has shifted enough to warrant a re-write.

The commute data is only as good as the routing API, which uses GTFS data for public transport. GTFS data for Dublin Bus is notoriously incomplete and sometimes out of date. We supplement it with real journey time validation, but it's a moving target.

User preference capture is still too shallow. "Quiet area" means different things to different people. We ask a handful of questions but haven't built anything sophisticated enough to actually model lifestyle fit with accuracy. That's probably the next thing worth investing in.

The renter-facing version of this neighborhood analysis is here: https://homescout.io/guide/moving-dublin-dont-know-where-to-live

Caspar Bannink. Founder of HomeScout.io. Building AI-powered rental search for Dublin.