Show the project.
Control the details.

Architecture, plans and neighbourhood context communicate the character of a development. Visitors must still find the right building, unit or project type quickly. Distinguish renders from photographs of completed work. Availability should be linked to the property register rather than manually drawn onto an image.

During design, document representative screens and expected user actions. For each decision, identify what editors maintain, what comes from another system and who owns its freshness.

Acceptance check: A first-time mobile visitor can find the relevant service and next step.

The workflow connects these stages: Project and phase → Contractor report → Review open issues → Accept quantity. Each transition has an owner, inputs and a visible result. Before implementation, map the normal journey, correction, cancellation and repeated actions. Interface status must represent a confirmed state rather than a button click.

Acceptance check: Returns and retries preserve input without duplicating the result.

A project contains buildings, units or phases; a construction stage contains work items and supporting evidence. Store planned, reported and accepted quantities separately. Each issue references a task, location and owner. Closing an issue retains its history, and resubmitting a report does not double completed quantities.

Acceptance check: Reference data changes do not overwrite an agreed document.

Buyers see the public catalogue, contractors assigned contract work and the client team submitted reports. Financial details and estimates have separate permissions. The demo blocks acceptance while an issue remains open; actual acceptance authority follows the company’s agreed contracts and procedures.

Acceptance check: A different organisation cannot retrieve a restricted file by direct URL.

Unit status may come from CRM, drawings from an approved repository and work progress from an internal platform. Recheck current property availability on the server when reserving. If synchronisation is delayed, show freshness information rather than promising a unit from an outdated listing.

Acceptance check: An unavailable source never appears as a confirmed success.

For long operations, acknowledge receipt and retain the result identifier. Retrying after a connection loss must not create a second record. Separate user-correctable errors from cases requiring a specialist, preserving input under the agreed handling rules. Design empty, loading, forbidden and unavailable states before implementation rather than after launch.

Acceptance check: A repeated event does not apply an operation twice.

Developers need project, property-type and neighbourhood pages; contractors need expertise and completed work. Control filter-generated duplicates. Preserve valuable project URLs during migration and redirect replacements. The target action follows the business model: consultation, viewing or quotation request.

Acceptance check: Search and filters lead to useful pages without endless duplicates.

The first release covers the complete journey from “Project and phase” to “Accept quantity”, supporting pages and editable fields. Test mobile views, roles, forms, documents and integration failures in staging. Save the previous state and define rollback before switching. Handover includes editor instructions, the exchange design and a checklist for future releases.

Acceptance check: Recovery has been tested on a copy, and editors can maintain fields independently.