This is a look at how I built a UK property marketplace, and the reasoning behind some of the technical choices along the way. It is written as a build story rather than a sales pitch — mostly because the decisions are more useful than the conclusions.
The starting question was simple: if performance, automation, and content quality were treated as requirements from the beginning, what would the platform look like? The answer became a full property marketplace written in Rust, and the sections below walk through the parts I found most interesting to design.
The Three Audiences a Property Platform Serves
A property platform has three groups of people to consider, and they value different things.
Buyers and tenants want relevance: they describe a home in their own words and expect the search to understand them. Agents want to publish and manage stock quickly. And whoever operates the platform needs quality control that does not require adding staff every time listing volume grows.
Keeping all three in the same architecture — fast public pages, low-friction publishing, and automated quality control — was the constraint that shaped most of what followed.
Why I Chose Rust
Rust is not the most common choice for a web marketplace, so it is worth explaining the reasoning rather than presenting it as obvious.
I wanted the platform to run efficiently, respond quickly, and stay stable over time. Rust fit those priorities well, and here is what it changed in practice.
- Server-side rendering by default. Listing pages reach the browser as content rather than as an empty shell that fills in later, which helps most on slower mobile connections.
- Efficient resource use. The compiled application runs comfortably on modest hardware, which keeps infrastructure requirements predictable as usage grows.
- Compile-time safety. A strict compiler catches a whole category of issues before deployment, so production debugging tends to be about logic and configuration rather than memory faults.
- A single deployable binary. The web server, business logic, and UI compile together, so there is no separate runtime to install or version-match on the server.
These are practical properties rather than abstract ones. They are the reason operating cost stays tied to actual usage rather than to compensating for the stack.
Building Moderation Into the Publishing Flow
Content quality was the first thing I wanted to get right, because it tends to become harder exactly as a platform grows.
The approach was to make moderation part of publishing rather than a separate step afterwards. When a listing is submitted for approval, an AI review runs first. It looks at whether the submission reads like a genuine UK property advert, whether the description is consistent with the offer, and whether it contains spam, scam patterns, offensive content, or material that does not belong on a property site.
Listings that pass can go live quickly, with the publisher notified. Listings that do not pass receive a clear reason. Cases that are genuinely ambiguous are flagged for a human reviewer rather than rejected automatically.
That last decision was intentional. Automated review works well for clear cases, but human judgement is still the right tool for the uncertain ones. The aim was to reserve human time for the cases that actually need it.
Search Based on Meaning
Search was the part I enjoyed designing most, because property search has a specific difficulty: people and agents often describe the same home in different words.
To handle that, search works on meaning rather than exact text. Every approved listing is converted into a vector representation using an embedding model, stored in PostgreSQL with pgvector, and matched by similarity.
In practice, a query like “quiet home near good schools” can surface relevant properties even when those exact words are not in the title, and results are ranked by how close they are in meaning. A relevance threshold keeps loosely related results from padding out the page.
I also kept a fallback chain, because search needs to keep working even when an external service is temporarily unavailable. If embedding generation fails, the system falls back to text matching, and then to browsing — so a user always receives results.
From Similar Properties Toward Recommendations
Once search understood meaning, a further step became possible. Search helps when someone already knows what to ask for; recommendations help with the next question — what else might be worth looking at.
The foundation for that already exists. Because every listing has a vector representation, the platform can measure genuine similarity between properties rather than relying on category or postcode alone. That is what powers comparable properties on a listing page: someone viewing a two-bedroom flat can be shown homes that are actually similar in meaning, specification, and location context.
Relevant behavioural signals are also collected as part of normal use:
- which listings people view, and how often;
- which properties are saved as favourites;
- which searches users save and repeat, including filters and locations;
- what people type into search, kept as anonymised analytics.
The planned next step is a personalised layer on top: a feed that learns implicit preferences — price range, area, size, property type, and the signals within descriptions — and ranks new inventory accordingly, with alerts prioritised by relevance rather than sent exhaustively.
To be precise, since it matters if someone asks for a demo: the similarity engine and the behavioural data exist today, while the personalised recommendation layer is the next step rather than a shipped feature. It is an incremental machine learning layer built on infrastructure that already works.
Bulk Import With BLM
One lesson stood out during development: for an agency, the deciding feature is often import, not intelligence.
UK agencies already exchange listing data using the BLM format. If moving to a new platform means re-entering every property by hand, adoption rarely happens. So the platform supports BLM import and export, including handling for Property Hive-style feeds where formats differ in ways that can trip up a naive parser.
An agency uploads a feed and listings are created or updated automatically. Photos referenced in the feed are fetched, validated, optimised, and moved to the CDN without manual work. Duplicate detection means re-importing an updated feed does not clone the whole portfolio.
One detail proved important: available credits are checked before an import begins rather than partway through, so an import does not stop unexpectedly after processing part of a file.
Presenting Property, Not Only Listing It
Agents present as much as they publish, which led to portfolios: curated collections of properties behind a single shareable link. A letting agent can send a shortlist to a client, a developer can showcase a site, and a landlord can share available units with an agency.
Public portfolios are indexable and built for reach. Unlisted ones stay out of search engines while remaining reachable by direct link, which suits a private shortlist. Their external identifiers are generated randomly rather than sequentially, so the URLs cannot be guessed by incrementing a number.
Maps follow the same idea. Listings with valid UK postcodes appear geographically, clustered at wide zoom so dense areas stay readable and expanding into individual pins as you zoom in. Agents can position a pin precisely when publishing, and the maps use open tile providers so map usage does not scale in cost with traffic.
Verification and Account Security
Property listings involve money, contact details, and identity, so verification runs throughout the flow.
Email is confirmed with a one-time code at registration, and Google sign-in is available where configured. Passwords are hashed, sessions are signed, logging out on one device invalidates the others, and authentication routes are rate limited.
Phone verification was a particularly interesting piece. Mobile numbers verify by SMS, but many UK agencies operate on landlines, which cannot receive text messages. Rather than treating those numbers as invalid, the platform adds a voice-based verification path for UK fixed lines, with a controlled manual-review fallback for cases where an automated call cannot complete. It handles a group of users the platform is specifically meant to serve.
Operating the Platform
Operations turned out to be a larger part of the work than I first expected, because running a platform means answering practical questions quickly.
To support that, the admin side became a real control plane: moderation queues, user management, contact messages, searchable application error logs, search analytics, rate-limit monitoring, feature flags, and manual maintenance commands. Nightly jobs handle cleanup and send a summary report, so routine maintenance happens on its own and leaves a record.
None of this is visible to a visitor, but it is what makes the platform maintainable over time.
Portable Deployment With Docker
The platform ships as containers: the application, PostgreSQL with PostGIS and pgvector, and Caddy in front handling HTTPS certificates automatically.
The goal was portable, predictable deployment. Running behind a reverse proxy also brings details worth getting right — for example, making sure the application reads the genuine visitor IP address rather than the proxy address, so rate limiting applies per visitor as intended. Those are the kinds of details that surface once something runs in production.
Custom Build vs Template
A template can be a good fit for a straightforward site with a small number of properties, and it is worth saying so plainly.
The trade-offs shift as requirements accumulate: AI moderation, semantic search, industry feed import, company teams with roles, credit accounting, shareable portfolios, and operational tooling. When those need to work together in one system, a custom build lets the product follow the business model rather than adapt around a set of separate components. That flexibility was the reason to build this from the ground up.
Who This Is For
Agencies and property businesses: a platform built around UK workflows, where publishing is quick, feeds import cleanly, and stock is presented properly to clients.
Founders and product owners: a reference for how a proptech build can be structured when performance, automation, and operations are considered from the start.
Investors: a product with distinct components — automated content quality, semantic discovery, industry-standard import, and efficient infrastructure — with a clear direction for further machine learning work.
If You Are Building Something Similar
If you are considering a property marketplace, a white-label listing product, or a platform where automation and content quality affect whether it scales, I am happy to discuss it.
What I have described here is built to be operated: fast public pages, search based on meaning, automated moderation with human oversight, portable deployment, and the tooling needed to run it day to day.
Describe what you are trying to build, and I can share an honest view on whether a custom platform fits — or whether a simpler option would serve you better.