When not to use AI: our matchmaker without a language model

We use AI almost everywhere: in the CRM, for photos, for articles, for sorting email. That's exactly why, when we built the tool on our website that suggests homes to buyers, we decided not to use it. This piece explains how the tool works and why.

What it does

Instead of the usual filters (area, price, square metres, number of rooms), the page asks five questions:

1. the sea, the Karst plateau, or both depending on the day;
2. where you have breakfast: on a terrace, in a garden, in front of a big window;
3. how much space: compact, family-sized, no compromises;
4. what pace: the city on your doorstep, or silence;
5. your budget, in bands.

Sixty seconds, and the real catalogue answers with three homes, each with a sentence explaining why it was chosen.

It looked like the perfect job for a language model. Send it the answers and the catalogue, ask "what are the three best homes and why?". We chose not to.

Why no LLM

A model can invent a terrace. That's the main reason. A sentence like "breakfast gets its own terrace", written by a model, may or may not be true depending on how it read a four-page description. In our matchmaker that sentence can only appear if the home's structured "terrace" field is switched on. The site cannot claim a feature the home doesn't have.

Every point has to trace back to an answer. Someone shown three homes has a right to understand why. With transparent scoring the explanation isn't reconstructed after the fact. It is the calculation.

It must always give the same result. Same answers, same homes, same order. That makes the tool checkable and fixable: if a home shows up where it shouldn't, you can find the line that put it there.

No server needed. The catalogue reaches the page in slimmed-down form, with only the fields that matter and none of the long descriptions. The calculation runs in the browser. The answers stay in the visitor's own browser. Anyone who comes back finds their result again, and we receive nothing unless the person asks us to get in touch.

How the scoring works

Each answer gives every home some points, and the contributions add up.

• Location weighs most. A seafront area scores high, and a home right on the water or with a sea view adds more, up to a cap. Choosing "both" rewards the border, the stretch of coast where the plateau drops into the sea.
• Breakfast looks at a single field per answer: terrace, garden or, for the big window, a sea view.
• Space uses three floor-area bands with a soft edge. A home just outside its band, within 15%, gets half the points. That's not a rejection, it's a door left ajar.
• Pace scores areas by how close they are to the city or to quiet.
• Budget is the only answer that can exclude a home. Inside the band, full marks. Below it, almost full: that's a pleasant surprise, not a flaw. Up to 15% above the ceiling, a few points, because that's room to negotiate. Beyond that, the home drops out.

Two details we like. Homes whose price is available on request only stay in the running with a neutral contribution, but their price is never shown or used openly. And on equal points, the home that answers more of the questions wins: four out of five beats a landslide on two.

The "why" sentence

Under each home there's one sentence, and no model writes it. The code takes that home's two strongest contributions and stitches together two hand-written fragments, one for each combination of question and answer, in the site's three languages. No machine translation. If a contribution is zero, its fragment stays out.

To avoid repeating the same sentence on all three homes, the second and third prefer to talk about dimensions the first hasn't covered. They still draw only from their own positive contributions. If a home has no positive contribution at all, the sentence admits it: it's a wild card from the catalogue.

Below the sentence, green ticks show which questions the home actually answers.

The limits, stated

Plain code has different limits from AI. It isn't limitless.

• It depends on the data. If a home has a terrace but the field isn't set, the matchmaker won't see it. The error is honest and traceable, though: you fix the data rather than question a model.
• Some answers are approximations. "A big window" isn't a field in our catalogue. The nearest structured signal is a sea view, and the code says so: a window counts if it frames something.
• The weights are our choices. That location matters more than pace is an editorial judgement, not a statistical truth. At least it's written down, readable, and changeable in one place.

When code beats AI

This project gave us a working rule. We prefer plain code when:

• the output makes factual claims about a home, a contract or a price, and a mistake is worse than a sparse result;
• the signals that matter are already structured: if the data exists as a field, reading it is more reliable than having it inferred;
• the result needs explaining, to the person receiving it, or to ourselves when something doesn't add up;
• the same question must always get the same answer;
• volumes are small: on an agency-sized catalogue, a hand-built score is more than enough.

We need AI where the input is free, messy language: an email to classify, a phone call to summarise, a text to write from given facts. No table of weights holds up there. But five multiple-choice answers aren't free language. They're data, and data is handled with code.