Overview
I was searching for a house in London and became frustrated by how much manual comparison existing property platforms required. Rightmove and Zoopla were useful for finding listings, but weren't particularly good at helping me make the actual decision.
My criteria involved more than price, bedrooms and postcode: commute routes, neighbourhoods, a proper private garden for our dog, floor plans, condition, tenure and value for money. A property might technically meet every conventional filter while being completely unsuitable in practice.
My role
I acted as product owner, user, designer and developer, using AI coding assistance to accelerate implementation. Self-initiated, June to September 2026, through numerous iterations up to v18.1.
Process
The loop was always the same: experience the problem, define the requirement, implement it, use it, find what fails, refine.
1. A functional alternative
I was looking at several distinct neighbourhoods at once, so searches support multiple stations or areas, each with its own radius. Commutes are configurable by destination and transport mode, and use real Google routes. Being near a station didn't necessarily mean an acceptable journey.
An important early correction was eliminating fabricated fallback listings and unsupported property information. I decided to prioritise accurate information over quantity of returned results.
2. From search results to a decision-making workspace
Properties can be triaged (hide, watch, watch for a price drop, enquired) and given persistent notes. Each property has a stable identity so notes and decisions survive repeated searches and appearances on different portals, with conservative cross-portal deduplication. Preserve the user's mental work.
3. Showing the image that matters
Property cards usually lead with the estate agent's chosen hero image. I often wanted to see the garden or floor plan first, so cards have four media modes: Photo, Garden, Floor plan, and Garden + plan.
Garden mode needed image classification. Early selections confused a usable garden with trees, roads, building exteriors or nearby green spaces. I refined it to favour visible lawns, patios and decking, and penalise roads, cars, front elevations and tree canopies. When confidence is low, it falls back to the lead photo, and you can still pick the main and garden image yourself. What information is prioritised is entirely based on the user's preference.
4. Designing around incomplete information
An unknown tenure, missing floor area or unavailable floor plan doesn't necessarily make a property unsuitable. So the app distinguishes verified facts, calculated information and genuinely unknown information, and keeps missing details visible and flagged.
Conditional requirements came from this too: a balcony might be fine for a flat, but doesn't substitute for a garden in a house. Freehold and leasehold properties get their own bathroom and outdoor-space rules. Uncertainty is made explicit.
5. Speed and continuity
Card, map and split views link the geographic and listing-based views. Results appear promptly and are then enriched with verified details, searches are time-bounded, and partial results are kept if one source fails. Saved searches run in the background and notify only for genuinely new properties. A useful partial result, presented transparently, is often better than a perfect result delivered too late.
Impact
I used it throughout my own house hunt. It runs locally on my Mac with multi-source searches, maps, real commute routing, garden and floor plan modes, persistent notes and triage, deduplication, explicit unknown-data handling, and scheduled alerts.
It was never meant as a commercial launch. Live portal access, image detection and search reliability needed repeated engineering work, and not every improvement was tested in production-like conditions.
Conventional property-search interfaces optimise for browsing listings. My real problem was making and remembering decisions, and that is what this tool ended up being designed around.