A closed project should not look available for another week
When a property status changes, every catalogue card and related interface needs to stop presenting the old state as current.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A status change is not complete when only the main project page changes.
If sales have closed but a catalogue card still says “available”, the user begins with an obsolete promise. Saved lists, comparison views and related modules can create the same mismatch.
When availability changes, that update has to propagate through the project catalogue instead of surviving as stale state somewhere else.
Status deserves a real model
Availability is rarely a simple yes-or-no field. A project might be actively selling, temporarily paused, available only on request, sold out, archived, or awaiting fresh verification.
If the data model collapses all of those conditions into one boolean, the interface has to guess. The most dangerous guess is treating “unknown” as “available” because it produces a cleaner card.
I prefer explicit states with explicit behaviour. Which surfaces should show the project? Which actions remain valid? Should comparison stay available? Does the page need a last-verified date? Those decisions are easier to keep consistent when the state is named instead of inferred.
Propagation is where stale information hides
The edit itself may be correct while surrounding systems lag behind. The project page reads the new value, a cached catalogue still has the old one, search results update on another schedule, and a language edition points at an earlier record.
For that reason I think in dependencies: which components consume this field, which ones cache it, and what event tells them to refresh? If some surfaces are intentionally delayed, the product should not pretend that every status is real-time.
Failure behaviour matters as well. If an upstream source stops responding, retaining a clearly dated last-known state is often safer than falling back to a positive default.
Old projects can still be useful
Closing sales does not automatically make a page worthless. Someone may have bookmarked it, own a unit there, compare historical pricing, or simply want to understand a developer's past work.
An archived page can serve those needs if it makes the condition obvious. The mistake is leaving the old commercial state in place while the page continues to attract users as if the offer were current.
The technical system does not decide the editorial wording. Its job is to make the chosen status behave consistently wherever the project appears.
A good content platform knows how to age information as deliberately as it publishes new information.