Frontend revamp or full rebuild

Choose a revamp when the content model and the urls are sound. Choose a rebuild when the stack cannot be edited safely, or when the offer has changed shape. That is the useful way to make a website rebuild vs redesign decision, and it is more concrete than a debate about whether the site "feels old."

A revamp replaces the front of the site: templates, type, layout, and the way sections are written. The addresses, the kinds of pages, and the editing model stay. A rebuild replaces the system those pages live in. Both can be the right project. They have different risks, and they should not be sold as the same week of work.

A revamp when the bones are sound

Open the list of urls that matter. Homepage, product or service pages, a proof page, a way to start a conversation. If those pages still match how you sell, and if each one has a single job, the information architecture can stay. You are free to remake how a page looks and how it is built, without pretending the company is new.

The content model is sound when an editor can point at the headline, the sections, and the images as fields, not as a unique pile of markup on every page. A revamp then means new templates on that model. The team keeps the habit of editing. The visitors keep the addresses. You spend the project on clarity and craft.

This is the right scope when the complaint is visual drift, a phone layout that was squeezed in later, or a homepage that buries the offer under sections nobody will stand behind. The pages can be rewritten. The system does not have to be thrown out to do it.

A good revamp still has a brief. Name the pages in scope, the states of those pages, and the one action each must support. "Make it modern" is how a revamp becomes a rebuild in disguise, with none of the cleanup a rebuild requires.

A rebuild when editing is unsafe

Some sites cannot be changed without a specialist and a rollback plan for a headline. The symptoms are practical. There is no staging copy anyone trusts. Dependencies are pinned to a platform you cannot upgrade. A plugin owns the layout. The last clean copy of the content lives in someone's laptop. A small change risks the form that brings in work.

That is a rebuild. Carrying the old templates forward would preserve the fear. The new system should make the next edit boring: a repo the company owns, a preview, and a content shape that matches the pages you actually publish. On a Hanabi build that usually means a Next.js front end, written in TypeScript, with the content in a place an editor can open. The technology is the means. The result the founder should feel is that a sentence can change without a rescue.

Rebuild here includes a map of what comes across. You are allowed to leave behind plugins that only existed to patch the old theme. You are not allowed to lose the pages people already use unless those pages describe an offer you have ended.

If two people on the team tell the story of the last outage from a small content change, believe them. That story is a better scoping tool than a lighthouse tour of the homepage. The rebuild is justified when the risk of editing exceeds the risk of moving.

A rebuild when the offer changed shape

Sometimes the stack is editable and the site is still the wrong instrument. You used to be a single product with a one-page explanation. You are now a service with proof, a process, and a different buyer. Or you were a shop with a blog bolted on, and you are now a journal with a small shop. The old content model forces every new idea into the previous shape.

A rebuild fits when new pages would be workarounds. You would be hiding services inside blog posts, or selling a product from a homepage accordion, because the system has no place for the thing you now are. Design the page types you need, then build those. Keeping the old urls that still answer a real query is part of the job. Keeping the old template system is not.

Write the new offer in one sentence and list the page types it needs. If that list matches the current system, you are looking at a revamp with better copy. If the list introduces pages the system cannot represent without a hack, you are looking at a rebuild. The sentence does the diagnosis. The mood of the team does not.

What both projects still owe the visitor

Neither choice is a license to ship a slower, vaguer site. web.dev's Web Vitals guidance gives the current thresholds for a good experience: largest contentful paint within 2.5 seconds, interaction to next paint at 200 milliseconds or less, and cumulative layout shift at 0.1 or less. A revamp that adds a heavy introductory sequence, or a rebuild that waits on a pile of scripts, has failed the visitor in a way you can measure.

Google's people-first content guidance also draws a line that founders cross by accident. Removing or mass-adding pages mainly to look fresh does not make a site more helpful, and Google says quite plainly that this will not improve how a site seems in search. Keep the pages that still answer something true. Rewrite the ones whose offer is stale. Delete the ones that describe a product you no longer stand behind, and redirect them to the closest honest page.

The visitor's test is the same in both projects. What is this, and how do I talk to a person? If the new front end cannot answer those in the first screen, the scope argument was internal. It never reached the page.

A short way to choose

Use four questions. Stop at the first one that forces a rebuild.

• Do the current page types match the offer you want for the next year?
• Can a teammate change a headline, a proof point, and a price without fear?
• Can the urls people already use be preserved or redirected on purpose?
• Can the new front end meet the Web Vitals thresholds without special pleading?

If the first two are yes, commission a revamp and spend the effort on the pages, the phone, and the words. If either is no, commission a rebuild and budget for content mapping, not only for a new look. The signs that usually start this conversation are collected in how to tell a site needs a revamp.

When you want that choice made with design and production code in the same hands, start from Hanabi's services. The studio builds marketing sites, storefronts, and product interfaces for founders who need the page and the repo to agree.