Our product doesn't use AI. That was a decision, not an omission.

This project had an obvious place to put a model. That is exactly where we decided not to put one.

TrovaStorage is the self-storage marketplace we are building. During its pilot, back when it was still called Metroquadro, it asked operators to list their facility unit by unit, so people looking for space could see the real inside of the building instead of the usual photo of the front door. The operator’s first job, though, was also the most tedious one: before renting anything, they had to draw the floor plan, meaning the outline of the building, the corridors and the units they wanted to carve out of it.

It was the perfect spot for an impressive demo. You upload the dimensions, type “draft me the best possible layout”, and a few seconds later something plausible appears on screen. In 2026 nobody even asks how it works anymore. We chose not to do it.

What we put there instead of a model

In its place there is an algorithm that lays units out in rows. It is deterministic, it is a few dozen lines of Python and it makes no network calls. The comment at the top of the code is quite candid about what it is meant to be and, more importantly, what it isn’t:

“A starting point the seller then edits, not an optimiser. No randomness: same input always yields the same layout.”

You enter the footprint, the corridor width and the unit mix you want, and the units are placed in rows in the order you asked for them. Whatever doesn’t fit doesn’t quietly disappear. It comes back as an explicit list grouped by size (three six-square-metre units don’t fit). That isn’t an edge case handled gracefully; it is half the value of the feature.

It isn’t a clever algorithm, we admit. But the problem wasn’t asking for cleverness. It was asking for predictability.

Why that was the wrong place

There are three reasons, and all of them are duller than the idea of a language model drawing warehouses.

The draft exists to be edited. The operator gets it and starts working on it straight away: dragging, rotating, moving the pillar to where it actually stands, widening the corridor because a forklift needs to get through. If regenerating it gave a different result every time, the draft would stop being a starting point. It would become an oracle, something you consult rather than something you build on. In a setting like this, reproducibility isn’t a technical nicety. It is what makes the tool usable at all.

The result has to be explained to whoever pays the rent. Sooner or later someone will ask the operator: “Why do six units fit in this corridor and not seven?” The answer has to be a rule, such as the width, the tolerance or the minimum clearance to keep free. It can’t be an embarrassed “the system suggested it”.

In this business, mistakes are geometric and final. A unit overlapping a pillar isn’t a slightly worse answer than the others. It is a square metre that doesn’t exist, rented to someone holding a contract. No confidence threshold makes that acceptable.

The criterion, stripped to the bone

AI earns its keep where the input varies a lot and mistakes are cheap. An assistant that rewrites a listing description is the perfect example: you can feed it any text and, at worst, a mistake costs you a second read. The same goes for a system that pulls data out of documents that all look different.

Here it is the other way round. The input is three numbers and a list (metres, corridor width, unit mix): nothing ambiguous, no free text, nothing to interpret. And as we have seen, a mistake costs a contract.

The layout optimiser is still on the list of post-MVP ideas in our product document, with a note that works as a general rule: a constraint solver first, machine learning only if it is really justified. Leaving the door open isn’t the same as having walked through it.

Where we did put the constraints

In this product, certainty doesn’t come from model horsepower. It comes from constraints, as long as they sit where nobody can get around them.

The two geometric rules are simple: no unit overlapping another, and nothing sticking out of the footprint. They are enforced both in the browser and on the server. The browser check is a courtesy to whoever is drawing; the server check is the one that counts.

In the same way, double bookings are impossible because the database says so, not because the code is being careful. An exclusion constraint in Postgres rejects two overlapping bookings on the same unit, whatever the application does and however many requests arrive at once. If two customers click at the same instant, one of them gets a handled error with a clear message. Two contracts on the same unit simply can’t exist.

The part people usually leave out

This story has an ending at our own expense, and it happened right here on this site.

The chatbot that answers questions on the site is a RAG system. Asked about TrovaStorage, it cheerfully explained that the product offers “an editor with intelligent constraints”. Yet the knowledge card we had written for it said in black and white that there is no AI component anywhere in the product.

The model wasn’t to blame. The way we had split the text was: into fixed-length chunks that ignored the sections. The clarification sat at the bottom of the card, so it ended up in the second chunk. For a question about the editor, semantic search returned only the first one. The model got the claim without the limit that came with it, and filled the gap with the handiest adjective it could find.

The fix was editorial, not architectural: we moved the clarification into the same chunk as the claim it refers to.

We have kept one principle from that day: a model doesn’t know what we didn’t give it, and that gap won’t stay empty. It gets filled with something plausible, often the very word we wanted to avoid.

Where we are

The pilot is over and TrovaStorage is live at trovastorage.it. It is the independent directory of self-storage centres in Italy, free for people searching, where each operator manages their centre’s listing and receives the enquiries.

The pilot features this article talks about (floor plan, isometric view, booking) are not active today. The criterion that guided us, on the other hand, hasn’t changed. You can see how TrovaStorage works today on the product page.

Got a problem and not sure a model is the answer? Get in touch. Sometimes the honest answer is no, and it is still worth talking it through.