The Question We Ask Before Quoting Any Redesign Project

I run a small WordPress studio — webmaster.co.ua, 18 years, 235+ projects. A large share of our work isn't new builds — it's redesigns of existing sites. For years we scoped those the same way we scoped new builds. That was the mistake.

"Redesign" hides two completely different projects under one word. Sometimes a client wants a visual refresh on a site that fundamentally works. Sometimes they want a visual refresh because the real problem is that the site doesn't convert, and they've concluded — often wrongly — that a new look will fix it. Quoting both the same way means underpricing the second one and over-delivering design work the client didn't actually need.

We now ask what's changed since the current site launched, not what they want it to look like. A business that's rebranded, added new services, or shifted its customer base has a real reason for a redesign that a style refresh will genuinely serve. A business whose situation hasn't changed but whose site "feels dated" usually has a narrower problem than they think — often just a couple of outdated design choices, not a full rebuild.

Analytics before opinions, every time. Before agreeing on scope, we pull whatever traffic and conversion data exists on the current site. It's changed the conversation more than once — a client convinced their homepage was the problem, when the data showed nobody was making it past a broken step three pages later. Redesigning the part that was actually fine would have wasted the whole budget.

Old content and structure carry more value than clients assume. A full rebuild throws away SEO equity, existing backlinks, and page structures that were quietly working, along with the parts that weren't. We now default to auditing what to keep before scoping what to replace — a full rebuild is sometimes right, but it should be a decision, not a default.

If your redesign quotes look identical to your new-build quotes, it's worth splitting them — the two projects solve different problems, even when the deliverable looks the same on paper.