The developer has sent a quote you are happy with, and underneath the total is a line that says “advance required to begin”. You are not against paying upfront, but you have heard stories of people who paid most of the money, got a half-built site and then an unanswered phone. Equally, the developer has probably met clients who vanished after the design was approved.
Website development payment terms exist to make both of those outcomes unlikely. Good terms keep each side’s risk small at every stage, so that nobody is ever owed much or owes much. This post explains the usual structures, what each payment should be tied to, and what to settle before the first transfer. It is general information, not legal or financial advice; for anything you intend to rely on, speak to someone qualified.
Why an advance is normal
An advance is not a sign of distrust. It does three practical things for a developer: it confirms you are serious enough to book their time, it covers any early outlay such as a theme licence, and it protects them if you change your mind after discovery and design have been done.
What makes an advance reasonable is its size relative to the work it covers. A modest advance against discovery and design is fair. Most of the total upfront, before anything has been shown, shifts nearly all the risk onto you.
Common website development payment terms, compared
Most small website projects use one of four patterns. None is wrong in itself; each suits a different size and kind of project.
| Structure | How it works | Suits | Watch for |
|---|---|---|---|
| Full payment upfront | Everything paid before work starts | Very small, fixed jobs such as a single landing page from a provider you know | You carry all the risk until delivery |
| Two parts | Advance at start, balance at launch | Simple brochure sites | A long gap between payments if the project stretches |
| Three parts | Advance, then a payment on design approval, then balance at launch | Most small business sites | Clarity on what “design approved” means |
| Milestone-based | A payment tied to each defined deliverable | Larger sites, stores, anything with integrations | Milestones that are vague or date-based |
The more stages a project has, and the more money involved, the more sense it makes to split payments finely. A three-part structure is a sensible default for most business websites because each payment lines up with something you can see.
What a milestone should be tied to
The single most important rule: tie each payment to a deliverable you can check, not to a calendar date.
A date-based schedule (“second payment on the 15th”) goes wrong in both directions. If you are slow sending content, you end up paying for work that is waiting on you. If the developer falls behind, you have paid for work that has not been done. Deliverable-based milestones remove that problem because payment and progress move together.
Good milestones look like this:
- Design approved: homepage and one inner page design shown to you and accepted in writing.
- Build ready for review: all pages in the agreed list built on a staging or preview link, with your content in place.
- Feature working: for example, a test order completed through the payment gateway in test mode.
- Launch: site live on your domain, SSL working, forms tested and delivering to your inbox.
Poor milestones look like “50 per cent of the work complete”, which nobody can measure, or “development phase”, which has no visible end.
Defining “approved” and “complete”
A milestone only works if both sides agree when it has been reached. Two definitions save a lot of awkwardness.
Approval should be something explicit, such as a reply saying “approved” to a specific draft, rather than silence. Some agreements say that if you do not respond within an agreed period the stage counts as approved; that is reasonable, provided the period is realistic for your schedule and you know it is there.
Completion should be measured against the agreed scope. If the page list had six pages and five are built, the milestone is not reached. If six are built and you now want a seventh, the milestone is reached and the seventh is a change. That is why the scope needs to be written down first, ideally in a requirements document both sides have read.
Advance and milestones for different kinds of project
Small brochure sites
Keep it simple. Two or three payments, the last on launch. For a basic five-page starter site (ours is ₹6,999 onwards), more stages than that add paperwork without reducing anyone’s risk.
Online stores
Separate the store from the site. A sensible pattern is advance, design approval, catalogue and checkout working on a preview link, then launch. Payment gateway activation often depends on the gateway’s own review of your business, which neither you nor the developer controls, so do not tie a payment to the gateway going live; tie it to the checkout working in test mode.
Phased projects
If you are launching a core site first and adding features later, treat each phase as its own small project with its own payments. That way phase two can be rescoped, delayed or dropped without leaving phase one’s payments in dispute.
What happens to the money if the project stops
Projects do stop, for ordinary reasons: a business closes, a partner leaves, priorities change. The payment terms should say what happens.
- If you stop the project, you normally pay for work completed up to that point, and the advance is often kept against early-stage work.
- If the developer stops, you should receive everything built so far and a refund of payments for work not delivered.
- Either way, you should get access to the files, the theme, any licences bought for you, and your domain and hosting, which ideally were in your name from the start.
These points belong in a written agreement. Our post on what a website development contract should cover sets out the related clauses.
Payments for changes outside the scope
Almost every project picks up extra requests. Agree in advance how they are priced: a fixed quote per change, or a stated hourly rate, and whether they are billed as they happen or added to the final payment. What matters is that extra work does not quietly get rolled into the next milestone without both sides seeing the number first.
A short written note for each change, saying what it is and what it costs, keeps the final invoice free of surprises. For how scope and price relate in general, the guide to website development cost is the place to start.
Invoices, receipts and tax
Ask for an invoice for every payment, including the advance, showing what the payment is for and which quote it relates to. If the provider is GST-registered, the invoice should show GST separately with their GSTIN. Keep payment confirmations alongside the invoices. If you are claiming input credit or simply keeping clean books, your accountant will want both. This is general information, not tax advice.
Prefer traceable payment methods such as bank transfer or UPI to a business account over cash. It protects both sides if a dispute ever arises.
Balance payment and the launch
The final payment is often the most awkward. The developer may want it before the site goes live; you may want to see it live first. A common compromise is that the site is launched, you check it against an agreed list, and the balance is paid on that check passing. A short pre-launch checklist gives both sides a shared list of what “working” means.
Whatever you agree, write down who controls the domain and hosting during this period. If the developer holds them, a payment dispute can become a hostage situation, which is in no one’s interest.
When the developer is abroad, or you are
Cross-border projects add two practical questions. First, which currency the price is in, and who bears any conversion or bank charges on each transfer; write that down so a payment does not arrive short. Second, how payments are sent, since international transfers and card payments go through different channels with their own charges and paperwork. Your bank can tell you what applies. As before, this is general information rather than advice, and the same milestone logic applies wherever the developer sits.
Whatever the location, the website development payment terms you agree should be in the same document as the scope, so that nobody has to piece the arrangement together from old chat messages.
Before you send the first payment
- Is the scope written down, with a page list and feature list?
- Is each payment tied to a deliverable rather than a date?
- Is it clear what “approved” means and how you give it?
- Is there a stated way to price changes?
- Does the agreement say what happens if either side stops?
- Are the domain and hosting in your name, or will they be?
- Will you get an invoice for the advance?
If all seven have answers in writing, the payment terms are doing their job. If you would like to talk through payment stages for a project like yours, our website development services page is the place to start.
Next in this series: Website Requirements Document: A Template for Owners
