What Actually Changes a Website Development Quote

Why two quotes for the same website differ by a factor of three

You send the same one-page brief to three agencies in Gurgaon. One comes back with a number. The second comes back with roughly double it. The third is three times the first, and its proposal is the longest of the lot. Nothing about your brief changed between the three emails, so the honest conclusion is that the brief was never the thing being priced. Each agency priced a different imagined website, and the differences live entirely in the assumptions they made where your brief went quiet.

That is the whole story. A quote is a guess about scope wearing the costume of a fact. When you write ‘about ten pages, clean and modern, with a contact form’, one agency reads that as a single layout repeated ten times with a stock form, and another reads it as ten individually designed screens, a custom enquiry flow, and a dashboard where you can read the enquiries. Both are defensible readings of the same sentence, and the second is genuinely three times the work of the first.

The gap is not usually greed. It is not usually incompetence either. It is the compounding of six or seven unstated assumptions, each of which sounds minor on its own, and each of which quietly doubles or halves a slice of the build. Someone assumed you would write the copy. Someone else assumed they would. Someone assumed the site connects to your CRM; someone else assumed enquiries arrive by email and stop there.

So the useful question is never ‘why is this one expensive’. The useful question is ‘what did each of you assume that the other did not’. Ask it directly and the three numbers usually resolve into one number with three different amounts of work bolted to it, at which point you are comparing like with like and can actually choose on merit rather than on the size of the figure at the bottom of page four.

Scope: page count versus template count, and why the second one matters

Almost every buyer describes a website by its page count. Almost every developer prices it by its template count. Those two numbers are not the same number, and the difference between them is the single biggest reason quotes diverge.

A template is a distinct layout: a design and a set of components that gets built once and then filled with different content. A blog with two hundred articles is one template, not two hundred pages of work, because article number two hundred costs nothing to add once article number one has a layout. A five-page brochure site where every page looks structurally different is five templates, and it is genuinely more expensive to build than that two-hundred-article blog even though it looks smaller in every way to the person commissioning it.

Count your templates before you ask anyone for a price. Home is one. An interior content page is one. A listing or index page is one. A detail page (a property, a room type, a product, a case study) is one. A form or enquiry page is one. Contact, with a map and hours, is often one more. Suddenly the ‘forty-page website’ you were describing is a six-template build, and six is a number a developer can actually price without inventing anything.

Here is the arithmetic, framed as an explicit hypothetical so nobody mistakes it for a rate card. Say a template takes eight hours to design, twelve to build responsively, and four to wire into the CMS: twenty-four hours per template. Six templates is a hundred and forty-four hours. Ten templates is two hundred and forty. That difference of ninety-six hours is where two quotes separate, and it is entirely invisible if the conversation stayed at ‘about forty pages’.

Send your template list with the brief. Every quote that comes back will be tighter, and the ones that still vary wildly are varying for reasons you can now interrogate directly rather than guess at.

Template build versus custom build, and the honest case for each

There is a tired argument in this industry that custom is serious and themes are cheap. It is not true, and believing it costs Indian businesses real money every year. Both approaches are legitimate. They just fail in opposite directions, and the skill is knowing which failure you can live with.

A theme or page-builder build starts from a pre-made design system. You are buying somebody else’s solved problems: the responsive breakpoints work, the navigation collapses correctly on mobile, the typography scale is already sane, and the accessibility basics are usually handled. What you give up is exactness. Your brand will bend slightly to fit the theme rather than the theme bending fully to your brand, and every future change happens inside the constraints the theme author decided on years ago.

A custom build starts from your design. Every screen is drawn for your content and your conversion path, and nothing on the page exists because a theme shipped with it. That precision is real and it is worth paying for when the site is your primary sales surface. The cost is that you are now paying to solve the problems the theme had already solved, including the boring ones nobody demos: focus states, print styles, keyboard navigation, what happens when a product title runs to four lines.

The honest split is roughly this. If the website is a credibility layer, a place people check before they call you, a well-executed theme build is not a compromise, it is a sensible allocation of money. If the website is the transaction itself, an e-commerce store, a booking engine, a lead machine where a two percent difference in conversion changes your year, custom earns its price back through control over the exact moments where visitors decide.

Watch for the middle path being sold badly. A heavily customised theme can end up costing more than a custom build while inheriting all of the theme’s constraints, because the team spends its hours fighting the framework rather than building your site. If a quote proposes a premium theme and then lists twenty overrides to it, ask whether the theme is still doing any work for you.

CMS choice, and what it quietly commits you to

The CMS conversation gets treated as a technical detail settled by the developer. It is a business decision with a five-year tail, and it deserves ten minutes of your attention before anyone starts building.

WordPress is released under the GPL and can be self-hosted anywhere, which means your hosting is portable and your content is yours in a database you can copy. That is a real bargaining position at renewal time. The cost is that a WordPress site is a stack of plugins from different authors on different update cycles, and somebody has to own the maintenance of that stack. Nobody enjoys owning it. Everybody needs someone to.

