How I Built a Property Matching System Using Euclidean Distance

mark m — Fri, 12 Jun 2026 07:14:17 +0000

Most accommodation platforms sort by price and star ratings. When I started building Voyera, a ski accommodation platform for Niseko, Japan, I wanted something different: a system that understands what each guest actually cares about and matches them to properties accordingly.

The result is the Voyera Index, a six-dimension mapping system that treats every property as a shape rather than a number.

The problem with star ratings

A 4-star hotel tells you almost nothing about whether it fits your trip. A couple looking for a quiet retreat and a group of ten looking for a ski-in/ski-out chalet with a hot tub could both be searching for "4-star accommodation in Niseko." They'll get the same results, sorted by price, and spend hours figuring out what actually works.

The dimensions that matter are different for every guest. Some care about proximity to the lifts. Others want space and privacy. Some need a full kitchen and laundry for a family of six. Star ratings collapse all of that into a single number.

Six dimensions instead of one

The Voyera Index maps every property across six dimensions:

Luxury: fit, finish, and overall quality of the accommodation
Facilities: on-site amenities like hot tubs, saunas, gyms, ski storage
Access: how close and how easy it is to reach the slopes
Value: what you get relative to what you pay
Privacy: seclusion, space, and independence from other guests
Groups/Family: suitability for larger parties, kids, and multi-generational trips

Each property gets a value from 0 to 5 on each dimension. Plot those six values and you get a shape, a radar chart that acts as the property's fingerprint. A luxury penthouse with poor ski access looks completely different from a basic apartment right on the slopes.

Where Euclidean distance comes in

The matching works by asking guests to set their own priorities across the same six dimensions. Their answers produce an "ideal shape." Then it's a distance calculation.

If a guest's ideal shape is:

[Luxury: 4, Facilities: 3, Access: 5, Value: 2, Privacy: 1, Groups: 4]

And a property's shape is:

[Luxury: 3, Facilities: 4, Access: 4, Value: 3, Privacy: 2, Groups: 4]

The Euclidean distance between them is:

d = sqrt((4-3)² + (3-4)² + (5-4)² + (2-3)² + (1-2)² + (4-4)²)
d = sqrt(1 + 1 + 1 + 1 + 1 + 0)
d = sqrt(5)
d ≈ 2.24

The lower the distance, the closer the match. Rank every property by distance and the guest gets results ordered by fit, not price.

Weighted dimensions

Not all dimensions matter equally to every guest. Someone who marks Access as their top priority and does not care about Luxury should see a different ranking than someone with the opposite preferences.

Weights solve this. If a guest weights Access at 3x and Luxury at 0.5x, the distance formula becomes:

d = sqrt(0.5*(4-3)² + 1*(3-4)² + 3*(5-4)² + 1*(2-3)² + 1*(1-2)² + 1*(4-4)²)
d = sqrt(0.5 + 1 + 3 + 1 + 1 + 0)
d = sqrt(6.5)
d ≈ 2.55

The weighted version penalises mismatches on dimensions the guest cares about most.

The visual language

Each property's six-dimension shape renders as a radar chart. Guests can compare properties visually without reading descriptions. A property that ranks high on Access and Value but sits low on Luxury and Privacy has a distinctive elongated shape. You can see the trade-offs at a glance.

This also powers the “Find My Stay” quiz on voyera.com, where guests answer a few questions about their trip after entering their preferred dates. They then get ranked property suggestions based on how closely each property’s shape matches their ideal.

The tech stack

For anyone interested in the implementation:

Next.js 16 App Router with TypeScript
Prisma ORM with Neon PostgreSQL
Property dimension values stored as simple integer columns on the property model
Distance calculation runs server-side at query time
Radar charts rendered as SVG; the Index explainer page uses animated SVG with elastic-out easing
Deployed on Vercel

The distance calculation is fast enough to run on every query. With a few hundred properties, there is no need for pre-computation or caching. If the catalogue grows to thousands, pre-computed distance matrices or approximate nearest neighbour search would be the next step.

What I learned

Simple maths solves real problems. Euclidean distance is first-year linear algebra, but applied to a real domain with real trade-offs, it produces results that feel intelligent to the end user.

Six dimensions is a sweet spot. Fewer and you lose meaningful differentiation between properties. More and the radar charts become hard to read and the quiz becomes tedious.

The shape metaphor works. Showing guests a visual shape rather than a list of numbers changes how they think about their trip. They stop comparing prices and start comparing fit.

If you are building any kind of matching or recommendation system, multi-dimensional distance is worth considering before reaching for ML. Sometimes the geometry is enough.

Voyera is live at voyera.com. Built with 7 years of Niseko accommodation experience.

DEV Community: mark m