Unit Selector Cost: What Drives the Price

Unit selector quotes range more widely than almost anything else in property marketing, because the same three words describe a filterable table and a data-driven building interface wired into a sales system.

Four variables account for most of the spread, and unit count is not the dominant one despite being the number everybody quotes.

Published ranges by deliverable type live on our cost page rather than being restated here, because a figure quoted without its scope is the most misleading thing in this category.

The four real cost drivers

1. Unit type count, not unit count

The variable that scales the visible work.

Two hundred apartments across six types is six plans, six datasets and six presentations. Eighty apartments across twenty two types is nearly four times the production for less than half the inventory.

The building can be large and the project small, or the reverse, which is why quoting a unit count without a type breakdown makes accurate pricing impossible.

How to control it: count types before requesting quotes and supply the list. It is the single most useful thing a developer can send.

2. Integration

The variable that most often turns a deliverable into a project, and the one developers price least accurately.

A static dataset exported once is close to free. A scheduled import from a spreadsheet is modest. A live connection to a CRM or sales platform is a development task with testing, error handling, field mapping and a maintenance relationship afterwards.

If the system of record is proprietary or has no API, it becomes a bespoke connector, which is a different order of cost and one that has to be scoped rather than estimated.

How to control it: establish what the API exposes before choosing anything, and consider whether live data is a requirement or a preference. For many developments a daily refresh is entirely sufficient and dramatically cheaper.

3. Presentation standard

The variable that separates a functional selector from a marketing asset.

Platform default output is included in a subscription and looks like the platform. A selector matched to the development identity, using the project typography, colour and imagery, with considered interaction and layout comparisons, is production work.

For a design-led development that difference is the reason to commission rather than configure. For a straightforward scheme it is spend without return.

How to control it: decide whether the selector is a utility or part of the brand expression, and brief accordingly rather than defaulting to bespoke because it was demonstrated well.

4. Content the selector presents

The cost that is frequently attributed elsewhere and belongs here.

A selector displays plans, renderings, view descriptions and specification. If those exist, the selector is a frame. If they do not, producing them is the majority of the work, and it gets discovered when the build is underway.

How to control it: audit what content exists before scoping. Marketing floor plans per type, at least one rendering per type, and view descriptions by aspect or floor band are the minimum a good selector needs to be worth building.

Why quotes diverge

Normalising those six makes quotes comparable. Without it the cheapest number wins and the difference reappears as unpriced content production or an integration nobody scoped.

The integration line, in more detail

Worth expanding because it is where budgets break and because developers can assess it before talking to anybody.

Full API with unit attributes. Availability, price, area, aspect, floor, plan reference. The selector reads everything from one place and stays correct. Cheapest good outcome.

API with availability only. Status comes from the system and everything else has to be maintained separately, which means a second source of truth for attributes and a reconciliation burden.

Scheduled export. A file produced daily or weekly and consumed by the selector. Simple, robust, and dependent on somebody not forgetting.

Manual entry. The selector has its own data, updated by hand. Works at small scale, fails during a launch, and reintroduces the parallel record problem.

No integration path. Some systems genuinely cannot expose data. That constrains the options and it is better to know before choosing a presentation vendor than afterwards.

Where budgets get wasted

Bespoke presentation on a utility selector. A rental building with a hundred identical units does not need a designed interface.

Live integration where daily would do. Expensive precision on a variable that does not change hourly in most developments.

Building content twice. Plans produced for the brochure and again for the selector because they were commissioned separately.

A selector on unreliable inventory. The most expensive waste in the category, because the spend is incurred and the output is a liability.

Sales gallery version discovered late. Touchscreen requirements differ enough that retrofitting is substantial.

Modelling two states. Cheap to build and it pushes the real picture into a spreadsheet, which costs more than the saving.

What genuinely reduces cost

Fix the unit type schedule first. Every downstream cost scales with it.

Produce the content once. Plans and renderings serve the brochure, the website and the selector. Commission them together.

Question whether live data is needed. Daily refresh is sufficient for most developments and far simpler.

Check the API before choosing anything. It constrains every later decision.

Match presentation to positioning. Bespoke where design differentiates, default where it does not.

Plan the gallery version at the start. If there is one.

How development type changes the number

Rental and multifamily leasing. Cheapest. Few types, availability from the property management system, and a functional interface is appropriate.

Suburban for sale housing. Moderate. More types, plan and elevation compatibility to encode, and inventory that changes at a manageable pace.

Urban condominium. Higher. Many types, view and floor band pricing, and a design standard that platform defaults do not meet.

Luxury or branded residential. Highest. Few units, high type variety, bespoke presentation, and content produced to a standard where the selector is part of the brand experience.

Mixed use. Frequently two selectors sharing a building context, priced closer to the sum than to one.

Ongoing cost

Rarely quoted and material over a sell out.

Availability maintenance if not integrated. Price updates through releases. New unit types if the schedule changes. Content updates as renderings are added or replaced. Platform fees. And the periodic breakage that follows site redesigns and browser changes.

