A retail leasing website looks like the easiest project on the list. A few pages, some photos of shop units, a contact form. Something you could build over a long weekend.

Then you think about who's actually using it. A brand looking for its next store, comparing locations on a phone between meetings. A leasing team that needs to mark a unit as taken today, not after a developer's next deploy. And Google, which decides whether anyone finds the site at all.

Building the Kate Mall leasing website was a good reminder that "simple" websites have their own kind of depth. Here's what a leasing site really needs, and the thinking behind the decisions.

Who the site is really for

The first decision wasn't technical. It was being clear about the audience.

A shopping mall has two very different websites hiding inside it: one for shoppers (what's open, opening hours, events) and one for businesses (what space is available and how to lease it). A leasing website is the second one. Its visitors are retailers, brand managers and franchise operators, and they arrive with a practical question: is there a space here that fits my business, and how do I talk to someone about it?

Every page had to help answer that question faster. Anything that didn't was decoration.

Unit listings: structured data, not a brochure

The heart of the site is the available units. It's tempting to treat them as content, a page per unit with text and photos. The better approach is to treat them as data: each unit has fields like size, floor or zone, category of use and availability status.

Structured data pays off everywhere:

• Filtering by size or category becomes a query, not a manual list someone has to keep in sync.
• Consistency: every unit page shows the same information in the same place, so visitors can compare.
• Status changes in one place. A unit marked as leased disappears from the available list everywhere at once.

The general lesson: whenever a client says "pages", check whether they really mean "records". Records are easier to keep correct.

Enquiries: the only conversion that matters

For a leasing site, success isn't page views. It's a serious enquiry reaching the leasing team with enough detail to act on.

That shaped the enquiry flow:

• Enquire from the unit page, with the unit already attached, so the team knows exactly what the visitor was looking at.
• Ask only what's needed to start a conversation: name, company, contact details, type of business. Every extra field costs submissions.
• Store every enquiry, then notify. An email notification is convenient, but emails get lost. Saving the enquiry first means nothing disappears if a mail server has a bad day.
• Protect the form with validation, rate limiting and spam protection, because public forms attract bots within days.

// Simplified: save first, then notify in the background
$enquiry = Enquiry::create($request->validated());

Notification::route('mail', config('leasing.team_email'))
    ->notify(new NewLeasingEnquiry($enquiry));

With a queued notification, the visitor gets an instant "thank you" while the email is sent in the background.

SEO: be findable for what people actually search

A leasing website that nobody finds is a very nice brochure in a drawer. The SEO basics did most of the work:

• Server-rendered HTML, so search engines see real content immediately rather than an empty page waiting for JavaScript.
• A unique title and meta description for each page and unit, generated from the data, not copy-pasted.
• Clean, readable URLs and a sitemap that updates itself when units change.
• Proper headings and descriptive alt text, which help accessibility as much as search.
• Open Graph tags, because many links get shared in messaging apps, and a link with a good preview gets clicked.

Fast pages, especially on mobile

Leasing sites are image-heavy: floor plans, storefronts, photos of the mall. Images are also the most common reason a site feels slow.

The rules I follow on sites like this:

• Resize images on upload and serve sizes that match the screen, in modern formats where supported.
• Lazy-load images below the fold, but never the main image at the top of the page.
• Set width and height on images so the layout doesn't jump while they load.
• Keep JavaScript small. A leasing site doesn't need a heavy front-end framework to show a list of units.
• Cache pages that rarely change, and clear the cache when the content does.

Admin updates: the team shouldn't need a developer

This is the part that decides whether a website stays accurate after launch. If changing a unit's status needs a developer, it won't happen on time, and an out-of-date availability list is worse than none.

So the admin side mattered as much as the public side: simple forms for units, photos and statuses, and a list of enquiries. Not a generic page builder with a hundred options, but screens shaped around the few things the team actually updates.

What I'd tell anyone building something similar

• Know the one question your visitors arrive with, and answer it fast.
• Model listings as data, not pages.
• Save enquiries before sending emails about them.
• Get the SEO basics right before reaching for anything clever.
• Treat images as the main performance problem, because they usually are.
• Make updates easy enough that the business does them without you.

If you've built a listings site, for property, jobs or anything else, what was the part that turned out harder than it looked?