NovPrice sorting needs a rule for properties with no confirmed price
A property with no confirmed price cannot honestly be treated as cheapest or most expensive, so sorting and budget filters need an explicit policy for unknown values.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
Sorting by price looks objective because numbers have an obvious order. Property catalogues are less tidy than that. Some records have a confirmed asking price. Some only have a project-level “from” figure. Some say “price on request.” Others genuinely have no current price confirmed at all.
The moment those states enter one list, “sort low to high” stops being a pure arithmetic instruction. The product has to decide what to do with records that are not numerically comparable.
Unknown price is not the lowest price
The most damaging shortcut is to convert missing price to zero. The mathematics then works perfectly and the product becomes misleading. Properties with no known price rise to the top of an ascending list as though they were the cheapest options available.
A buyer may reasonably interpret the first cards as the best fit for a limited budget. The system has silently turned missing information into a commercial advantage.
Putting unknown prices at the bottom is usually safer, but even that needs care. Bottom position must not imply “most expensive.” It only means those records could not participate in the numeric order. A small label or separate group can make that distinction clear.
There is no single layout that every catalogue must use. The non-negotiable part is semantic honesty: an unknown value should not be presented as though its relative price were known.
Budget filters make a stronger claim than sorting
Sorting asks for an order among available values. A filter such as “under THB 5 million” makes a stronger statement: these properties meet the chosen threshold.
A property with no confirmed price cannot be proven to meet that condition. Including it automatically inside the filtered result would treat uncertainty as a positive match.
That does not mean the property must disappear completely. A catalogue can offer an option such as “also show properties with unconfirmed price,” or place them in a clearly separate section. The buyer then sees that these additional options still require a price check.
The opposite mistake is possible too. A “price on request” property is not automatically premium. Lack of a published figure should not be turned into a status signal. Unknown remains unknown in both directions.
A project-level ‘from’ price is not always a unit price
Another difficult case is partial information. The project has a published starting figure, but the specific unit being viewed does not have a confirmed current amount.
If the catalogue card represents the project itself, a clearly labelled “from” price can be useful. If the card represents a specific apartment, using the project minimum as though it belonged to that unit creates a different claim.
This is why the data model needs more than a numeric field. The product should know what kind of number it has: confirmed unit price, project starting price, historical value, estimate or no confirmed current price. A sorting algorithm cannot produce an honest result if semantically different numbers are flattened into the same category.
The visible label matters as much as the technical distinction. Buyers should not need to reverse-engineer whether the number belongs to the unit, the phase or the entire development.
Suppose an unpriced record sits in the “price to confirm” group. The team later receives a confirmed amount. The property can now enter the numeric sequence at the appropriate position. That movement is a normal consequence of better data.
What should not happen is random movement caused by data conversion. A record appears first because blank became zero, then drops to the bottom after a fix, then moves again after the next import. To the buyer, the catalogue may look unstable even though the market did not change at all.
Testing therefore needs incomplete states, not only perfect demo data. A robust sort should be exercised with confirmed values, missing values, newly confirmed values and records whose price is temporarily unavailable. These are normal catalogue conditions.
The same tests should cover both ascending and descending order. A missing value should not suddenly become “highest price” simply because the direction changes.
Honest ordering makes the limits of the catalogue visible
NovAsia’s live Thailand catalogue already contains records where the price is shown as on request or not specified. That is not a defect by itself. It can be more responsible to show that the price is not confirmed than to invent a figure.
The product responsibility begins with what happens next. Confirmed amounts should sort as real numbers. Unconfirmed records should not impersonate zero. Budget filters should not claim that an unknown price satisfies a threshold. The interface should explain why some cards sit outside the numeric order.
For me, that is a better catalogue than one that looks perfectly sorted only because missing information has been forced into a number. A buyer can work with an explicit unknown. They cannot make a sound comparison when the product hides the unknown inside arithmetic.
Price sorting is a small control with a large effect on what appears first. When the dataset is incomplete, the honest answer is not to pretend the gaps have a position. It is to define a clear rule for them and let the user see that rule in the result.
Sources
- NovAsia — Thailand property projects catalogue: includes records presented with “price on request” / unspecified price states, demonstrating the practical need to handle non-numeric price states explicitly. Accessed 6 October 2026.
- NovAsia — Alexander Elshin expert profile: describes technical responsibility for catalogue behaviour, data consistency, forms and user state. Accessed 6 October 2026.