These are examples to help you compare deliverables, not fixed packages. Your written proposal defines what is included, who supplies each input and how the work will be reviewed.
One campaign or offer, a clear page structure, responsive design and a tested enquiry or registration route. Supply the offer, brand assets and approved content; agree separately on copywriting, advertising, extra variations and integrations.
A homepage, agreed service pages, relevant work and contact journey. Decide whether your team needs a CMS and who prepares the copy and imagery. Extra services, languages, custom workflows and ongoing updates change the scope.
An agreed theme approach, catalogue structure and checkout or product-enquiry journey. Product data, photography, app subscriptions, payments, migration and merchant training need explicit responsibilities; they are not automatically part of every build.
Content readiness affects both the schedule and the amount of design iteration. A clear sitemap and approved product or service information give us something concrete to design around. If writing, photography or catalogue cleanup is needed, identify it before comparing quotes.
Custom page layouts, editing controls, product variants, booking rules and connections to other systems require different levels of work. We agree the essential launch scope and separate later improvements so the first release can be tested as a complete journey.
A redesign also needs an inventory of existing URLs, content and useful search entry points. Reusing a design does not remove the work of checking redirects, forms, mobile behaviour and handover.
The proposal should distinguish one-time design/development from domain renewal, hosting, platform subscriptions, paid themes, apps and external services. Payment processing and operational tools can have their own charges. Confirm current fees with the relevant provider before committing.
Ongoing edits, monitoring, new features and support are separate scope decisions. Confirm who owns each account, who pays renewals and what happens after launch. Payment milestones, tax treatment and any support period belong in the written proposal rather than an assumed package.
Share your audience, intended next step, existing site, likely pages, content readiness and any systems the website must connect to. A preferred launch date is useful context; explain what it depends on. You do not need to choose a technology before we talk.
We clarify the requirements, list deliverables and exclusions, and describe the review and handover process. Before approving the build, compare the proposal against the same brief you gave other providers. Ask how additional requests will be handled and which decisions are needed from you.
Page count is only one input. Content preparation, unique layouts, editing, integrations and testing can change the work substantially. Share the brief so we can define comparable deliverables.
No. We are based in Ahmedabad and prepare a proposal around each project. This page explains how the scope is formed; it is not a rate card.
We can discuss a focused first release where the core journey works end to end. Later features should be listed separately, with their dependencies and cost considered before they are added.
