Website design cost depends on what the finished site must do, what already exists and who supplies the work. Two proposals for the same number of pages can describe very different projects. A useful comparison separates discovery, design, development, content, migration and ongoing ownership. For how I agree scope, payment and ownership on my own projects, see my terms of business.
Discuss your projectSee selected work
This guide provides a way to structure that comparison. It does not present fictional prices as my packages or claim a universal market rate. For a project estimate, the starting point is a representative catalogue or page set and a defined customer task.
The scope decisions that change the price
| Cost area | Question for the proposal | Common missing dependency |
|---|---|---|
| Discovery | Which decisions and prototypes are included? | Unresolved requirements are assumed to be simple |
| Design and templates | How many distinct layouts and states are covered? | Mobile, empty and error states are omitted |
| Content and catalogue | Who prepares copy, images and structured data? | Data cleanup is treated as a free import |
| Integrations | Which systems exchange which fields? | Unavailable APIs or account permissions |
| Release | What migration, testing and rollback work is included? | Launching is reduced to changing a domain setting |
| Ownership | What training, support and documentation follow? | Ongoing licences and maintenance are excluded |
Count distinct page types rather than treating every URL as a separate design. Twenty product pages can share a template, while one complex product may require several custom states. Similarly, a small site with bespoke business-system integration can require more engineering than a larger brochure site.
What changes ecommerce website development cost?
An online shop build covers how the catalogue works, not just how it looks. Variants, trade accounts, price rules, shipping limits, search, filters and who owns stock all change the scope. Find out which come with the platform, which need setting up and which need custom work.
A product configurator adds another set of inputs: option rules, visual assets, validation and a commercial handoff. Keep those visible rather than hiding them inside “interactive product page”. The configurator cost guide explains those drivers separately.
Moving an old site can be a big job too. Product IDs, images, old URLs and redirects all need matching up. An import that says “success” does not prove the new site has the right data or that key journeys still work.
An illustrative budget calculation
The following arithmetic is a teaching example, not a quote, rate card or market benchmark. Suppose a scoped project contains 20 hours of discovery, 30 of design, 70 of development and 30 of testing and migration. That is 150 hours. At an assumed £60 per hour, the labour allowance is £9,000.
If the example also assumes £600 in one-off assets and £900 in first-year licences, the model totals £10,500 before any tax, hosting or ongoing support not already included. Change one input and the total changes. The value of the model is that the assumptions can be challenged.
A contingency should be tied to a named risk. A stock system with no documentation is a reason to look into it and hold time in reserve. Adding a percentage to every quote without saying why does not make the estimate reliable.
Comparing website and ecommerce packages
Packages can make a standard job easier to buy. They are hard to compare when “custom design”, “SEO included” or “unlimited revisions” are not defined. Ask what you actually get for each phrase, and how you will know it is done.
For example, does SEO include preserving redirects, editing metadata, creating a page-intent map, validating structured data or writing all product descriptions? Does a revision mean adjusting an approved layout or replacing the whole creative direction? A clear line protects both sides.
Compare the same time horizon. A lower build fee with compulsory recurring licences may cost more over the period you expect to use the site. Include foreseeable maintenance and the cost of routine changes, while keeping optional future phases separate.
Write an ecommerce website brief
A brief should make the buying journey, catalogue and day-to-day operation clear enough to scope. A list of attractive websites is useful context, but it does not say how stock reaches the shop, which products need special rules or what a release must prove. Download the editable ecommerce brief (.txt), complete what you know and leave genuine unknowns visible. It is platform-neutral, so it works for a Shopify or WooCommerce discussion.
- Business problem and baseline: “we need a modern website” could mean poor mobile browsing, hard catalogue maintenance or an unsupported platform. Record dated evidence and define the primary conversion, excluding test orders and spam.
- Testable requirements: turn “better discovery” into “a customer can filter compatible products using agreed attributes”, and “reliable integration” into an update that reaches the shop with visible failure handling.
- Representative products: ten complex products can need more work than hundreds of simple ones. Bring a standard product, one with variants or dependencies and a discontinued item.
- Sources of truth: name the system and approver for product IDs, descriptions, images, prices and stock. For each integration, name the sending and receiving systems, trigger and recovery owner.
- Ownership split: the business signs off product details, claims, payment, tax, delivery rules and scope. The developer sets the checks, builds and tests, and writes down how to roll back.
Sort each requirement into essential at launch, priced separately, or out of scope, and include internal content work and third-party costs. Share a budget range and the reason for the target date so a proposal can describe a realistic first phase. For example, a retailer with 120 products handling trade enquiries by email might launch with clear categories, accurate stock, retail checkout and a separate trade-enquiry route, and price customer-specific trade pricing as a later phase. That is illustrative, not a client case. Finish with handover: who owns the domain, hosting and platform accounts, who edits content, and what training and support follow. Never put passwords, customer exports or API keys in a brief.
See also: web design and build, and the Velune, ProSalonFurniture and Soinvogue projects.
Reduce avoidable work before reducing quality
Prepare a small but representative content set, name one decision owner and agree what must launch. Reuse page layouts where you can, and test the riskiest system link early. Those steps reduce rework without removing essential testing or accessibility.
Decide who owns product data before design starts, not after. A beautiful template full of messy product details is still unfinished. Use the project brief to record responsibilities and the maintenance guide to clarify ongoing care.
Request a scoped website proposal with the current site, required customer journeys, catalogue examples and desired launch constraints. A useful estimate should make clear what is included, what remains uncertain and how the result will be accepted.