A redesign won't fix it. You probably don't have a design problem.

The redesign trap

A redesign changes how the site looks. It rarely changes what the site says, and it almost never changes what the site can do. If your real problems are a stale story and a structure machines can't read — and for most founder-led firms they are — a redesign gives the stale story new typography and the unreadable structure new colors.

There's a tell you can check right now: pull up the proposal from your last redesign. Count how many line items are about how the site looks, and how many are about what it says, what machines can read from it, and who on your team can change it without a developer. Most proposals are 90% the first category. That ratio is the trap.

The brochure was the problem. A prettier brochure is not the answer.

What a website is now

The brochure model made sense when a website's job was to impress a visitor who already found you. That job still exists, but it's no longer the main one. Your site is now read by more machines than people: search crawlers, AI engines answering your buyers' questions, tools your prospects run before they ever email you. And it's the natural home of things that used to live in your head and your inbox — your offers, your prices, your process, your standards.

Built for that reality, a website stops being marketing collateral and becomes an operating surface: the place where the business states what it does, in a form both buyers and machines can read, that your team can keep current without you. That's a different artifact from a brochure, built differently:

• Componentized, not page-painted. Offers, proof, prices, and FAQs live as structured pieces that can be assembled into new pages fast. A landing page for a new campaign takes hours, not a project.
• Structured data on every page. Machines are told what the business is, what it sells, and what it costs — not left to infer it. This is the difference between being cited by AI engines and being guessed about.
• A content system your team runs. Publishing doesn't route through a developer or through you. The person who knows the update makes the update.
• Documentation as a deliverable. The build isn't finished when the site launches. It's finished when your team can run it — which means the how is written down and handed over, not retained as the builder's leverage.

When a redesign IS enough

Honesty matters here: sometimes new paint is the right spend. If the story on your site is current, machines can read it, your team can update it, and it simply looks five years old — hire a designer, skip the rebuild, and don't let anyone talk you into more. A visual refresh on sound structure is cheap and fast.

The test is what failed. Run the checks in why your website isn't bringing in clients. If the story and the structure pass and only the aesthetics fail, redesign. If the story or the structure fails, no amount of design will move the numbers, because the numbers were never about design.

Why the build has to start from the operating logic

Here's the step most rebuilds skip, and it's the one that decides everything: the site can only carry the business's operating logic if someone extracted that logic first. An agency can't extract it — they'd have to interview you for months and they're not scoped to. So they work from your old site and a kickoff call, which is how the new site ends up a better-looking copy of the old one.

This is why every build I do starts from an Operating Map — three working sessions that get how the business actually runs on paper before anything gets built. The Map produces the structure; the build makes it real. Scoped that way, the build can be fixed-price, because the unknowns were resolved before the first line of code. No exceptions to this, including for clients who arrive ready to build: unmapped builds are how the industry produces expensive brochures.

The economics, honestly

A mid-market agency redesign for a services firm runs $30,000 to $80,000 once you count the strategy phase, and it depreciates like a car: the day it launches is the best it will ever be, because nothing about the build changed who can update it or what machines can read. Three years later you're back at the same table buying the same project.

An operating surface costs comparable money up front — in my practice a fixed price, scoped from the Map — and the economics run the other way. Every new page inherits the structure, so the cost of the next landing page falls from a project to an afternoon. Your team publishes without a developer, so the update backlog stops accruing. The structured data compounds as engines re-crawl. And because documentation is a deliverable, you own the thing outright — no builder dependency priced into every future change.

Whichever way you buy, put these questions to any builder: Who can create a new page after launch, and what does it cost? What exactly will machines be told about the business, page by page? What gets handed over in writing? A builder with good answers is safe to hire at any price. A builder without them is expensive at any price.