How to Choose a Unit Selector Company (2026)

Quick answer: Diagnose before you shortlist. If nobody can say with certainty what is available right now, you have an inventory problem and a selector will publish it. If inventory is sound and the public display looks like a database, you have a presentation problem. The shortlists for those two are almost entirely different.

Unit selector selections go wrong in a way that is easy to diagnose afterwards and easy to avoid beforehand.

A developer with unreliable inventory buys a beautiful selector and publishes the unreliability. A developer with sound inventory buys another inventory platform and still has a public display that looks like a spreadsheet. Both spent money on the half they already had.

This is a framework rather than a ranking, and the first step is a diagnosis.

How this list was put together

Options are organized by which problem they solve. Inventory platforms and presentation production are deliberately listed together because they are routinely compared as one purchase.

Criterion	What we looked for
Problem	Inventory integrity or buyer-facing presentation.
Team size	Whether a system needs permissions and audit.
Sales complexity	Releases, holds, brokers, preview allocations.
Design sensitivity	Whether a platform default display is acceptable.
Integration	Whether the two layers have to connect.

Editorial note: Rendimension publishes this guide and appears on it. We place a platform first because a system of record and a presentation layer are not substitutes, and we list ourselves in the specific niche we serve rather than at the top. Every other entry is an independent company we do not control, identified through public research.

1. Zoho CRM

Before choosing a vendor, establish whether you have an inventory problem or a presentation problem, because the two lead to entirely different shortlists.

Zoho heads this list as the baseline system of record for teams with configuration capability. If inventory truth is currently a spreadsheet, fixing that comes before any selector conversation, and this is frequently the cheapest way to fix it.

Move to a specialised platform when release management, hold expiry and contract stages need to work without being designed by you.

2. Rendimension

We list ourselves second and in a specific niche rather than as a general recommendation, because the right answer depends on which half of the problem you have.

We fit when inventory truth already exists in a system and the buyer-facing layer needs to match a marketing programme rather than a platform default, and when the selector has to present plans, views and layout comparisons that are being produced anyway.

We are the wrong choice when the underlying problem is that nobody knows what is actually available, because a produced presentation layer over unreliable inventory publishes the unreliability more attractively.

Boundaries: we produce the visuals and buyer-facing tools used in sales presentations. We do not raise capital, we do not obtain approvals and we do not guarantee them, and we do not sell units or operate a sales CRM.

3. MRI Software

Consider when the sales operation is large enough that inheriting real estate conventions is worth more than configuring your own, and when release phases and contract stages need to work natively.

4. Sell.do

Consider when pricing complexity is the binding constraint: escalation through releases, bands by floor and view, and incentives that change quarterly.

5. Property xRM

Consider when your sales team works with more states than available and sold, which is most teams, and you want the system to match rather than force a workaround.

6. RE.Platform

Consider for long sell outs where releases, pricing and delivery dates all change during the project and history matters for reporting.

7. YourNextHome

Consider for mid sized residential developments that need structure without enterprise overhead.

8. Blindersoe

Consider when consolidation is genuinely worth more than best of breed, accepting that the weakest component in a bundle cannot be replaced independently.

Step one: diagnose

Two questions, answered honestly, determine everything that follows.

Can somebody tell you right now, with certainty, which units are available? If the answer requires checking with an agent, or if there is a spreadsheet involved, you have an inventory problem. Fix that first, because a selector on top of it makes the problem public.

Does the current public display look like it belongs to your marketing? If it is a platform default sitting inside a carefully designed site, you have a presentation problem, and buying another inventory system will not touch it.

Many developments have both, in which case the sequence matters: inventory first, presentation second, because a presentation layer built on shifting data has to be rebuilt when the data is fixed.

Step two: map your states

The most useful preparation available and it takes an afternoon.

Write down every state a unit can be in as your team actually uses them. Available, verbally held, held with deposit, reserved with expiry, contracted, exchanged, completed, released, unreleased, broker allocation, preview allocation, withdrawn.

Then check candidate systems against that list rather than against their feature pages. Any state your team uses that the system cannot represent will end up in a spreadsheet, and that spreadsheet is where errors originate.

This exercise also frequently reveals that the team disagrees about what a state means, which is worth discovering before a system encodes one interpretation.

Step three: the questions that separate vendors

Show me a reservation expiring. Not described, demonstrated. It is the state most commonly unhandled.

What does the API expose? Availability alone or full unit attributes. This determines whether a produced presentation layer is possible.

How do broker allocations stay off the public view? Audience-aware views or manual discipline, and the second fails under launch pressure.

What happens when the connection fails? Stale with a timestamp, fallback to enquiry, or confidently wrong data.

Who can change availability and is it logged? Permissions and audit separate a system of record from a shared file.