For a development selling over two or three years, the cumulative operating cost frequently approaches the build cost, and pricing only the build understates the commitment by roughly half.

Judging whether a price is reasonable

Is the unit type count stated? If the quote references units rather than types, it was not priced on the variable that scales.

Does it specify the integration? Method, frequency and failure behaviour.

Who produces the plans and imagery? If unstated, that work is coming to you.

What does a change cost after launch? New type, price model change, phase addition.

What a unit selector is worth

Stated honestly. It does not sell units, does not obtain approvals and no vendor obtains approvals or can guarantee them.

What it does is remove the slowest exchange in a pre-construction or leasing sale and let a buyer answer their own questions when they are most engaged. For a development with a long sales cycle and a busy team, that friction removal justifies itself. Measured against a promise of conversion improvement the vendor does not control, every budget in this category disappoints.

The build versus buy calculation

Developers with a pipeline eventually ask whether to own this capability rather than commissioning it per scheme, and the arithmetic is clearer than it looks.

The reusable part is the system: inventory model, states, permissions, integration patterns. That genuinely amortises across projects and is worth owning if you launch several developments a year.

The non reusable part is everything the buyer sees: the plans, the renderings, the building geometry, the identity. That is produced per scheme regardless, because each development is a different building with different marketing.

So the honest answer for a portfolio developer is usually to own the system and commission the presentation, which is the same conclusion the single scheme analysis reaches from the other direction.

Owning both only makes sense at a scale where a permanent internal team is justified, which is a small number of organisations and consistently overestimated by the ones considering it.

Phased spending across a launch

Rather than one budget at launch, the spending that works follows the sales campaign.

Before launch: the system, the integration and the presentation build. The largest single block and the one with a hard deadline.

At launch: nothing, ideally. Anything discovered here is a rush cost and rush costs in this category are steep because the deadline is public.

First quarter: refinements based on how buyers actually use it, which is when the comparison and filtering gaps become obvious.

Ongoing: maintenance, price updates, new types and phase additions.

At each release: a discrete update, priced in advance rather than negotiated under time pressure.

Developments that budget only the first block are surprised four times, and each surprise arrives with less room to absorb it than the last.

What a fair quote looks like

Rather than a number, five things make a quote comparable to another.

It states the unit type count it was priced against. It specifies the integration method, frequency and failure behaviour. It says who produces the plans and imagery the selector displays. It lists the states it will support. And it gives a price for changes after launch, per type, per price model change and per phase.

A quote answering those five can be compared with another answering the same five. Without them, comparing prices is comparing assumptions, and in this category the assumptions differ by considerably more than the prices do.

The sales gallery version

A separate line that arrives late on a substantial number of projects and is consistently underestimated.

A selector built for a website does not transfer to a gallery touchscreen without work. Interaction targets have to be larger, hover states have to go, the layout has to work at a different aspect ratio and viewing distance, and it has to survive being used all day by strangers.

There are also requirements a web build never faces: returning to a home state after inactivity so the next visitor does not inherit a session, working when the connection drops rather than showing an error to a prospect standing in front of it, and letting an agent drive it confidently during a presentation.

Building both from one foundation is a modest addition. Adapting a finished web tool afterwards is close to a second project, and it lands in fit out when the gallery has an opening date.

Comparing against doing nothing

A comparison rarely made and worth making, because the alternative to a selector is not always another selector.

The realistic no-tool baseline is a downloadable price list and plans, with enquiries handled by the sales team. That costs almost nothing, works on every device, and for a small development with an attentive team it performs adequately.

What it costs is sales time answering the same questions repeatedly, and buyer attrition among people who wanted an answer at nine in the evening and did not get one until Tuesday.

Whether that trade favours a tool depends on inventory size, sales cycle length and how much of your buyer traffic arrives outside business hours. For a large development selling to an international audience the answer is obvious. For a twelve unit scheme selling locally it genuinely is not, and being talked out of the honest answer by a good demo is a real risk in this category.

Frequently asked questions

What drives unit selector cost most?

Unit type count rather than unit count, and integration. Two hundred apartments across six types is far less work than eighty across twenty two, and a live connection to a sales system is a development task rather than a configuration.

Is live availability worth the cost?

Frequently not. A daily refresh is sufficient for most developments and dramatically simpler. Live integration is worth it when inventory moves fast enough that a day of lag would create real problems, which is a smaller set than vendors imply.

What cost is most often missed?

The content the selector presents. If marketing plans, renderings and view descriptions do not already exist, producing them is the majority of the work and it gets discovered mid build.

How much does maintenance cost over a sell out?

For a development selling over two or three years the cumulative operating cost frequently approaches the build cost. Pricing only the build understates the commitment by roughly half.

Which development type is most expensive?

Luxury and branded residential, because unit type variety is high, presentation is bespoke and the selector is part of the brand experience. Rental leasing is cheapest, with few types and a functional interface being appropriate.