Designing in the browser before building in Elementor

What they had, and what they did not

AWRA Invest sells luxury property — branded developments, waterfront villas and private estates across Dubai, Europe and West Africa. New company, new site, nothing to migrate.

They arrived with three things:

• a logo
• a video
• the copy they wanted on the page

And nothing else. No layout, no reference site they liked, no brand guidelines, no photography beyond the video. For a business whose entire proposition is discretion and taste, “make it look expensive” is not a brief you can build from directly.

So the design was the deliverable. The build came second.

The problem with approving a picture

The normal route here is a mockup — design it flat, send a PNG or a Figma link, get sign-off, then build.

That works, but it has a known failure: a client approves a picture, and then sees the real site and feels something is off. The spacing breathes differently at their screen width. The hero behaves differently when the video is actually playing. Type that looked elegant in a static frame reads differently when you scroll past it.

Nobody is wrong in that situation. They approved what they were shown; it just was not the thing they were buying. And by then it is a rebuild, not a revision.

Designing the real thing instead

I built the design as a working page in plain HTML and CSS, and sent it as a link.

They opened it on their own phones and laptops, scrolled it, clicked through it, and saw the video running behind the opening line rather than imagining it. Approval was on the actual experience.

The reason this works better here is specific to the type of site. A brokerage page is almost entirely feel — space, restraint, pace. There is no complex functionality to specify. Static HTML gets you to the real feel quickly, because there is no page-builder overhead between an idea and seeing it.

Then, once approved, Elementor:

• The client’s team can edit text and images without me
• Adding a market or a page does not need a developer
• The design was already settled, so the build was execution rather than decisions

What the design had to do

For a brokerage selling to private buyers, the site is a credibility document, not a property catalogue. Nobody buys a waterfront villa from a web page. They decide whether this is a firm worth an introductory conversation.

That pushed everything toward restraint: generous whitespace, an editorial serif, a muted palette taken from the logo, and the client’s video running full-bleed behind the opening statement rather than boxed into a corner.

Markets are divided into the Middle East, West Africa and Europe, each reachable in one move from anywhere on the site, with the enquiry route kept short throughout.

The result

Two weeks from first design to launch, with no redesign requests once the build began — because the thing they approved and the thing they received were the same thing.

When I would not do it this way

This suits a site that is mostly presentation. If a project is driven by functionality — a booking flow, a dashboard, anything with real states and logic — designing it in static HTML means building a shell you then throw away. A wireframe or prototype is the right tool there.

The trade is honest: designing in the browser costs more time up front than a flat mockup. You get it back by not rebuilding later, and by removing the most expensive kind of disagreement — the one that surfaces after the work is done.