One client has had their website redesigned three times across the same codebase. Each refresh ran in weeks, the look and feel changed substantially, and not a single page had to be rebuilt. Another client came to us with an inherited site where changing the hero image meant editing it on twenty separate page templates by hand. Same business goal of a site that looks current. Completely different cost.
The reason isn’t budget or designer talent. It’s a set of architectural choices the original developer made years before the redesign conversation started. The site that refreshes cheaply was built with reusable components, design tokens, and content separated from presentation. The one that has to be rebuilt was built the way a lot of sites are built: page by page, with styling copied around and content embedded in HTML.
This post is about what makes the difference, how to spot it before you commission a new build, and why the cheapest site to launch is rarely the cheapest site to own. If you are starting from scratch rather than deciding what to do with a site you already have, how long that build takes and what moves the number is the more useful question.
The site that’s been redesigned three times
The client redesigns regularly. Brand evolves, market positioning shifts, conversion data points to a new homepage hierarchy. Each redesign is a creative project for the design team, and each one ships in weeks of development work, not months.
A few decisions, made once, are why.
Reusable components. Every page is built from the same set of building blocks. One hero, one feature grid, one CTA, one card layout. When the designer wants the hero to look different, we change one file. The fourteen pages using it update at once. Designers can rearrange and restyle without anyone touching twenty page templates.
Content separated from presentation. Blog posts, case studies, and marketing pages are content data, not HTML. The template renders them. Changing the template changes every post without touching any post.
Utility-first styling. Styles live next to the markup that uses them. Delete the markup, the styles go with it. No accumulating stylesheets full of classes nobody can safely remove because nobody knows what they’re still styling.
A design token system. Colors, spacing, type, and radii live in one place. A brand refresh updates the tokens. Everywhere those tokens are used updates with them.
None of those choices costs more on day one than the alternatives. They cost the same time to build, sometimes less. They just compound favorably every time the site changes.
The sites that have to be torn down
The contrast pattern shows up in almost every inherited codebase we audit. Different sites, same handful of structural problems.
Hardcoded HTML inside blog posts. Past authors or developers embedded <div> tags, inline styles, and layout markup directly inside post content to fight a rigid template. Redesigning the look means manually editing every post (sometimes hundreds) to strip out the embedded markup before the new design can apply. We’ve done this on a client project. It’s a budget line item nobody plans for, because the buyer didn’t know it was there.
No components, just templates. Each page is its own HTML file, top to bottom. The hero on the homepage is independent from the hero on the about page is independent from the hero on the services page. Changing the design means changing them all by hand and hoping you find every copy.
CSS class graveyards. Stylesheets accumulate over years. New designs add new classes. Old classes stay because nobody knows where they’re still applied. After three or four iterations, the CSS is a layer cake of decisions nobody can safely remove. A redesign that updates one component breaks two others nobody knew were linked.
JavaScript mashed together. Inline scripts, global variables, and event handlers entangled across pages. The behavior the designer wants to change is buried under behavior that has to keep working. Touching anything risks breaking everything. That same entangled JavaScript is also what tends to fail INP, the Core Web Vital that measures interaction responsiveness: heavy handlers and uncontrolled re-renders block the main thread on every click.
The buyer didn’t choose any of this. It’s the result of a build that prioritized day-one cost over five-year cost, or that was assembled by someone working without a system. The damage isn’t visible until the second or third redesign quote comes in and the buyer can’t understand why it costs as much as starting over.
The extreme case is a full platform migration, where the rebuild cost reflects the same underlying issue: templates have to be rewritten, plugins replaced, integrations re-implemented, content extracted from whatever HTML it was buried inside.
What makes a website easy to redesign
The choices that let a site refresh easily are unglamorous and not unique. They’re well-known in modern web development. They show up consistently in the sites we build, and they show up in the sites we redesign without rebuilding.
Components, not pages. The same building blocks reused across the site. Redesign once, update everywhere. The hero, the feature grid, the testimonial block, the CTA. Each lives in one file.
Content as data, not markup. Posts and pages are structured records. The template decides how they look. A redesign changes the template. Every page renders the new design without touching the content.
Utility-first styling. Style classes live alongside the markup they style. When the markup is deleted, the style goes with it. No dead CSS accumulating in the background.
Design tokens. Colors, spacing, fonts, and radii defined in one place. A rebrand is a token update, not a markup audit.
Server-rendered or static. Pages are HTML files, not JavaScript apps. What ships to a visitor is what shows up in the source. Designers and developers can see and change what’s actually rendering. For a content site, a JavaScript framework is usually more than the job needs.
None of these is exotic. They’re the default in modern frameworks for a reason. The reason they don’t show up in every quote is that they take judgment and discipline to set up well, and the cost is paid by whoever builds the site first while the savings are collected by whoever owns the site later.
How to evaluate this before you hire
You don’t need to read the codebase to test for these choices. The questions below give a competent developer obvious openings to demonstrate their thinking. The exact words don’t matter. The shape of the answer does.
1. Are pages built from reusable components, or is each page its own file? Looking for: components, used across multiple pages. The wrong answer sounds like “we’ll build each page individually” or “we’ll start from a template and customize.”
2. How is blog content handled if we change the design later? Looking for: content stored as data (a CMS, markdown, a structured collection) with the design applied through a template. The wrong answer sounds like authors embedding HTML inside posts, or every post being its own file.
3. What happens to old CSS when we update the design? Looking for: utility-first styling or design tokens, so unused styles disappear with the markup that used them. The wrong answer sounds like “we’ll leave the old styles in case we need them” or “we’ll add the new styles on top.”
4. If we want a different button style site-wide, how many places change? Looking for: one. If the answer is “every page that uses one,” the architecture isn’t built for the kind of changes a real website goes through.
5. How do you keep the design consistent as we add pages later? Looking for: a design system, a token set, a component library. The wrong answer sounds like “we’ll copy from the closest existing page.”
A developer who can answer all five with grounded specifics is set up to deliver a site you can refresh. A developer who pivots or stays vague on more than one or two is likely to deliver a site you’ll have to rebuild.
These same questions work in reverse on a site you already own. If you can’t answer them about your current site, that’s the audit. The gap between what’s there and what should be is what a refresh would have to cover before any new design can land.
Why the cheapest build is rarely the cheapest over five years
A build that skips reusable components, design tokens, and content/presentation separation is cheaper on day one. Less setup, fewer architectural decisions, faster to the launch screenshot.
That savings is spent back, with interest, on every redesign, every new page, every content change, every audit. The total a buyer pays for the site over five years is the launch cost plus everything spent maintaining and changing it after launch. The choices that make the first job cheaper are usually the ones that make the second job expensive.
The question worth asking isn’t “how much does this site cost to build.” It’s “how much does this site cost to own for five years.” If the architecture is right, the answer is roughly the launch cost plus periodic refreshes. If the architecture is wrong, the answer is the launch cost plus a rebuild somewhere down the line, and possibly another after that.
This is the same calculation behind the broader build-vs-buy decision. Even when custom is the right call, the way the custom site is built determines whether it can grow with the business or has to be replaced.
The choice is made once
A site can be built to grow with the business, or built to be replaced. The choice is made once, at the start, by the team writing the first version. It determines every refresh after.
If you’re commissioning a new site, ask the five questions before signing anything. If you’re sitting on a site you inherited, the same questions tell you what you’ve got. The answers don’t have to use the words a developer would use. They have to describe the same kind of thinking.
If you want a read on whether your current site can be redesigned or has to be rebuilt, tell us what you’ve got. We’ll give you an honest read on what’s there.