Rebuilding On Ropes, from WordPress to a site that answers questions

On Ropes is an Auckland rope access company. Its technicians abseil down apartment towers, office blocks and silos to repair facades, recoat walls, find leaks and test roof anchors. Boro Srbinovski started it in 2021 after ten years working at height.

The work is precise. The old website wasn't. It was a WordPress site that looked like a lot of other trade sites, and said little a property manager could check.

I rebuilt it, as one part of a wider change in how the company runs: enquiries that flow into ONYX1 as jobs, a managed Microsoft 365 for the team, and how the business shows up when someone in Auckland searches for rope access or asks an AI assistant about it. The project page has the whole picture. This is the story of the website, with screenshots from the live site.

The short version

• WordPress is gone. The new site is nineteen hand-built pages with no theme and no plugins to patch.
• A three.js scene runs a rope access crew and a scaffolding crew against the same building, so you can watch the difference instead of reading about it.
• Every form is protected against spam. Quote requests land straight in ONYX1, the job-management product I co-founded, so the enquiry becomes the job record.
• Microsoft 365 runs the mail and accounts, and the company domain is protected so forged email gets stopped.
• Every page is written and marked up for three readers: people, search engines and AI assistants.

Why not just fix the WordPress site

Fair question. Most of what was wrong could, in theory, be patched: a faster theme, an image plugin, a caching plugin, a forms plugin, a security plugin.

That stack is the problem. Each plugin is another thing to update, another login and another way in. For a contractor without an IT department, a site that needs patching every week is a site that eventually doesn't get patched.

The pages On Ropes needed don't change often. Services, projects, the team, an FAQ and a quote form. That's a document, not an application, so I built it as one. There's no WordPress login to break into and no plugin waiting for a security patch. Retired addresses redirect, so links people saved still go somewhere sensible.

Designing for the person comparing quotes

The people who visit are property managers, body corporates and facility teams. Many arrive with a scaffolding quote in hand, wondering whether rope access is cheaper, safer or just different.

So the site borrows from the documents they already use: schedules, spec tables and timeline bars. There's one accent colour, the green from the logo, kept for things you can press and things that prove a claim. Sentences are short. Numbers do the persuading: IRATA technician levels, the standards the anchors are tested to, two independently anchored ropes for every technician.

Specificity cuts both ways. A review found the site said the company was founded in 2022. The Companies Office record says November 2021. Nine references got corrected, including the structured data. Small, but a site that sells precision had better be precise.

The 3D comparison

The question every client asks is how rope access compares with scaffolding. You can answer it in a paragraph, or you can show it.

The home page has a three.js scene with one building and two crews. On the left, two rope access technicians and a site lead rig the roof, go over the edge and work down the facade. On the right, a six-person crew puts up scaffolding one lift at a time. A slider down the middle lets you drag between them, and each side keeps its own clock.

A few decisions made it work on a phone, not just on my laptop:

• It's honest about time. The clocks are labelled as illustrative and the caption says real durations vary by site. It shows the sequence. It isn't a quote.
• It loads only when it's needed. A still image paints first, and the 3D code is fetched as the scene scrolls into view. If a device asks for reduced motion or data saving, the 3D code never loads at all.
• It's built for touch. Drag to rotate, pinch to zoom. On touch devices it renders at a lower frame rate so a background demonstration doesn't drain the battery.
• The technician is a real model. It's a public-domain character model by the artist Quaternius, posed and harnessed in code, with its licence recorded next to the file.

Enquiries, end to end

A contractor's website has one job: get the phone ringing or the inbox filling with real work. Spam undoes that. So does an enquiry that sits in an inbox nobody's watching.

Every form on the site is protected against spam, including the pop-up callback form. Almost everyone sees nothing at all; only traffic that looks automated gets challenged. Enquiries are checked again before they reach the team, so the inbox fills with real work rather than bots.

The quote page goes a step further. It embeds the ONYX1 enquiry form, so a quote request doesn't arrive as an email at all. It arrives in ONYX1 as an enquiry, already in the pipeline that turns it into a quote, a crew schedule, site photos, safety records and an invoice. Anyone browsing without JavaScript gets a plain link to the hosted version of the same form.

