Making real estate the front door of the Dialessa website

Today was a short website day: 1 working session with coding agents, 3 prompts, 3 commits, 4 deploys, about 2 hours of active work and 597 lines changed. None of it was new product work. It was about making sure the right people land on the right page.

What I noticed

I'd been treating real estate as the main focus for Dialessa, but when I opened the live site, the homepage was still the generic version. The pages I'd written for real estate existed. The front door just wasn't pointing at them.

It's an easy gap to miss when you spend your days in the web app and the voice agent rather than looking at the website the way a visitor does. I'd been assuming the site reflected where my head was, and it didn't.

What I changed

• Made the real-estate page the main homepage.
• Set the voices page to open on the real-estate option by default, so someone browsing voices hears the version that fits them first.
• Updated the blog articles so readers in other trades and in broking are pointed to a page written for their own line of work, not back to a generic page.

The last change matters to me because the blog brings in readers from more than one industry. Moving the homepage to real estate shouldn't leave everyone else at a dead end. A broker reading an article should get to a broking page, and someone in a trade should get to a page that talks about their work.

How I checked it

Before releasing, I ran the changes through a set of automated review and verification helpers. Each looked at a different angle:

• Code quality, to catch anything messy or fragile in the changes.
• Search visibility, because swapping the homepage can affect how the site gets found.
• Claims, to make sure the copy didn't promise anything I can't back up.
• User experience, to check the routes from blog to industry page actually make sense to a reader.

The claims check is the one I value most on marketing pages. It's easy to write a confident sentence that drifts past what the product does, and having something check every page for that before it goes live is worth the time.

What was hard

Nothing broke in a dramatic way. The hard part was the bit before any code: realising the live site didn't match what I thought it was showing. After that the work was simple, but it touched several pages, which is why it took 4 deploys to production. I released in small steps and checked each one on the live site rather than bundling everything into one big release.

What I learned

• Look at the live site regularly as a visitor would, not just the version in my head.
• When you narrow the focus on one page, check where everyone else ends up. Changing the homepage meant fixing the routes for every other audience too.
• Small, checked releases are easier to trust than one large one, even on a day this short.

It's a small change, but the website now matches the business I'm actually building.