Can I see the public display on a real project? Live, on a phone, from a development that launched a while ago.

Terms worth reading before price

Data export. Your unit schedule, states and history should be portable. Inventory data has a long life and outlives vendors.

Subscription dependency for public display. If the buyer-facing element stops when a subscription lapses, that is a live sales site failure rather than an administrative one.

Integration ownership. Who maintains the connection when either side updates.

Change pricing. New unit types, new phases, price model changes. These accumulate across a sell out.

Red flags

No answer on reservation expiry. Suggests the sales process was never modelled properly.

A demo where availability is obviously static. Ask them to change a unit state and refresh.

No API discussion. Means the presentation layer will be theirs forever.

Claims about conversion. Selectors remove friction. They do not sell units, and no vendor obtains approvals or can guarantee outcomes.

Everything bundled with no component pricing. Makes it impossible to tell what you are actually paying for and hard to replace a weak part later.

When not to commission yet

If inventory truth is unresolved, wait on the selector and fix the system. This is the single most common sequencing error in the category, and it is expensive in both directions: the selector gets rebuilt when the data model changes, and in the meantime it publishes errors that damage trust with buyers who noticed.

If the unit schedule is still moving, wait on the presentation layer specifically. Every unit type is a plan, a dataset and a presentation, and adding a type after the design is set touches all three.

The work that can proceed in the meantime is the content: marketing floor plans, unit type renderings, view descriptions. Those are needed regardless of which system wins and they are the long lead items.

Matching the answer to the situation

Five situations cover almost every case.

Small development, simple inventory, no team. A spreadsheet is genuinely adequate and a selector can read from a periodic export. Do not overbuy.

Mid sized development, sales team, phased releases. A purpose built platform, adopted properly, with a produced presentation layer if the scheme competes on design.

Design-led development with existing systems. Keep the system, produce the presentation layer, wire them together.

Portfolio developer. One system across projects, with presentation produced per scheme so each development can carry its own identity.

Leasing operator. The property management platform is the system of record. The selector reads from it, and building a second inventory record is the mistake to avoid.

Running the engagement well

Four things improve the outcome and all sit with the client.

Resolve the state model before procurement. It is the specification, and doing it late means retrofitting.

Name the data owner in writing. Not an assumption that sales will handle it.

Test with a state change, not a demo. Change a unit, refresh the public view, see how long it takes and what it looks like.

Decide the failure behaviour explicitly. What the public sees when the connection breaks, because it will at some point and preferably not during launch week.

The single filter if you apply only one

Ask any vendor to show you a live selector from a development that launched a year or more ago, then check whether the availability looks plausible for a project of that age.

A building that launched eighteen months ago showing almost everything still available is either not selling or not being updated, and the vendor should be able to tell you which. A vendor who cannot show a live example at all is telling you something too.

The answer is diagnostic regardless of what it is, because it reveals whether the vendor designs for the life of a sales campaign or only for its launch.

One boundary worth stating

Unit selectors support a sales process by removing its slowest exchange. They do not sell units, they do not obtain approvals and no vendor obtains approvals or can guarantee them, and they do not replace a sales team or a system of record.

The friction removal is real and worth paying for. A buyer who can see what exists, what is available and roughly what it costs without waiting for a callback has been served, and the conversation that follows starts further along.

What no selector does is make disorganised inventory reliable. Held to the friction standard the spend justifies itself easily. Held to a promise of fixing a sales operation, it disappoints, and vendors who imply otherwise are selling something outside their control.

The same caution applies to the presentation side. A well produced selector makes a building legible to somebody who has never stood in it, which on a development sold years before completion is genuinely valuable. It does not make an ordinary building desirable, and treating it as a substitute for the product rather than a window onto it is how expectations get set that no interface can meet.

Frequently asked questions

How do I know if I have an inventory or presentation problem?

Ask whether somebody can say right now with certainty which units are available. If that requires checking with an agent or consulting a spreadsheet, it is an inventory problem. If inventory is sound but the public display looks like a database, it is presentation.

What preparation is most useful before choosing?

Write down every state a unit can be in as your team actually uses them, including informal holds. Then check systems against that list rather than feature pages. Any state the system cannot represent ends up in a spreadsheet.

What should I ask a vendor to demonstrate?

A reservation expiring, live rather than described, since it is the most commonly unhandled state. Also ask them to change a unit state and refresh the public view, and to show a live selector from a development that launched a while ago.

Why does the API matter?

Because it determines whether a produced presentation layer is possible later. An API exposing only availability forces a second source of truth for orientation, view, area and plan references, which reintroduces the problem you were solving.

When should a selector not be commissioned yet?

While inventory truth is unresolved, because the selector will publish the errors and get rebuilt when the data model changes. Content like marketing plans and unit renderings can proceed meanwhile, since they are needed regardless of which system wins.