That's the part I care about most. The website isn't a brochure bolted onto the business. It's the front door of the same system the crew uses on site.

Making it fast on a phone

Most visitors are on a phone, often on site. The first full build looked good on a desktop and was heavy on mobile. Lighthouse, Google's page audit tool, scored mobile performance at 64. The largest element took 13.4 seconds to paint on its simulated mobile connection, and the home page weighed 5.2MB, of which 3.9MB was images.

The cause was simple. I'd rebuilt the photography from the original files, up to 2,400 pixels wide, and sixty of them had no smaller versions. A phone was downloading a 2,400 pixel photo to fill a 350 pixel card.

The fix was boring, which is how fixes should be:

• Every image now offers 800 and 1,280 pixel versions, sized to the slot it sits in.
• Only the first hero photo loads before the page paints. The rest wait until the browser is idle.
• The font stylesheet no longer blocks the first paint.
• The logo files went from 1,535 pixels wide to 480, for a mark that displays at about 150.

Home page imagery went from about 3.9MB to about 1.5MB at the size a phone picks.

Search engines and AI assistants

Being found is a different problem from being good. When a property manager in Auckland needs a leak found on level nine, they search. More and more, they ask ChatGPT, Claude, Gemini or Perplexity instead, and the answer names two or three companies. You want to be one of them.

There's no trick for either. Both reward the same thing: clear, specific, consistent facts a machine can read without guessing. So the site states its facts in layers, one for each kind of reader.

In practice that means:

• Pages that answer real questions. Each service page says what the work is, when you need it, how it's done and what you get at the end. The FAQ answers cost, safety, access and paperwork in plain language, 26 questions in all.
• Structured data on the pages that matter. The business, its address and hours, each of the seven services, the breadcrumbs and the FAQ are marked up as schema.org data, so a search engine doesn't have to infer them.
• Files written for AI. The site publishes an llms.txt, a short plain-text map of the business, and a longer reference with company facts, service scope, safety, quoting and FAQs. An assistant that reads it gets the facts from the source.
• The same facts everywhere. Name, address, phone number, founding year and service list match on every page and in the structured data.

The goal was page one on Google for the Auckland searches that bring in work, and to be a company AI assistants name for rope access in Auckland. In my own checks it's there now. Treat that as an observation rather than a measurement: rankings move with location, device and personalisation, and AI answers change from week to week. The groundwork doesn't move, and that's the part anyone can control.

The IT behind it

The website is the visible part. The less visible part is the company's Microsoft 365, which I run end to end: user accounts, licences and mailboxes for the team.

It also covers whether the company's email can be trusted. The domain is set up so that receiving mail servers can tell real On Ropes email from a forgery, and keep the fakes out of the inbox.

For a business whose clients pay by bank transfer, that matters. An email pretending to be a supplier and asking for new bank details is a well-worn fraud, and a protected domain makes it much harder to pull off.

What I'd tell another trade business

• You probably don't need a CMS. If your pages change a few times a year, a static site is faster, cheaper and has far less to attack.
• Show the work. Real crew photos beat stock photos, and a demonstration beats a paragraph.
• Connect the form to the job. An enquiry that lands in your job system gets answered. One that lands in a shared inbox might not.
• Write for machines too. Structured data and an llms.txt take a day. They're how search engines and AI assistants learn what you do.
• Protect your email domain. Setting up SPF and DMARC costs nothing and closes off a whole class of fraud.

Questions people ask about the rebuild

How long did it take?

The bulk of the rebuild, two rounds of review and the performance work landed between 1 and 11 September 2026. The ONYX1 enquiry form went in on 8 October.

Does the 3D scene slow the page down?

Not the first paint. The page loads a still image in its place, and the three.js code is only fetched when the scene is about to scroll into view. Devices that ask for reduced motion or less data never fetch it.

Do AI assistants actually read llms.txt?

Honest answer: it's a proposed convention, not a standard, and support varies by assistant. It costs little to publish, and anything that fetches it gets a clean summary. The structured data and plain, specific page copy do more of the work.

What's next?

RCO, a building, restoration and maintenance company, has a site I built in Framer. The next phase moves it to Next.js on Vercel, with the same enquiry handling, structured data and AI-readable reference. Both are on my client work page.