Website redesign costs are shaped by what must change, what must be preserved and who is responsible for delivering each part. Page count matters, but it is rarely enough to compare proposals fairly.
A small website with difficult integrations, incomplete content and an uncertain migration can require more work than a larger site built from well-prepared material. Two quotes for the same number of pages may therefore describe very different projects.
Before asking whether a price is high or low, ask what it includes. A useful comparison separates design, development, content, migration, testing and ongoing responsibilities. That makes it easier to understand the trade-offs without relying on a generic price range that may not fit your business.
Distinguish a visual refresh from a rebuild
A visual refresh may preserve the existing platform, content structure and functionality while changing presentation. A rebuild may replace the platform, reorganise content, change integrations or introduce new publishing workflows.
These are not interchangeable scopes. Updating typography and layout is different from moving years of articles into a new system while maintaining their URLs and images.
Write down what is staying and what is changing. Include the hosting arrangement, domain, admin system, page structure and external services.
If you are unsure which approach is appropriate, make that an explicit discovery question. Requesting a fixed build price before that decision is made can encourage assumptions that only become visible later.
Count templates and behaviours, not only pages
Many pages can share a design template. A hundred articles might use one article layout, while a single quotation tool might require substantial bespoke behaviour.
Ask the supplier to identify the page types and unique interactions. Common types include the homepage, service pages, article pages, listings, contact forms and policy pages.
Then record what makes each type different. A service page with a simple enquiry link is not the same as one with interactive models, multiple media galleries and a conditional form.
This approach helps you see where custom work is concentrated. It also supports sensible prioritisation: a specialised feature can sometimes be delivered later without delaying the core website.
Treat content preparation as real project work
A redesign cannot solve every problem through layout. Old copy may no longer describe the business accurately. Images may be too small, poorly named or unavailable in their original format. Important information may exist only in sales documents.
Clarify who will gather, edit and approve the content. If copywriting is included, state which pages and how many review rounds are covered. If the business supplies copy, agree on the format and delivery dates.
Do the same for photography, video, diagrams and downloadable files. New visual assets and asset clean-up should not be silently treated as the same task.
A content inventory often reveals why apparently similar projects have different costs: one begins with approved material, while the other begins with a collection of unresolved decisions.
Examine integrations in detail
An integration can be as simple as a link to another service or as involved as a two-way exchange of records. The phrase "connect our CRM" does not describe the full requirement.
Ask which system owns the data, what should be transferred, when it should move and how failures should be handled. Identify whether staff need to review information before it is sent.
Also establish who provides access and documentation. A supplier may not be able to estimate an unfamiliar integration confidently until those details are available.
For a contact form, specify the recipient, required fields, storage requirements and confirmation behaviour. For payments or bookings, identify the external provider and the intended customer journey. Avoid assuming that a familiar logo means the implementation is automatically straightforward.
Include migration and existing assets in the scope
If the old site contains articles, product records, documents or customer-facing downloads, decide what must move. Check the quality of the export and whether relationships between records need to be preserved.
A migration may involve cleaning up duplicate material, mapping image paths, checking authors and categories, or identifying content that should be retired.
Keep the business decision separate from the technical operation. The project team can implement a migration plan, but someone responsible for the content needs to decide what remains relevant.
Ask how the migration will be tested. A successful import count does not prove that every page has the correct images, formatting, links and publication status.
Specify testing in terms of business tasks
"Testing included" can mean different things. Request a practical list of devices, page types and workflows to be checked.
Important tasks may include submitting an enquiry, opening a document, using the navigation on mobile, publishing an article and recovering from an invalid form entry.
Include relevant accessibility checks and a review of important pages under realistic connection conditions. A desktop screenshot cannot show whether a menu is usable on a phone or whether an upload fails partway through.
Decide who performs final acceptance and how issues are classified. Distinguish defects against the agreed requirements from new features requested after approval.
This makes the final review more predictable for both the business and the supplier.
Separate launch work from ongoing services
A website remains an operational responsibility after launch. Hosting, backups, software maintenance, content updates and support may be provided by different people.
Ask which recurring services are included, which are optional and which remain your responsibility. Clarify how you obtain access to domains, analytics, source material and content exports.
If support is included, ask what it covers and how requests are handled. A maintenance arrangement does not necessarily include unlimited design changes or new features.
Also discuss handover. Editors may need guidance on image preparation, publication dates, categories and routine content changes. A well-built admin interface is more useful when the people operating it understand its intended workflow.
Compare proposals on the same basis
Create a comparison table using responsibilities rather than only totals. For each supplier, record the assumed number of templates, content work, integrations, migration, testing, revisions and support.
Mark exclusions clearly. An item left out of one proposal is not necessarily a problem, provided you know who will handle it.
Ask suppliers to explain large differences in scope. They may have identified risks or requirements that another proposal has not considered. Equally, a proposed feature may not be essential to your actual goal.
Avoid asking one supplier to match another's price without first aligning the deliverables. The useful question is whether the proposed work addresses the business need at an acceptable level of complexity.
Reduce scope without weakening the core journey
When the budget is constrained, prioritise the tasks that make the website useful. Clear service information, reliable contact routes, usable mobile navigation and maintainable content are sensible foundations.
Consider deferring advanced integrations or elaborate interactions if they are not necessary for the first release. Record those deferred items so that future development can account for them.
Do not remove testing, content review or essential handover simply because they are less visible than a homepage animation. Those activities help establish whether the site works as intended.
A phased approach should still produce a coherent first release, not a collection of unfinished pages.
Prepare for a more useful quotation discussion
Bring a content inventory, a list of current problems and the workflows that must work at launch. Explain what you can supply internally and where you need help.
360 Design's web development services and web design services cover related but distinct parts of that discussion. A proposal should make the responsibilities clear rather than treating design and development as interchangeable labels.
When you request a project discussion, describe the required outcome and the uncertainties you still need resolved. That is a stronger basis for comparing redesign costs than a page count or a visual reference alone.
Elisha Roodt
Founder and Digital Pioneer at 360Design.org. Leading groundbreaking innovations across Web Development, Virtual Reality, Augmented Reality, 3D Renders, and AI since 1998.
