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.
Top comments (0)