“How much does a website cost?” is fair to ask and hard to answer honestly without context. A simple marketing site, a store with inventory rules, and an internal tool with several user roles may all be called a website. Their work is different.
Start with the outcome
What should visitors or staff be able to do when the project is finished? Who are those people, and what do they use today? We ask for the few journeys that matter most, then identify which ones must work at launch. A clear first release is easier to estimate than a long feature list with no priorities.
Find the constraints
Existing systems can shape the work more than the new screens do. We ask about data that needs migrating, payment and CRM connections, content ownership, legal requirements, and the people who will maintain the result. We also ask about deadlines and what drives them. A fixed event date calls for a different plan from a flexible roadmap.
Put uncertainty in the estimate
If an integration has no documentation or the old data has not been inspected, a precise price would pretend away risk. We would rather name the unknown, propose a short discovery step, and update the estimate when evidence arrives. A useful quote explains what is included, what is assumed, and how changes will be handled.
That conversation should leave a client better able to compare approaches, even if we do not end up building the project.
