Most sites have one reader. This one had two, and they wanted opposite things.
I will keep the client vague. It is a regulated financial product, sold through professional practices, that protects the work those practices do for their own customers. So the business buys it, and the customer lives with it. Two audiences, one product, and almost nothing in common between what each of them needs to read.
Why one page could not do it
A business owner evaluating this wants to know what it costs, what they earn, what happens to their liability, and how much of their day it takes. They are doing arithmetic. Their tone is skeptical and their attention is short.
Their customer wants to know one thing: if this goes wrong, am I covered, and what do I actually do? They are not doing arithmetic. They are worried.
A single page trying to serve both ends up hedging every sentence. It talks about margin and reassurance in the same breath and lands as marketing rather than information. So the site splits early, at the top level, and the home page does almost nothing except establish what the product is and route you to the version written for you.
The home page's job was not to explain the product. It was to figure out which of two people had arrived.
Seventeen pages in the end. Two audience tracks, a claims page, a leadership page, a newsroom with four long-form articles and a launch release, three legal pages, and three intake forms.
Showing the money instead of claiming it
The hardest page was the business one, because the pitch is financial and financial pitches on websites are usually a summary you are asked to trust.
Instead of a claim, that page walks one representative case through four numbered steps: the value of the work, what the product adds to it, what the business earns, and what it costs them when a claim is paid. Each step is a real number sitting in its own block, and the fourth step is the one that does the persuading, because it is the number that used to come out of their pocket.
Underneath it sits a short outcome panel: four plain lines on what changes for the business, and one on what changes for their customer. The walkthrough earns the claim, then the panel states it. Doing it the other way round is how you get a page nobody believes.
Drawing it instead of buying it
Stock photography for this category is dire. Every option is the same lightly-lit office, the same posed handshake, the same equipment. It says nothing about the product and it makes any brand using it look like every other brand using it.
So the two moments that matter most are hand-drawn instead: an illustration of the actual thing being sold, and a checklist graphic on the customer page where a stock photo had been sitting and reading, in the client's words, too clinical. Both are inline vector, which means they are a few kilobytes, they stay sharp on any screen, and their colours come from the site's own palette rather than from whatever a photographer lit three years ago.
The page that is deliberately hard to find
Claims got their own page, linked from the footer on every page and deliberately absent from the top navigation.
That looks like a mistake and it is not. Nobody is browsing for the claims process. They arrive at it in one of two states: they are evaluating and want to confirm it exists, or something has failed and they need it right now. Both of those people will find a footer link. Meanwhile putting "File a Claim" in the primary nav of a marketing site tells every prospect to think about failure before they have understood the product.
The page itself is the process in four steps, the questions people actually ask, and a contact form. It is the only page on the site written for somebody having a bad day, and it reads differently because of it.
No framework, on purpose
Seventeen files of hand-written HTML, styles inline, one folder of images. No build step, no package manager, no content management system.
The cost is real: a change to the navigation means editing seventeen files. I made that trade because a static folder can be opened by anyone, on any machine, in ten years, with no toolchain to resurrect and no dependency that has since been abandoned. For a marketing site of this size, the thing most likely to break it is not traffic. It is a build pipeline nobody has run in eighteen months.
It also means the site is genuinely fast without anyone optimising it, and that whoever inherits it can read it.
The layer nobody sees
Every page carries structured data: a machine-readable copy of what the page says, which search engines read and humans never do. It is invisible, which is exactly why it rots.
When I audited the finished site before delivery, six of those answers had quietly drifted out of sync with the visible copy during editing. The page said one thing, the data said what the page used to say. Nobody would ever catch that by looking, because looking is what reviews do.
In the same buried layer, the site was declaring availability in eighteen states the client is not licensed in, and omitting the one they are. Invisible on screen. Perfectly legible to anything that parses it.
The rest of the audit turned up about a dozen smaller things, including several I had introduced myself in the final round of edits: a stray closing tag pushing a section outside its container, two links pointing at anchors that no longer existed, and an accessibility skip link that pointed at nothing on the one page most likely to be reached by someone in trouble.
None of it was visible. All of it was real. Auditing your own finished work is worth more than any amount of care during the build, because the errors that survive to the end are precisely the ones your attention has stopped catching.
What I would keep
The split by audience, first and always. The walkthrough that shows a number moving instead of asserting one. Drawing the thing rather than buying a photograph of something adjacent to it. And putting the page for people in trouble where people in trouble will look, rather than where it flatters the funnel.