Work · Client platform ยท Property auctions

Landmark Auctions

An online property auction platform for The Landmark Partnership: catalogue, legal packs, proxy bidding and deposits, with identity checks timed around the hammer.

Role Architect and builder (Agile Tech Solutions), for The Landmark PartnershipWhen 2025โ€“2026
Landmark Auctions
30 mina bid in the last 30 minutes pushes the finish to at least an hour away, so sniping doesn't work
ยฃ250minimum bid increment; proxy bids need a deposit first
3 rolesadmin, agent and bidder, checked in the browser and again at the API
After the hammereach winner owes identity and anti-money-laundering checks by a set deadline

The problem

Property auction houses have traditionally run on a patchwork: catalogues as PDFs, legal packs sent out on request, bids taken in the room or by phone, deposits chased by hand and identity checks done on paper. Buyers want to see everything online and bid from anywhere, and the auction house still has to meet its anti-money-laundering duties.

The idea

Landmark Auctions puts the whole sale online for The Landmark Partnership, a UK residential and commercial property auction house. Each lot carries the details buyers actually check (guide and reserve price, lot number, tenure, EPC rating, council tax band, viewings, completion dates), its legal pack, and online bidding. Behind it sits a back office where agents manage their own lots and admins run auctions and assign work.

How it's built

The platform is a Node.js and Express API on PostgreSQL, with Redis and a separate headless Chrome container that gathers public property details when a lot is set up. It runs in Docker on Agile Tech's own server behind Cloudflare. Deposits and commission are taken through Stripe payment intents in pounds, so card details never touch the platform.

Access is role-based, with admin, agent and bidder roles checked in the browser and enforced again at the API. Sign-up records GDPR consent, admin actions are written to an audit log, and the API has rate limiting and security headers.

Available properties: current, upcoming, previous and unsold lots, searchable by location, type and price.

Fair bidding

Each bid is written inside a database transaction that also marks the current winning bid, so two people can't both believe they're winning. Bids go up in steps of at least ยฃ250. Proxy bids, where the platform bids for you up to a limit, are only allowed once a deposit is in place. A bid in the last 30 minutes pushes the finish out to at least an hour away, which takes the point out of last-second sniping.

Live auctions: filters for live, upcoming, ending soon and ended sales.

Identity, timed around the hammer

The most interesting decision was when to check who a bidder is. Checking everyone up front puts people off before they've found a property they care about. So registered users can bid, and identity and anti-money-laundering checks become an obligation the moment someone wins: one per lot and winner, with a deadline, tracked until it's met.

Where it doesn't fit (yet)

The catalogue is live, and the online bidding, deposits and post-win checks are built ahead of the first fully online sale. Deferring checks until after a win lowers the barrier to bidding, but a winner who can't pass them means the lot has to be offered again, which is why deposits matter. And a soft close makes busy auctions run longer, which suits sellers more than impatient bidders.

What I took from it

In regulated transactions, identity is a timing decision. Verify everyone up front and nobody bids; verify nobody and the business is exposed. The design is in choosing the exact moment to check, and making sure the obligation can't quietly slip.

Building something that has to be secure by design?
I help teams get identity, secrets and AI access right from day one.
How I work with teams →