Two website quotations can promise the same outcome, show very different totals and still be impossible to compare. One may include discovery, copy support, mobile testing, redirects, analytics and post-launch help. Another may list “complete website” but leave every one of those items undefined. The price difference is visible; the risk difference is hidden.
The direct answer is to stop comparing quotations as single numbers. First convert them into one shared scope worksheet, then compare deliverables, responsibilities, assumptions, ownership, testing and support line by line. A Delhi business should know what will exist at launch, who supplies each input, how acceptance works, what remains recurring and what happens when the scope changes.
This guide provides an illustrative, price-free worksheet for that process. It is not a Web Solution Centre quotation, a universal contract or legal advice. It is a practical way to ask clearer questions before choosing a website partner. If you need a team to estimate an actual brief, review the Web Solution Centre website and share the project facts rather than asking for an unexplained “best price.”
The direct comparison method
Begin with a short business brief that every shortlisted agency receives unchanged. Ask each supplier to respond against the same headings. Then transfer the answers into a comparison sheet. This reverses the usual process: instead of letting each agency define a different project and then comparing totals, you define the decision and ask each agency to show how it will deliver it.
A useful comparison has four passes:
- Normalize the scope: list the pages, templates, functions, content, integrations and non-functional requirements that matter.
- Expose responsibilities: mark what the client supplies, what the agency creates and what needs a third party.
- Separate build and running costs: distinguish one-time work from licences, hosting, maintenance, content and future changes.
- Score evidence and risk: assess relevant work, clarity, testing, ownership, handover and exclusions—not sales language.
Why the lowest quotation may not be comparable
A website is a bundle of decisions, not a commodity with one standard specification. A five-page brochure site built from approved copy is different from a five-page site requiring positioning workshops, original copy, photography direction, CRM integration, multilingual content and lead tracking. Counting pages alone hides the work.
Low quotations are not automatically poor, and higher quotations are not automatically better. A supplier may work efficiently, reuse a suitable system or need less discovery because your brief is unusually complete. The problem begins when the lower number depends on assumptions you have not seen: one design revision, client-written copy, stock imagery, no migration, no event tracking, no accessibility review, shared licences or support ending on launch day.
The same applies in reverse. A high quote should not receive a premium merely because it includes fashionable labels. Ask what research will be performed, which outputs you will receive and how each output changes the build. “Strategy” should result in decisions such as audience priorities, navigation, content hierarchy and conversion paths. “Technical SEO” should become crawlable links, indexation controls, metadata, structured data where appropriate, redirects and measurable quality checks—not a keyword spreadsheet left outside the website.
Build a one-page scope worksheet
Before contacting agencies, complete the following twelve fields in plain language. If an answer is unknown, write “to be discovered” rather than guessing. The worksheet is a decision aid, not a specification designed to eliminate expert advice.
- Business goal: the decision or action the website should help, such as qualified enquiries, catalogue discovery, appointment requests or dealer applications.
- Primary audiences: who they are, what they need and any important differences between buyers, partners, recruits or existing customers.
- Current website: its platform, approximate content volume, known problems and whether analytics or Search Console access exists.
- Required page types: home, service, category, product, project, article, location, contact, policy and any logged-in areas.
- Required functions: forms, search, filters, payments, bookings, calculators, downloads, portals, chat or integrations.
- Content responsibility: who supplies, writes, edits, translates, approves and enters text, photographs, video and downloadable files.
- Brand inputs: logo files, colour and type rules, examples to preserve, and whether identity work is inside or outside scope.
- Technical requirements: platform constraints, hosting, email, CRM, ERP, payment gateway, analytics, consent and security needs.
- Quality requirements: target devices, supported browsers, accessibility level, performance checks and testing expectations.
- Migration and SEO: URLs to preserve, content to move, redirects, metadata, structured data and measurement continuity.
- Timeline and approvals: genuine launch dependency, internal reviewers, feedback turnaround and unavailable periods.
- Handover and support: ownership, administrator access, training, documentation, warranty and ongoing maintenance needs.
If budget boundaries are real, disclose a range or a maximum alongside priorities. A supplier can then recommend a viable first phase instead of quietly removing essentials. WSC’s guide to website designing cost in Delhi explains why the final investment changes with scope, content, integrations and ongoing responsibility; it should not be used as a substitute for a project-specific brief.
Compare the actual website scope
Discovery and information architecture
Ask whether discovery is a call, a workshop or a research phase, who attends and what it produces. Useful outputs may include audience priorities, a sitemap, user journeys, feature decisions and content gaps. If the quotation includes wireframes, identify which page types receive them and how many feedback rounds are included.
Look for a connection between discovery and the eventual interface. A catalogue website may need category and search behaviour defined before visual design. A professional-services site may need service relationships, proof and enquiry routes. Review comparable work in the agency’s website design portfolio, but judge the relevant decisions—not whether another client’s colours match yours.
Pages, templates and functions
“Twenty pages” is ambiguous. Twenty manually designed pages, twenty content entries using four templates and twenty migrated URLs represent different work. Request a list of unique templates and an estimated content-entry count. For every function, describe the complete user outcome. A contact form needs fields, validation, spam handling, recipient rules, confirmation, storage policy, tracking and failure behaviour.
Integrations require even more precision. Name the system, account owner, data exchanged, direction of sync, authentication method, test environment and party responsible when the third-party service changes. “CRM integration included” is not enough to predict delivery.
Content, images and migration
Mark each content task as client, agency or shared. Copywriting may mean editing client drafts, interviewing subject experts or producing complete pages. Photography may mean image selection, art direction or an actual shoot. Migration may include copying text but exclude cleaning HTML, remapping downloads, preserving author/date fields or redirecting old URLs.
Ask how approval works and who bears the schedule impact when content is late. A strong plan can launch priority pages first, but it should not hide placeholder copy or publish claims nobody has checked. Content should help the intended visitor complete a task. Google’s people-first content guidance similarly emphasises usefulness, original value, clear authorship and trust rather than pages produced mainly to attract search traffic.
Responsive design and accessibility
Every modern quotation may say “mobile responsive,” so ask how it will be accepted. Which phone, tablet and desktop breakpoints or representative devices will be checked? Are menus, forms, tables, pop-ups, videos and third-party embeds included? Will text resize, keyboard navigation, focus order, colour contrast, labels and error messages be reviewed?
If accessibility matters, put a target in writing. The W3C describes WCAG 2.2 as an international standard organised around perceivable, operable, understandable and robust content, with testable success criteria at A, AA and AAA. A quotation should state the intended level, testing method and exclusions. “Accessible design” without a standard or validation plan is difficult to accept.
Search readiness and measurement
SEO scope should distinguish initial website hygiene from an ongoing search programme. A build can include crawlable navigation, clean URLs, titles and descriptions, canonical tags, robots controls, an XML sitemap, image alt text fields, redirects and accurate structured data. It cannot honestly guarantee rankings.
Google’s developer guide for Search asks sites to be secure, fast, accessible and functional across devices, and recommends tools such as URL Inspection and the Rich Results Test. Ask whether the supplier will configure the agreed basics, preserve existing URLs and connect analytics/Search Console accounts you control. For a migration, use a documented website redesign SEO checklist rather than treating redirects as a post-launch repair.
Performance, security and privacy
“Fast website” needs a measurement context. Ask whether tests use representative mobile conditions, production hosting and realistic content. The current Core Web Vitals are LCP, INP and CLS; web.dev documents “good” thresholds of at most 2.5 seconds, 200 milliseconds and 0.1 respectively, assessed at the 75th percentile for field classification. Those thresholds are useful targets, not a promise that every test or user will produce the same value. The official Core Web Vitals methodology is a better reference than an unexplained “100 performance score.”
Security scope should reflect risk. A brochure site, ecommerce store and customer portal need different controls. At minimum, identify software updates, TLS, backups, administrator access, form protection, secrets, logging and restore responsibility. For applications handling accounts or sensitive data, ask what verification standard or testing basis will be used. The OWASP Application Security Verification Standard provides an open basis for testing technical security controls; mentioning it is useful only when the quotation names an appropriate level or concrete requirements.
Use a like-for-like comparison table
Create one row for every material requirement. Replace vague ticks with a short status: included, excluded, optional, client-supplied, third-party or unclear. Add a reference to the quotation section and a question owner. The compact example below is illustrative.
| Comparison area | What to record | Evidence or acceptance test | Risk if unclear |
|---|---|---|---|
| Discovery | Sessions, participants and outputs | Approved sitemap and priority journeys | Design begins on untested assumptions |
| Design | Unique templates and revision rounds | Approved desktop and mobile layouts | Extra layouts become change requests |
| Content | Writing, editing, entry and migration owners | Page inventory with approval status | Launch stalls or uses placeholder copy |
| Functions | Detailed user and administrator behaviour | Scenario-based acceptance tests | “Included” feature does not meet the workflow |
| SEO | Metadata, redirects, sitemap, schema and tracking | Crawl and analytics launch checks | Visibility or measurement breaks at launch |
| Quality | Devices, browsers, accessibility and performance | Named test matrix and issue threshold | Disagreement about what “finished” means |
| Handover | Accounts, code, files, training and documentation | Access checklist signed off | Supplier dependency after final payment |
| Support | Warranty, maintenance, response and exclusions | Support route and service boundaries | Routine fixes become unplanned costs |
Do not force every supplier into identical technology. A good agency may recommend a better route after discovery. Compare whether that route meets your outcomes and constraints. If you are deciding between a managed content system and a tailored build, the WordPress versus custom website comparison can help you separate platform trade-offs from agency preference.
Read the commercial structure carefully
A clear quotation separates the project total into understandable phases or deliverables without forcing you to reverse-engineer the work. It also identifies taxes, payment timing, validity period and the conditions for invoices. The aim is not to demand an hourly breakdown for every creative decision. It is to see what event earns each payment and what happens if either party delays an input.
Separate one-time and recurring items
Record hosting, domain renewal, premium plugins, fonts, stock assets, email services, security tools, payment-gateway fees, SMS services, maintenance and support separately. Note who contracts with each provider and whether the price can change outside the agency’s control. A low build price paired with locked, recurring dependencies may have a higher ownership cost than a larger transparent build.
Read the change-control rule
No brief predicts every decision. A fair change process explains how a new request is described, estimated, approved and scheduled before work begins. It should distinguish correction of work that fails agreed acceptance criteria from a new requirement. Beware both extremes: “everything is included” without boundaries and a quotation so rigid that small clarifications trigger conflict.
Identify assumptions and exclusions
Assumptions can be useful because they expose the conditions behind the price. Examples include timely client feedback, one language, a fixed number of content entries, existing brand assets or access to a documented API. Exclusions should be equally visible. Move any exclusion that matters into the main comparison rather than leaving it buried in notes.
Confirm ownership, access and handover
Ownership is more than a sentence saying “website belongs to client.” List the things you need to operate independently: domain registrar access, hosting control, DNS access, source code, design source files, database, media originals, CMS administrator account, analytics, Search Console, tag manager, payment accounts, licences, backup location and deployment documentation.
Domain control deserves particular attention. ICANN explains that the registrant is the person or entity that registers a domain and manages its settings through the registrar. Its information for domain registrants highlights access to registration, management, transfer, renewal and restoration processes. Your business should know the registrant identity, renewal route and recovery contact; an agency can manage the domain without becoming an invisible single point of failure.
Clarify intellectual-property terms for custom code, licensed components, fonts, photographs and third-party themes. A supplier cannot transfer rights it does not own. Ask which items are assigned, licensed, open source or subscription-based, and whether any licence is tied to the agency’s account.
Test timelines and acceptance criteria
A timeline should show dependencies, not just a launch date. Useful milestones include discovery sign-off, sitemap, wireframes, visual design, content readiness, development, integration testing, user acceptance, migration, launch and post-launch checks. Each milestone needs an owner and a realistic feedback period.
Acceptance criteria turn subjective phrases into decisions. “Responsive” becomes a named device/browser matrix. “Form works” becomes successful validation, delivery, confirmation, spam handling and analytics events. “Migration complete” becomes an agreed URL inventory, content check and redirects. Define the severity of defects that block launch and a process for lower-priority issues.
Evaluate the team, not just the document
Choose two or three relevant projects and ask specific questions: What constraint shaped the design? How was content organized? Which part was hardest to test? What did the client need to supply? Public pages demonstrate visible work, but they do not prove private results, budgets or the precise role of every vendor. Treat claims of traffic or conversion improvement as evidence only when the measurement, period and attribution are explained.
Check whether the team challenges unsafe assumptions respectfully. A supplier that explains why a requested animation may harm mobile usability, why a login needs additional security work or why a deadline requires phasing is doing useful commercial work. Agreement with every request is not the same as expertise. If you want a scoped discussion, use WSC’s website project enquiry route with the worksheet details prepared.
An illustrative Delhi business example
Imagine a Delhi industrial supplier requesting quotations for a catalogue website. Its first brief says only: “modern website, 100 products, enquiry form and SEO.” Agency A proposes a lower total using one product template and client-supplied data. Agency B proposes a higher total that includes taxonomy discovery, spreadsheet cleanup, part-number search, category filters, product migration, redirect mapping, analytics events and staff training.
Those are not two prices for the same website. The worksheet reveals the real decisions:
- Are the 100 product records already complete and consistently named?
- Does search need exact part-number matching, partial matching or synonyms?
- Which filters matter, and who defines the source values?
- Does every product need a downloadable technical sheet?
- Should enquiries identify the product and route to different sales teams?
- Are old product URLs receiving search visits that need redirects?
- Who owns data entry after launch, and what training is included?
The buyer may choose either route. If product data is clean and internal staff can load it, Agency A may be appropriate. If the taxonomy and migration are the hardest parts, Agency B may reduce operational risk. The correct decision comes from priorities and evidence, not from declaring one total universally “cheap” or “expensive.”
Common quotation mistakes
Sending different briefs to each agency
Casual conversations produce different assumptions. Send one base brief, allow clarification and circulate any material answer to all shortlisted suppliers. You are comparing solutions to one problem, not testing who guesses your expectations.
Using a feature count without defining outcomes
“Blog, gallery and WhatsApp” says little about administration, moderation, measurement, accessibility or privacy. Describe the user and business outcome for every feature that affects effort.
Assuming content is a final-week task
Content affects navigation, templates, proof and search intent. Name owners and deadlines early. Do not approve layouts filled with placeholder text if the real content may change the page structure.
Accepting “SEO-friendly” as a deliverable
Request the actual build checks and separate them from ongoing strategy. A technical SEO service may extend beyond launch into crawling, indexing, structured data and monitoring, but the quotation should say where the build ends and continuing work begins.
Ignoring post-launch access
Confirm accounts and handover before the last milestone. Recovering a domain, analytics property or source repository after a relationship changes is harder than setting ownership correctly at the beginning.
Negotiating only by deleting invisible quality work
If the total exceeds the budget, prioritize phases. Removing accessibility review, testing, redirects, backups or handover can make the number smaller while leaving the business with larger launch risk. Reduce breadth before removing basic quality controls.
Final decision checklist
- Every supplier received the same current brief and answered the same clarification questions.
- Pages, templates, content entries and functions are distinguished.
- Client, agency and third-party responsibilities are marked for each major item.
- Content writing, migration, data cleanup, image work and approvals have named owners.
- Mobile, browser, accessibility, performance and security expectations are testable.
- SEO launch tasks, redirects, analytics and Search Console responsibilities are explicit.
- One-time, recurring and optional costs are separated, with taxes and licence ownership clear.
- Payment milestones correspond to reviewable outputs or delivery events.
- Assumptions, exclusions, revision rounds and change-control steps are visible.
- Domain, hosting, CMS, code, data, design files and measurement-account access are covered.
- Timeline dependencies include your team’s content and approval commitments.
- Acceptance, warranty, support, maintenance and escalation routes are defined.
- Relevant portfolio evidence was checked without treating unverified results as fact.
- The chosen approach fits the business goal, internal capacity and acceptable risk—not merely the lowest total.
Conclusion
The best website quotation is not necessarily the cheapest, longest or most technical. It is the one that gives your business a credible route from its current problem to an agreed launch, with responsibilities, boundaries and ownership clear enough to manage.
Use the scope worksheet before asking agencies to price. Normalize each response into the same comparison table. Question vague inclusions, expose recurring dependencies, define acceptance and make handover part of the project—not an awkward request after payment. Then choose the team and approach that best fit the work you actually need.
Sources
- Google Search Central: Creating helpful, reliable, people-first content
- Google Search Central: Get started with Search — a developer’s guide
- W3C Web Accessibility Initiative: WCAG 2 overview
- web.dev: How the Core Web Vitals thresholds were defined
- OWASP: Application Security Verification Standard
- ICANN: Information for domain name registrants

