How Long a Website Takes to Build in India

The estimate you were given and the date you will launch are two different numbers

Ask three studios how long a website takes and you will get three ranges. A simple site in a few weeks. A business site with a handful of templates in a month or two. A catalogue with a payment flow, longer than that. None of those answers is dishonest, and none of them answers the question you were actually asking.

An estimate measures the studio's working days: design, build, revise, test, launch. Your question is about the calendar on your wall, the one with a date on it you have already mentioned to somebody. The two match only if everything the build needs from you arrives on the day it is needed. It does not arrive on that day, and the gap between the two numbers is usually larger than the estimate itself.

That gap is what this page is about. Not how fast a team can work: the half of the schedule that sits on your side of the table, in the order it blocks the work, and what each stall adds to the calendar. Almost nothing that delays a website is about code.

Two clocks run, and only one of them is in the quote

A quote is written in effort. It counts working days of design and development, and it assumes those days run one after another. That assumption is the whole problem, because effort days only run back to back if nobody is waiting for you.

The elapsed calendar is effort plus waiting, and the waiting is not evenly spread. It clusters at a handful of specific moments, every one of which is a moment when somebody on the build is holding a question that only you can answer.

Project planners call the longest chain of dependent tasks the critical path: the sequence that decides the finish date, where a day lost is a day lost on the whole project. On a small website, the critical path almost never runs through the hardest piece of engineering. It runs through a decision somebody has to make, an account somebody has to find the password for, and a photograph somebody has to take.

Here is the arithmetic. It is arithmetic, not a measurement of your project, and it is worth doing on paper before you commit to a launch date.

A modest site has somewhere around a dozen points at which work stops until you answer: the scope, the sitemap, the first design, the revised design, the text for each group of pages, the photographs, the policy wording, the domain and DNS credentials, the final sign-off. Answer each of them by the next working day and those pauses add up to roughly two and a half weeks of calendar. Answer in three days and the same twelve pauses are seven weeks. Answer in a week and they are nearer three months. The build did not change. Your reply time did, and it was multiplied by twelve.

A good team overlaps what it can: while a design decision sits with you, somebody is building something that does not depend on it. But a decision cannot overlap with the thing it decides, and once two or three of them are outstanding at the same time, there is nothing left to bring forward. The precise total is not the point. The point is that your reply time is multiplied by the number of times you are asked, and that line appears in nobody's quote.

For what it is worth, this is why we quote one phase at a time rather than a whole project. Each phase is scoped in writing before work starts, and you see working software as it is built. A total for a project that has not been scoped yet is a guess wearing a number, and the thing it is guessing about is mostly you. The same problem on the money side, and why a published range cannot price a project nobody has scoped, is in website development cost in India.

The seven things only you can unblock

They are listed here in the order they gate the work, which is not the order they appear in a proposal. The first four can all be done before you have signed anything, and a week spent on them before the project starts is the cheapest week in the whole schedule.

Week zero: the domain, the DNS and the hosting login

This is the least interesting item on the list and the one most likely to move your launch date by a month, because it is the only one with a published waiting period attached to it.

Four facts have to be established, and the answer to all four is often "the person who built the last site". Which registrar holds the domain. Whose name is in the registrant field. Who can log in and change the DNS records. Where the site is hosted today, and who pays that bill. A WHOIS lookup gets you the registrar and the expiry in a few seconds, and a DNS lookup shows you the nameservers and the mail records that are live right now.

Then there is the trap. If the registrant on the domain is not you and has to be changed to you, ICANN's Transfer Policy says at II.C.2 that "the Registrar must impose a 60-day inter-registrar transfer lock following a Change of Registrant". Correct the ownership and the domain cannot move to another registrar for two months. Move it first and the ownership stays wrong for the length of the move. Either order is survivable; discovering the choice exists in the week you meant to launch is not.

Two more numbers from the same policy, for planning rather than for alarm. A transfer between registrars is not instant: at I.A.3.5, a registrar of record that fails to respond within five calendar days produces a default approval, so a clean transfer is a week of elapsed time even when nobody obstructs it. And at I.A.3.7.5 a transfer may be refused when it is "requested within 60 days of the creation date", so a domain somebody registered for you last month cannot be moved this month.

