A listing is a document. A unit is inventory with a state.

It usually surfaces the same way. A unit sold in the morning is still showing 'available' on the launch site in the afternoon, and a fresh enquiry has just landed for an apartment that already has an owner. The sales team reads it as a slip: someone forgot to update the site, and the fix is to be more careful next time. The site, though, did exactly what it was built to do. That apartment's availability lived in a text field a person had to remember to change, and no one changed it. Nothing in the system objected, because nothing in the system knew the unit was sold. No amount of training the team closes that gap. It was decided before launch, in how the system stores a unit.

'Available' is a position in a state machine

Every listings collection has a status field, and that field is the trap. A generic collection can store the word reserved. It has nowhere to put the machine behind the word. A unit occupies one of a small set of states, free, reserved, sold, and a promotional price state, and it moves between them along defined paths. Each move is a transition the system either allows or refuses, and each transition fires rules. Reserving a free unit stamps an owner and starts an expiry clock. Selling a reserved unit closes the hold and drops the apartment out of every available list at once. Letting a reservation lapse returns the unit to free and hands the fee question to the rules. Each of those is a move the system runs, not text a person types after the fact.

The anatomy of a hold

Take the state that looks easiest and is hardest: a hold. On the surface reserved captures it. In practice a reservation is a small contract with a clock on it. Off-plan sales run through a reservation agreement that secures the unit for a set period, and when that period lapses there is a fee question: part of what the buyer paid refunded, part kept against the seller's costs. The exact terms vary by market and developer, so read this as one shape among several rather than a universal rule.

The clock is the part that bites first. With no expiry on the record, a lapsed reservation never returns itself to free, so a unit the buyer walked away from weeks ago still reads as spoken for, and a live enquiry gets turned away from an apartment that is genuinely for sale. A real hold carries four things at once.

The fields a listings collection quietly lacks

Make it physical. Set the hold aside, since the four fields above already carry it, and here is a short, unglamorous list of the rest a pre-sale unit has to hold before it can behave correctly.

Field	What it stores	Why a listing lacks it
status	an enumerated state (free / reserved / sold / promo) with legal transitions	it stores the word, not the transitions
tier	the pricing group the unit sits in, by type, floor, or view	one price field, no group
phase	the release batch the unit belongs to	no way to publish one batch of units at a time
deposit_taken	whether the exchange deposit is in	no state past a single label

None of that is exotic. It is close to the minimum a unit needs.

People usually hit a visible limit first and mistake it for the real problem. A general-purpose collection caps how much structure it can carry, and a unit spends that budget fast. A single unit relates to its building, its phase, its price tier, its active hold, and its buyer, so the collection is out of room on relationships alone, before a single rule behind any of them has been modelled. Teams treat that field limit as the thing to solve, when it was never the real constraint.

This breaks on unit one, not at scale

It is tempting to treat this as a scale problem, something that bites at 250 units or 500 and can be deferred until then. It bites on unit one. The moment a single apartment can be held, sold, priced by tier, and released in a phase, a flat listing is already the wrong shape. Scale only makes an early modelling choice costly to unwind.

The reverse is worth saying plainly, because it is real negative space. If your site lists six units that are simply for sale until they are gone, with no reservations and no phased release, a flat collection is fine and a state machine is overbuilding. The argument here is for inventory that actually changes state, which is most launches above a handful of units.

Vinode's Safa Al Fursan project in Riyadh runs as 528 units, delivered as one 3D scene with a back panel, a website, and an app. A development that size is released in phases by definition, and priced across unit type, floor, and view. Those are modelling requirements. A batch of units going live on a set date has to exist as a group the site can publish as one. A price that moves by phase needs somewhere to hold the tier. A document collection can store the values and still have no structure that says these forty units release next month at this band, which is the exact sentence a launch has to be able to express.

Bind the listing to the record

The move is to change the shape of the data, so the state and the rules behind it finally live in one place. Make the unit record the single source of its own state, and make the public listing a view that reads from that record. When the page renders straight from the record, there is no second document to fall out of step, so the unit changes state in one place and every surface that reads it changes with it. Reserve the apartment in the back panel and the listing, the filter result, and the brochure all reflect it in the same read.

This is the line Vinode's Back Panel draws. Each unit carries an availability status of free, reserved, sold, or promo. Units are organised into buildings and groups. A price change routes through a discount-request workflow with approval limits. Listings, filterable unit lists, and the auto-generated brochure all bind to that live data, so the current price and current availability come straight from that record. The buyer-facing filters, by building, size, floor, orientation, and price range, only work because each of those is a real, queryable field on the unit. For the front end of that model, the unit-selection experience is where the live record meets the buyer.

Choose the model before the tool

Before you build a launch on any collection, settle one question: does a unit carry a state with rules the system enforces, or is it a document with a label a person keeps accurate by hand? Answer it honestly, because the answer decides the architecture, and no amount of picking the right CMS, the right real-estate theme, or a higher plan tier changes it. The decision sits in the data model, upstream of whatever tool you build on.

Plenty of launches genuinely run availability off a shared spreadsheet, and that is a reasonable place to start. It works right up until the sheet and the site hold two different truths, and a buyer walks into the gap between them. The real point is quieter: you have already chosen a model, whether or not you meant to. Choose the one where the site cannot show a sold apartment as available.