Shopify goes the other way. The platform is hosted for you and the operational burden mostly disappears, which is worth a great deal to a small team without a technical person. Under Shopify’s terms you are licensing the platform rather than owning it, so you trade portability for reliability. For a store doing real volume that is usually a good trade. It is a worse trade for a content-heavy site that happens to sell three things.

A headless build, where the content lives in one system and the front end is built separately, gives you the most control over speed and the widest latitude to redesign without touching content. It also gives you two systems to maintain instead of one, and a much smaller pool of people who can pick up the work if your developer moves on. That last point is underrated and it is the one that hurts eighteen months later.

Ask three questions of any CMS proposal. Where does my content physically live, and can I export all of it. Who can maintain this if you and I stop working together, and roughly how many such people exist in this city. What happens to this site if a plugin, theme or hosting provider in this stack is discontinued. Any developer worth hiring will answer all three without getting defensive, and the quality of those answers tells you more about the next five years than the design mockups will.

Integrations: the cost that hides in the word ‘and’

Integrations are where quotes go wrong most often, because they arrive in a brief as tiny conjunctions. ‘A booking form, and it should go to our CRM.’ Six words. Possibly forty hours of work, possibly four, and the brief gives no way to tell which.

Take a CRM connection. If the CRM has a documented API, a stable authentication method and a field structure that roughly matches your form, the work is a few hours of mapping plus testing. If the CRM is an older on-premise system with an undocumented endpoint, or the client wants leads assigned by locality to different sales owners with a fallback rule for after hours, the same six words in the brief describe a week of work. The words did not change. The work changed by an order of magnitude.

Payments are the same story. Plugging a standard Indian gateway such as Razorpay or PayU into a standard checkout is a solved, quick piece of work, and the gateway’s own per-transaction commercial terms are separate from your build cost. Now add partial payments, a booking deposit that converts to a full amount later, GST invoicing that has to match your accounting system, or refunds triggered by a cancellation rule. Each of those is a real feature with real edge cases, and edge cases are most of the cost of payments.

Booking engines deserve their own warning. A hotel or clinic that already runs a booking system usually wants the website to show live availability, which means the site has to read from that system in real time and handle the moment when the answer arrives late or not at all. What does the page do while it waits. What does it show when the engine times out. Those two questions are the entire difference between a booking integration that works on a bad network in July and one that quietly loses enquiries.

WhatsApp is the most commonly underestimated of the lot. Meta’s WhatsApp Business Platform prices business-initiated messaging per conversation and requires template approval before you can send those messages at all, which means someone has to write the templates, submit them, wait, and handle rejections. That is process work, not just code work. Analytics has the same shape: a tag on the page takes minutes, while properly defined conversion events that survive a redesign take a planning session and a documented event map.

List every integration by name. Next to each, write what it must do and where the data ends up. That single page removes more quote variance than any other document you can produce.

Content readiness, and why an unwritten site blows the timeline

Ask any agency what actually delayed their last three projects. It will not be the code. In our experience the answer is content, every time, and it is worth understanding why a problem that sounds so soft causes so much delay.

A website cannot be finished around content that does not exist yet. Placeholder text hides every real problem: the heading that runs to three lines on a phone, the service description that is two words on one card and ninety on the next, the team section built for six people when you have eleven. Those problems surface the day real copy lands, and if that day is the week before launch, the team is redesigning under deadline pressure with a client who thought the project was essentially done.

Content also has a hidden dependency chain. Photography needs a shoot, which needs a date, which needs the premises to look right, which needs a small refurbishment nobody scheduled. Product copy needs someone who knows the products, and that person is usually the busiest person in the company. Legal pages need review. Testimonials need permission from the customers quoted in them, and chasing that permission takes weeks of gentle emails that nobody put in the plan.

So price the site honestly on this axis. A build where the client supplies final copy and licensed images on day one is a different project from a build where the agency writes, sources and edits everything, and the second is not a small uplift. If a quote does not say which of those it assumes, that is the first thing to clarify, because it is the assumption most likely to be different between two proposals sitting on your desk.

The practical fix is unglamorous. Write the content for your top three templates before the build starts, in a plain document, with real names and real numbers. Everything downstream gets faster and cheaper, and you will discover early which parts of your own story you have not yet worked out.

What you own at handover versus what you are renting

Almost nobody asks this question before signing, and almost everybody wishes they had. A website is not one asset. It is a bundle of assets with different owners, and some of them are on subscription without anyone having said the word.

Work through the bundle. The domain: whose account is it registered in, and is your name on it as registrant. The hosting: your account with the agency given access, or the agency’s account with you as a guest. The design files: do you get the source, or only exported images. The code: do you get a repository with its history, or a zip of whatever was on the server the day you asked. The content: can you export it in a format another system can read, or only as pages on a screen.