DNS has its own lag, and it is one you control in advance. Cloudflare's DNS documentation defines it plainly: "Time to Live (TTL) is a field on DNS records that controls how long each record is cached and as a result how long it takes for record updates to reach your end users." A record sitting on a one-day TTL takes up to a day to stop pointing at the old server after you change it. Lower the TTL on the records you are about to move several days before the switch, not on the morning of it.

If some of this is already a problem, the long version is getting your website back from a previous developer, which works through all eight accounts in the order that actually unlocks them. Start it now rather than in the week before launch: nothing else on this page can be finished until the domain answers to you.

Week zero: one page that says what the site is for

A brief does not need to be long and it does not need to be a specification. It needs to say what the business does, who the site is for, what you want a visitor to do, what has to connect to what, and who signs things off.

The reason it belongs in week zero rather than week two is that everything downstream is priced and designed against it. A gateway or an accounting integration discovered halfway through is the usual cause of a revised quote, and a revision is not only a different number: it is a pause while the number is agreed. Writing a software brief that gets an accurate quote sets out the eight questions and how much detail each one needs. It is an afternoon of work, and it is the single highest-leverage afternoon in the project.

The line in it that saves the most calendar is the last one: the name of the person who decides. Not the committee. One name.

Weeks one and two: the text, which is slower than it looks

Every published timeline mentions content in a clause and budgets nothing for it. It is the stall that stops everything, and it stops everything for a reason that has nothing to do with writing.

Writing the text is not the slow part. Deciding what it says is. What exactly do you sell and in what order. Which of those four services are you actually still doing. Do you publish what you charge or ask people to enquire. Which products were discontinued last year and nobody told the website. What is the one sentence a stranger should read first. A page cannot be finished around answers that do not exist yet, and placeholder text hides the problem instead of solving it: the layout gets approved against Latin filler, and then the real heading turns out to be twice as long, one product has forty words of description and another has four hundred, and the design comes back for a round nobody planned.

A usable rule for a small-business site is to allow a fortnight of elapsed time for text and to start it in week zero, in parallel with everything else. A page of final copy per working day is a comfortable pace for somebody who also has a business to run, and it is a pace that collapses if the writing is the last thing on the list every evening. If nobody internally is going to do it, say so at the brief stage rather than at the design stage, because that changes the plan rather than interrupting it.

The photographs are a separate project with their own calendar. A shoot is a booking, a day, and a round of selection, and none of that compresses. Find out early whether what you have is usable at all: a logo that exists only as a small image lifted from the old site will not survive being placed at the top of a new one, and a product photograph taken on a phone in a storeroom reads exactly as it was taken. Once you have the files, preparing images for the web covers the three steps that keep them sharp without making the page slow, and the image resizer handles the resizing in a browser without uploading anything.

The middle weeks: approvals, and what a reply time really costs

Two rounds of revision on a design stage is normal, planned for, and not where the time goes. The time goes into the elapsed days between the work being sent and the answer coming back, and three habits stretch those days more than any other.

Feedback by committee. Four people see the design, three of them reply, two of them disagree, and the project waits while that is resolved internally. The resolution is work, it is real, and it is on your side of the line. Name one approver who collects the opinions and sends one answer.

Feedback in instalments. A note on Monday, two more on Wednesday, a change of mind on Friday. Each one restarts the round. One message at the end of a round moves faster than five messages during it, even when the end of the round is later.

Reopening a settled decision. Changing the navigation after the templates are built is not a revision, it is a new phase, and it is the most expensive thing a client can do with a sentence. If a settled decision turns out to be wrong, say so immediately rather than at the next milestone: the cost of reopening it rises every week it stays closed.

Two things make rounds cheap. Put a date on each one when it is sent, in the same message, so that silence is visible rather than ambiguous. And use the working build for what it is for: a build you look at as it grows produces small corrections continuously, which is a different and much cheaper thing than a single large reaction at the end.

Before launch: the policy pages, and a gateway that cannot start until they are live

If the site takes money, this is the step that catches people out, because the sequencing is not obvious until you are in it.

