Websites and launch pages, designed and built to convert
Corporate websites and campaign landing pages, grouped below by what each one is rather than by who it was for. The published set is property — a corporate site and four off-plan launches, all built to carry high-resolution renders without the load time that usually comes with them — and the same build applies to any sector where a page has to load fast and produce an enquiry. Follow any capture through to the case study for the stack and the structure.
This page carries both the design and the build, because they are the same seven captures looked at two ways: how each page is composed, and how it was implemented. Splitting that into two pages would mean two pages showing identical images, which is worth avoiding.
Corporate websites
1 capture
Landing pages
4 captures
Mobile layouts
2 captures
Built around the campaign pointing at it
Most of these sites exist to receive paid traffic. That changes what matters. A brochure site can afford a slow hero image and a form that asks nine questions. A page receiving paid clicks cannot, because every second of load time and every unnecessary field is being paid for per visitor.
So the build starts from the campaign rather than from the design: what the ad promised, what the visitor expects to see first, and what the single next action is. The tracking goes in before the traffic does, which means the reporting is cost per enquiry from the first day rather than cost per click with a guess attached.
Speed is decided before any code is written
Most slow sites are slow because of what was designed into them: a full-screen video header, a carousel of uncompressed photographs, four webfonts and a stack of third-party scripts loading on every page. No amount of optimisation afterwards fully undoes those choices.
That is the argument for the same person doing both. The decision to use one typeface rather than four is a design decision with a performance consequence, and it is cheap to make at the start and expensive to reverse at the end.
What happens after launch, which is most of the cost
A website is not finished at launch, it is launched. Browsers update, dependencies need security patches, a payment provider changes an endpoint, somebody uploads a twelve-megabyte photograph and the homepage takes nine seconds. A site nobody maintains degrades quietly and the business usually finds out from a customer.
On this work maintenance was part of the arrangement rather than an afterthought, and the accounts stayed in the client's name throughout. That second part matters more than it sounds: a surprising number of businesses discover at the end of a relationship that their domain or hosting sits inside somebody else's structure.
The stack, and why it is not the interesting part
React, Next.js and Node on the custom builds, WordPress where the client needed to edit pages without calling anyone. The choice matters far less than people pretend, as long as whoever builds it is genuinely fluent in what they picked.
The question worth asking is not which framework but who runs the site afterwards. A custom build needs a developer for every change. A WordPress site lets a marketing person add a page on a Tuesday afternoon. That is a business decision rather than a technical one, and it should belong to the client.
Web Development questions
What do you build websites with?
The work on this page is custom-built rather than assembled from a page builder, which is what makes the load times on render-heavy property pages possible. I will happily work in WordPress or Webflow where that is genuinely the better fit for your team's ability to edit the site afterwards.
Can you take over an existing website?
Usually yes. Send me the URL and where it currently sits, and I will tell you honestly whether it is worth improving or worth rebuilding, and roughly what each would cost.