Then the licensed layer. Premium themes, plugins, fonts, stock photography and third-party components are typically licensed annually, and the licence often sits with the agency’s account rather than yours. That is not necessarily wrong, and it is frequently cheaper for you in year one. It becomes a problem in year three when you change agencies and discover that four of the things holding your site together renew on somebody else’s card.

Ask it in one sentence at proposal stage, in writing: if we part ways twelve months after launch, what exactly do I walk away with, and what stops working? A good developer answers this cheerfully because they have nothing to hide and they have been asked before. A defensive answer, or a vague one about ‘handing everything over’, is the most reliable warning sign available to you before money changes hands.

Get the answer into the contract as a list. Not a paragraph. A list of named items with a named owner beside each one, because paragraphs are where this argument goes to hide and lists are where it gets settled.

How to compare two quotes that are structured differently

Two proposals arrive. One is a single line and a number. The other is fourteen line items across three phases with an optional retainer at the end. They cannot be compared as written, and the instinct to just look at the totals is exactly how people buy the wrong website.

Normalise them first. Build a simple table with one row per cost driver and one column per vendor, then fill it from whatever each proposal happens to say. The rows that matter are: number of templates, design approach (theme or custom), CMS and hosting, named integrations, who writes the content, who supplies images, revision rounds included, testing and browser scope, post-launch support period, ownership of code and licences, and payment schedule. Nothing else needs a row.

Now the empty cells are the interesting part. Where one vendor has written something and the other has written nothing, you have found either a genuine scope difference or an assumption someone has not surfaced, and both are worth a direct email. Very often the cheaper quote fills up once those emails are answered, and the two numbers converge to within a sensible margin of each other.

Compare on the filled table, never on the totals page. And be suspicious of your own preference for the tidier document, because proposal design is a skill that correlates only loosely with the ability to ship a fast, maintainable website that still works in three years.

What a vague quote is hiding

Vagueness in a quote is rarely accidental. It is a pricing strategy, and understanding it makes you a much better buyer.

A quote with no template count is protecting the vendor from your idea of ‘a few more pages’. A quote with no revision limit will produce a change-order conversation in week six, and that conversation is much harder to have once you have paid a deposit and picked a launch date. A quote with no named integrations is assuming none, and the assumption will surface as a variation the first time you mention the CRM you thought was obviously included.

Watch the verbs too. ‘SEO-friendly’ means the developer will not actively obstruct search engines, which is table stakes and is not SEO. ‘Mobile responsive’ is a description of standard practice in 2026, not a feature. ‘Speed optimised’ means nothing unless it names a target, and there is a published one to name: Google’s Core Web Vitals thresholds of LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, assessed at the seventy-fifth percentile of real page loads. A quote that commits to those numbers is a different document from one that says ‘fast loading’.

‘Post-launch support included’ is the vaguest phrase in the category. Support for how long, covering what, at what response time, and does it include content changes or only bug fixes. Ask, and write the answer down. The difference between thirty days of bug fixes and twelve months of managed maintenance is enormous, and both get written as the same four words.

None of this means a vague quote comes from a bad vendor. Plenty of good developers write loose proposals because clients rarely read tight ones. But the loose proposal is a risk you are carrying rather than one they are carrying, and you are entitled to move that risk back by asking for specifics before you sign anything.

When paying more is genuinely the right call

This piece has spent nine sections teaching you to interrogate a number. It would be dishonest to end without saying that the higher quote is quite often the correct purchase, and here is how to tell.

Pay more when the site carries revenue directly. A booking engine, a checkout, a lead form that feeds a sales team with real quota: on those pages, small differences in speed, clarity and reliability compound every single day the site is live. Consider it as a clearly-labelled hypothetical. If a site takes a thousand enquiries a year and a better-built version converts even five percent more of them into conversations, that is fifty extra conversations annually, repeating every year, against a one-time difference in build cost. The arithmetic usually favours the better build well before year two, and it keeps favouring it afterwards.

Pay more for the boring parts. Accessibility, tested performance against published thresholds, proper analytics instrumentation, a staging environment, version control, documented handover. None of these demo well in a pitch meeting. All of them determine whether the next change to your site takes two hours or two weeks, and you will make changes to your site for years.

Pay more when you are buying judgement rather than execution. If your requirements are genuinely settled and written down, execution is a commodity and you should buy it efficiently. If you are not sure what the site should do, you need someone who will argue with your brief before building it, and that person costs more because that work is harder and rarer than writing the markup afterwards.

Do not pay more for account management theatre, for a bigger slide deck, or for a team size that does not map to anything in the scope. And do not pay less to a vendor who could not answer the ownership question. That one is not about price at all. It is about whether the thing you are buying is actually going to be yours, and no discount is large enough to make that ambiguity a good deal.