What to prepare before a rebuild

The schedule starts with the inputs

Most website projects do not slip because the design took longer than expected. They slip because the team waited eleven days for a list of service areas, then three weeks for photographs of the office, then a fortnight for someone to find the login for the domain registrar.

Treat the inputs as the real start line. A rebuild that begins with content, assets and access already gathered runs on a schedule that holds. One that begins on the signature date runs on a schedule that quietly becomes fiction in week two, and everyone involved learns it at the same moment: too late to fix.

The list below is short enough to finish in a working week if one person owns it. That is usually the difference between launching in the quarter you planned and launching in the next one.

Content is the long pole

Write down the facts that only the company can supply. The services offered and the ones deliberately declined. The markets served, named individually, with the boundaries you would actually accept a property inside. The fee structure, at whatever level of detail you are willing to publish. Property types and unit counts you work with. Response standards you are prepared to put in writing.

Then the people. Names, roles and one accurate sentence each for anyone an owner or resident will deal with. Biographies are the single most requested and single most delayed item in a rebuild, and they are also among the most read pages on a finished site.

Nobody needs polished prose at this stage. Bullet points in a shared document are enough. What is expensive is a blank where a fact should be, because a blank stops a page from being designed at all.

Photography: one real shoot beats a stock library

A grid of licensed interiors makes a company look like every other company. One competent half day shoot makes it look like itself. If the budget allows only one visual investment, this is the one that returns.

Shoot the team, the office, and four or five properties that represent what you actually manage. Include wide frames with room at the edges, because a website crops differently at every screen width and a tightly framed photograph is unusable as a banner. Hand over the original files rather than the versions that have been through a social media app.

If a shoot genuinely is not possible before launch, say so early. There are layouts that work with very little photography, and they are chosen at the design stage rather than improvised in the final week.

Access is the quiet blocker

Access items look trivial and are the most common cause of a launch delayed by days rather than hours. Find the domain registrar login and confirm who controls it. Find out where DNS is actually hosted, which is often not the registrar. Locate the analytics and search console properties, or accept that the historical data is gone.

Gather the live portal, vacancy and application URLs from the property management platform, not from the current website, because the current website is frequently the thing that is out of date. Confirm which address form submissions go to today and which they should go to tomorrow, and check that the sending domain is configured so the confirmation emails do not land in a spam folder on launch day.

Write all of it into one access inventory and keep it current. It is the document that makes handover real, and a company that has one is never locked out of its own website by a former vendor.

Decide who decides

Review is where good projects lose their weeks. Three stakeholders sending separate, partly contradictory notes on different days will add a round to every stage of the build and will produce a website that argues with itself.

Name one person who owns the decision. They can gather as much internal opinion as they like, and should, but what reaches the design team is one consolidated response per round with the conflicts already resolved. It feels bureaucratic for the first week. By the fourth it is the reason the project is still on schedule.

Inventory what already works

Before anything is replaced, list the pages on the current site that receive search traffic or that other websites link to. Service area pages and older articles are the usual survivors. They carry real value that a rebuild can either preserve or discard, and discarding it is invisible until rankings drop two months after launch.

Map every one of those URLs to its destination in the new structure, and agree what happens to the pages that have no successor. A redirect inventory built during preparation takes an hour. Reconstructing one after launch, from a traffic report and a memory of what used to exist, takes considerably longer and never recovers everything.