The policy pages are not a writing task, they are six decisions: your refund window and what it is measured from, what you will not refund, when the customer receives what they paid for, what you charge and what tax sits on top, who answers the phone and between what hours, and your exact legal entity name as registered. Website requirements for a payment gateway works through each page, in build order, with what it has to contain.

Now the part about the calendar. A gateway application asks for the live URLs of those pages. Razorpay's documentation for adding your business website lists the fields, and notes that when you add or update your primary website, "instant checks are run to validate your website, policy pages and business industry". You cannot pre-apply. The gateway's clock starts the day your pages are live, which means it starts after the build, not during it.

The gateway itself is rarely the delay. Razorpay's own account setup documentation describes assisted onboarding with activation "within 8 business hours". What costs weeks is arriving at the application with nothing ready: the identity documents not gathered, the policy decisions not made, the pages not written. All three can be done in week zero, in parallel with the build, by somebody who is not a developer. Almost nobody does them in week zero.

One sequencing rule, because it has a long tail: open the gateway account in the business's name, with your own identity documents, not the developer's. A gateway account is tied to a verified identity and cannot simply be reassigned later.

The week after launch is not the launch

Going live is a switch. Being found is not. Google's own guidance on asking for a recrawl states that "crawling can take anywhere from a few days to a few weeks", and that a sitemap "can be very helpful if you just launched your site".

So plan the week after launch rather than treating it as free time. Verify Search Console and submit the sitemap, which needs the DNS access from item one all over again. Watch the live site rather than the staging one. Run the website health checker over the real domain for the certificate, the redirects, the headers and indexability in one pass, and fix what it finds while the people who built it are still on the project.

A calendar with your rows filled in

This is the shape of the client side of a small-business build: a handful of pages, a contact form, perhaps one payment flow. The dates on the build side belong in your written scope, because they depend on what is being built. The rows below do not depend on that at all, which is exactly why they can start before anything is signed.

Read it as a list of things to finish early rather than as a promise about length. Every row that is already true before the build starts is a row that cannot delay it.

The week before you sign

Eight things, none of which needs a developer, all of which can be done while you are still choosing one.

1. Find out who owns your domain. Run a WHOIS lookup and read the registrar and the registrant. If the answer is a surprise, start fixing it today, because that is the item with the sixty-day lock.
2. Log in to the DNS yourself, once. Not "we have the details somewhere". Open it, see the records, close it.
3. Write the one page. What the business does, who it is for, what a visitor should do, what it connects to, and who decides.
4. Name the approver. One person, with the authority to say yes, who will be in the country for the next two months.
5. Start the text now. A page a day, beginning before the project does. Mark the pages where you genuinely do not know what to say, because those are the real schedule risk.
6. Audit the pictures. Open your logo at full size. Look at your product photographs on a large screen. Decide now whether a shoot is needed, because that is a booking, not a task.
7. Make the six commercial decisions if you will be taking money, and gather the identity documents into one folder while you are at it.
8. Put a reply time in the agreement, in both directions. Studios are asked for turnaround times constantly and clients are almost never asked for theirs. A line saying that feedback arrives within two working days, in one message, from one person, is the single most effective schedule clause available to you, and it costs nothing to agree in the week when everybody is pleased with each other.

Start here

1. Look up your domain today and find out who holds it and whose name is on it.
2. Write the one-page brief, and put the approver's name at the bottom of it.
3. Open a document for the text and write the homepage into it this week.
4. Check whether a photographer is needed, and if so, book one now rather than in week four.
5. Ask whoever quotes you which decisions they will need from you, and when, and write those dates next to your own.

The honest answer to "how long will this take" is that the build is quotable and the calendar is not, because the calendar is a joint production. A team that is never waiting on you is quick. A team that waits a week at twelve different moments is not slow; it is blocked, and the difference matters because only one of those is something you can fix.

If you would rather hand the whole sequence to somebody who has run it before, including the domain, the DNS and the policy pages, that is ordinary work for us: web application development for a new build, website fixes and maintenance for a site that already exists and needs the ownership sorted out. The first call is free and it is mostly us asking the questions on this page.

Either way, do step one today. It is the only item here that can quietly cost you two months.