Answer the buyer's questions before showing every feature.
A development website is not an architecture competition presentation. The architectural idea matters, but visitors also need practical information to judge whether a home is relevant to them. Start by writing down the questions that a buyer, an investor and an agent are likely to ask.
Which neighbourhood is it in? Is the project a proposal, under construction or complete? What types of homes are planned? Is an apartment actually available? Where can someone request verified details? Each important question should have an identifiable answer, even when the answer is simply that information has not yet been released.
On a phone, can someone identify the project, its approximate location, its current stage and the next useful action without scrolling through a long cinematic introduction? If not, the information hierarchy probably needs work before the animation does.
Keep the navigation proportional to the development.
A small project may only need a strong landing page plus a homes overview and contact section. A larger project with many buildings or unit types will benefit from separate, directly accessible pages. The architecture of the website should reflect the amount of real information available rather than a standard marketing template.
| Content area | What it should answer | Useful material |
|---|---|---|
| Project overview | What is being built, and at what stage? | Clear introduction, key image, verified status |
| Architecture | What makes the spaces and building distinctive? | Design explanation, exterior and interior views |
| Homes | Which types of units are planned or offered? | Plans, areas and availability, when confirmed |
| Location | Where is it and what surrounds it? | Accurate map, context and useful local information |
| Enquiry | How can I ask about a particular home? | Simple form, contact details and a clear next step |
Keep the labels familiar. “Homes”, “Location” and “Contact” are often more useful than abstract names that require a visitor to discover what is behind each link. If a page has no substantial content yet, it may not need its own menu item.
Use each visual to answer a different spatial question.
One exterior rendering can establish the identity of a development, but it rarely explains everything a buyer needs. Use a deliberate sequence: an overall view to introduce the project, a street-level or site view for context, a relevant interior for spatial character and a readable plan to explain layout.
Do not make five nearly identical camera angles do the work of one plan. If the project is unbuilt, clearly describe the images as architectural visualisations. Avoid implying that proposed finishes, planting, furnishings or views have already been delivered. Any qualifications should be easy to find near the material they explain.
Keep drawings legible on mobile.
A unit plan must communicate doors, rooms and circulation without forcing a buyer to decipher tiny labels. Prepare simplified exports where necessary, preserve a larger view for detailed reading, and provide the relevant room or area information in accessible text. A plan should not be the sole place where essential facts are hidden.
When possible, retain the intended aspect ratio on the detailed project page. A wide exterior or portrait interior need not be squeezed into the same crop as every other asset. Optimise responsive image sizes so smaller devices are not forced to load the full desktop master.
Separate confirmed unit information from presentation concepts.
The homes overview is where visitors expect precise and current information. Keep each unit identifiable with a consistent reference or number, a floor or location in the building, a plan and the data that has been verified for publication.
The example shows fields, not a factual offer. Do not publish invented unit sizes, prices, completion dates or availability just to make a design mock-up look finished.
What happens when availability changes?
Decide who owns the source of truth before launch. If availability is edited manually, give the team a simple, documented update process and visible responsibility. If it comes from an external sales system, define the integration and what happens if that source stops updating.
Never show a unit as currently available solely because its website card has not been edited. If information cannot be maintained reliably, a clear “Enquire for current availability” message is more defensible than an outdated badge.
If the development needs a clickable floorplate or 3D apartment selector, the guide to interactive floor plans on development websites explains when that extra interface is useful, how it connects to unit records and why a readable list and reliable status updates still matter.
Show the location accurately, not just attractively.
An attractive aerial image is useful, but it may not tell visitors how the building relates to streets, public transport or surrounding amenities. Pair location imagery with a usable map or an accessible address when publishing it is appropriate. For projects whose precise location is not yet public, state the area honestly rather than inventing a pinpoint.
Use verified descriptions of nearby services or transport, and distinguish current facilities from future plans. Do not promise walking times, connections, views or amenities that have not been checked. A good location section builds understanding without needing a map covered in decorative icons.
Make the next action specific to the visitor's interest.
A generic “Contact us” link can work, but a project website often benefits from more context. If a visitor is looking at unit A-203, the enquiry should retain that reference. They should not need to copy it manually into a blank form.
Ask only for information needed to respond, such as name, contact details and a short message. Explain what will happen after submission. Confirm that the form actually sends the enquiry to the intended recipient, and test error and success states on mobile.
Not every visitor is ready to select a unit. Offer a path for a general project enquiry as well. Keep contact details findable without requiring the visitor to finish a presentation or scroll through the entire page first.
A pre-launch checklist for content and technical delivery.
- Project name, location and development status are accurate and consistent across pages.
- Renderings are identified as visualisations, with qualifications where appropriate.
- Each selected image adds context; important subjects survive responsive cropping.
- Plans are readable, and essential unit facts are available in HTML text.
- Prices, floor areas, completion dates and unit availability appear only when verified and approved.
- The source of truth and update responsibility for availability are documented.
- Location claims and map markers match what can be supported.
- Enquiry forms preserve the relevant project or unit reference and have been tested.
- All public pages have appropriate titles, main headings, canonical URLs and internal links.
- Image publication rights, required credits and applicable legal information are checked by the responsible parties.
After deployment, test the live production URL, not just a preview. Confirm that forms still work in that environment, that image assets load and that pages are not accidentally marked noindex. A correct sitemap helps discovery but does not guarantee that search engines will index the pages.
Before approving the website, decide who will maintain it after launch. A beautiful project presentation becomes unreliable quickly if no one updates availability, plans, photographs or completion status as the development changes.