The short answer: a business website does not have one honest standard cost because “website” can mean very different things. A focused information site, a content-managed marketing platform, an online catalogue, a commerce journey, a customer portal and a bespoke application have different jobs, risks and ownership needs. A better question is: what must this website help a customer or team member do, and what needs to happen after that action?

For a South African business, a good estimate should translate that answer into visible deliverables. It should make clear what is included, what relies on your team, what depends on third-party services or existing systems, and what needs discovery before it can be defined. That approach is more useful than comparing a headline figure with no context.

The decisions that shape scope

Start with the user journey. Is the main job to explain a service, generate a qualified enquiry, support a campaign, take an order, let a customer access information, or help staff complete a task? Each route creates a different set of requirements for structure, content, forms, permissions and testing.

Content is a major decision. Someone needs to supply, write, review and approve the words, images, product information and policy pages. Content migration can also be work in its own right when an older site contains valuable pages, documents or search visibility that should not be discarded casually. A proposal should say who owns each of these decisions.

Then consider the operating layer. A basic enquiry form and an account portal are not variations of the same feature. A portal may need authentication, user roles, data access rules, integration assessment and a plan for support. An e-commerce flow may involve catalogue data, stock status, fulfilment communication and payment choices. These are reasons to define the hand-off instead of assuming a website ends when a visitor clicks a button.

Technical foundations also matter, but they should be expressed as work rather than vague quality claims. Ask how accessibility, mobile behaviour, performance checks, content editing, redirects, analytics, security responsibilities and backup or hosting boundaries will be handled. A well-scoped project can make these choices visible without promising a universal outcome before the site exists.

How to compare estimates

Compare the proposed work, not only the total. Two documents can use the word “custom” while describing entirely different levels of research, design, content support, integration and testing. Read the inclusions and exclusions closely. Does the estimate state how many journeys or templates are being designed? Does it distinguish content entry from content strategy? Does it identify the environment where the site will run and who controls it after handover?

For an existing business, ask what happens to the current site. A replacement may need a content inventory, redirect plan, new tracking configuration and a careful launch checklist. If leads, orders or account data need to move into another system, the estimate should separate the discovery of feasibility from the implementation of a confirmed connection. API access, data quality, permissions and exception handling can change the work significantly.

Also make support explicit. “Maintenance” can mean different things: software updates, content changes, monitoring, incident response, training, hosting coordination or a retained improvement backlog. A clear proposal says what is included now and what would be considered separately later.

Build a better brief first

You do not need a lengthy specification to request an estimate. Begin with a short description of the business task, the audiences, the current website or process, the systems that may be affected and the decision you need to make. Note any non-negotiables, such as an approval process, a launch event, content owner or data boundary. If the project is still taking shape, say so. “To be discussed” is more useful than a made-up budget range.

Finally, make a decision about the next level of definition. A smaller, clearly bounded website may be ready for a direct scope. A platform with customer data, integrations or operational change may need discovery before an implementation estimate is responsible. In both cases, the goal is the same: a website plan that reflects the work it needs to do and the people who will own it after launch.

Useful official references