How I scope a website project before quoting.

Most "website development quotes" arrive in a business owner's inbox within an hour of asking. A neat PDF, a number at the bottom, a deadline. It looks professional. It often isn't.

Here's the inconvenient truth: any quote produced in under an hour is a guess. The agency hasn't understood your business, hasn't thought about what your site actually needs to do, and is pricing off a template that ignores everything specific about you. You'll feel that mismatch later — usually six weeks in, when the project starts straining against the assumptions it was built on.

My process takes longer up front, on purpose. Here's exactly how I scope a website project before sending a quote — and why I'd argue this is the part that decides whether the whole project works.

It starts with a discovery call, not a brief

The first conversation is always a structured 30–45 minute call. Not an email exchange, not a form to fill out. A real conversation where I ask questions and listen carefully to the answers.

The reason is simple: most business owners don't know what they actually need from a website — and that's not a criticism. It's just not their job to know. They know the business; the website's job is to support that business. Figuring out what that means in practice is what discovery is for.

The questions I work through aren't standard "what colour do you like" agency questions. They're business questions:

• Who is the website actually for — and what do they need to feel before contacting you?
• What does the site need to do beyond looking presentable? Generate leads? Sell directly? Reduce repetitive enquiries? Educate the market?
• Where is your current website failing — specifically? "We need a new one" isn't a reason; it's a symptom of something more concrete underneath.
• What integrations matter? CRM, payment, booking, inventory, regional tax, accounting — what does the site need to talk to?
• Who will update it after launch? You? A team member? Nobody?
• What's the honest budget range — not the aspirational one, the real one?

About a third of the value of the discovery call is the answers themselves. The other two-thirds is what they reveal — about complexity, about hidden requirements, about whether the project is actually well-defined enough to quote.

The hidden requirements that change everything

Here's what no website template can capture: the things a business owner mentions casually in the third minute of the call that completely change the project scope.

*"Oh, and customers should be able to book a callback."*

*"It needs to handle quotes in three currencies."*

*"My accountant says we need a way to export this to Tally every month."*

Each of those innocent-sounding requirements is a real engineering decision. A "small booking form" might mean integrating with three different calendar systems, handling timezones, sending confirmations, blocking double-bookings. None of that is invisible work — it just looks invisible until you've built it before.

Surfacing these details during discovery is the entire point. If we miss them now, they appear as "scope creep" later — and scope creep is the single biggest reason website projects go over budget, over deadline, and into bad blood between client and agency.

The honest pricing framework

Once I understand what we're actually building, the pricing falls into one of three honest tiers. Real ranges, not aspirational ones:

A few honest notes about these numbers:

The ranges are wide on purpose. Two e-commerce stores can be 3x apart in price because one needs 200 SKUs with simple variants and the other needs multi-vendor inventory with custom shipping logic. The discovery call tells me which one you actually need.

USD pricing is "starting from." Indian agency overhead is dramatically lower than US/UK norms — same quality, much lower base. For US clients, complex projects scale up from the floor, but the value compared to local US agencies is significant.

What's included is consistent across tiers. Design, development, content integration, basic SEO setup, analytics, testing, launch. Hosting and third-party tools (payment gateways, premium plugins) are separate and transparent. No hidden costs — you see everything before signing.

The projects I say no to

Not every project gets a proposal. It's rare, but it happens — and saying no early is far better than taking on a project that's going to be a mismatch.

Most of the time I walk away when one of three signals shows up:

The brief keeps changing every conversation. If the requirements shift fundamentally between the first call and the follow-up email, the project isn't ready to be quoted. We pause, the business owner takes time to clarify what they actually want, and we can revisit later.

The budget and the requirements don't match. If someone wants an e-commerce store with custom inventory and a budget that fits Tier 1, the responsible thing is to say so — not to under-quote and deliver a compromised version. I'd rather recommend a leaner first version that fits the budget than oversell a project that can't be built well at that price.

The client primarily wants the cheapest possible option. There's nothing wrong with being budget-conscious — I respect it. But if the conversation is dominated by "can you do it for less" rather than "is this the right thing to build," the project is going to struggle. Quality work and aggressive cost-cutting pull in opposite directions; better to acknowledge that early.

Walking away is rare. Most projects work out. But the rare "no" protects both sides — the client gets pointed toward something more suitable, and we don't take on work we can't do justice to.

Why this whole process matters

Here's what proper scoping actually buys you, beyond just a more accurate quote:

The price you're quoted is the price you pay. No mid-project surprise invoices because something "wasn't in scope." The hard scoping work has already been done.

The timeline you're given is realistic. No projects mysteriously slipping by 6 weeks because nobody anticipated the integrations.

The final website does what your business needs. Not what the template assumed, not what looked good in a Dribbble mockup — what your real business actually requires.

That's the difference between a website project that delivers and a website project that drags on. It starts with the hour spent before any code is written.

If you're thinking about a website project — new build, redesign, or fixing one that isn't doing what your business needs — this is the conversation worth having. I help businesses figure out what they actually need, and my team at Clazzo Innovations handles the build. Strategy from me, execution from the team. Both, from one decision-maker.