The honest answer to 'how much for a website' is another question, and here is why. Also: how to describe what you want so that any developer can price it properly.
Ask three developers what a website costs and you will get three ranges that do not overlap. That is not evasion. A five-page company site and a system that takes payments, manages stock and has three types of user are both called websites, and they are not the same job. Here is what actually moves the price, so you can judge a quote rather than guess. ## What drives cost **Does it have accounts?** The moment there are users who log in, there are roles, permissions, password resets, and the question of who can see what. That is a significant step up from a site that only presents information. **Does money move through it?** Payments bring gateways, failed transactions, refunds, receipts and reconciliation. All of it has to be right, because being wrong costs real money. **How many kinds of user are there?** A pupil, a teacher, a bursar and an administrator are four interfaces with four sets of permissions, not one interface with a switch. **Where does the content come from?** If you want to change text and images yourself, that needs an admin. Worth it, but it is work. **What does it integrate with?** Every external system, accounting, delivery, SMS, an existing database, is a point of failure that needs handling. **What happens after launch?** Hosting, domains, fixes, and the things that only appear with real users. Anybody quoting a build without this is quoting half the job. ## How to describe what you want You do not need a specification. You need to answer three questions clearly: - Who uses this, and what is each of them trying to get done? - What does the business lose today because it does not exist? - What must be true on launch day for this to be worth paying for? That third one is the most useful question in the whole process. It separates what you need from what you would like, and it is usually the difference between a project that ships and one that drifts. ## Fixed scope or ongoing Two sensible shapes. **Fixed scope**: a defined piece of work, a timeline, a price agreed before anything starts. Good when you know what you want and it will not change much. **Retainer**: continuous work, releasing as you go. Good when the thing will keep evolving, which is true of most systems that run a business. What you want to avoid is the middle: an open-ended project with no defined end, billed by the hour, where neither side can say what done means. ## Questions worth asking any developer - Who owns the code when it is finished? - What happens if I want to change the text next month, do I pay for that? - What exactly is included after launch, and for how long? - Can I see something working before the end, or only at the end? That last one matters more than people realise. Seeing the thing in pieces as it comes together is how you catch a misunderstanding in week two rather than week ten. ## The cheapest project is the one scoped honestly Most expensive projects are not expensive because of the day rate. They are expensive because nobody wrote down what was being built, so it was built twice.