Web development has a billing trap built into the work itself: the project is never visibly "done." A plumber leaves and the leak is fixed. A developer finishes the build and the client says the site is not really finished until it is live, and not really live until they have tweaked the homepage copy twice, and by the way can the contact form also route to Slack? Meanwhile the final invoice sits unpaid because, in the client's mind, the project is still open.
The second trap is control. The finished product lives on a server, under a domain, behind credentials, and whoever holds those holds the leverage. A developer's invoice has to define when the project is done, who owns what, and in what order payment and go-live happen.
The quick version
- Bill fixed-price builds in milestones tied to demos, not calendar dates: deposit to start, a payment at design approval, and a final payment at launch.
- Make the trigger for each milestone invoice something the client clicked through on a staging link, so "done" is provable.
- Every mid-project "can it also do X" becomes a change order billed as its own line item, quoted before you build it.
- Pass through domains, hosting, plugins, and stock assets as separate lines, at cost or with disclosed markup.
- Collect final payment before go-live: the site deploys to production and credentials transfer after the last invoice clears, and the invoice says so.
- After launch, bill one-off fixes hourly with a minimum increment, and ongoing work as a monthly care plan.
Milestone billing tied to demos, not dates
Most site builds are quoted as a fixed project fee, structured as a deposit plus two or three milestone payments. Collecting money before any work starts is non-negotiable on project work; see deposit invoices and upfront payments for how to structure that first invoice.
What makes milestone billing work for developers is what you attach each milestone to. Calendar-based milestones ("30% on March 15") fail because web projects slip, usually while waiting on client content. Demo-based milestones fix this: each payment is triggered by something the client can see and click.
A common structure for an example $8,000 marketing site:
- Milestone 1 (30%, $2,400): due on signing, before any work begins.
- Milestone 2 (40%, $3,200): due when the client approves the design and a working staging build of the core pages. You send the staging URL with the invoice.
- Milestone 3 (30%, $2,400): due at launch readiness, before production deployment.
Each milestone description should reference the demo: "Milestone 2 of 3: staging build of homepage, services, and contact pages, approved by client 4/22." That one sentence turns a payment dispute into a link the client already clicked. The mechanics of splitting and sequencing milestone invoices are covered in how to invoice by milestones.
Add a stalled-project trigger to every milestone schedule. If the client disappears for weeks on content or approvals, you should not wait with them: "Milestone invoices become due 14 days after the associated demo is delivered, whether or not client feedback has been provided."
What the line items look like on a site build
Here is a realistic final invoice (Milestone 3) for that example $8,000 site, with a change order and pass-throughs picked up along the way:
| Description | Qty | Rate | Amount |
|---|---|---|---|
| Milestone 3 of 3: content migration, cross-browser QA, production deployment (per proposal #1042) | 1 | $2,400.00 | $2,400.00 |
| Change order CO-2: blog category filtering, approved 5/14 | 1 | $600.00 | $600.00 |
| Premium form plugin, annual license (pass-through, registered to client) | 1 | $99.00 | $99.00 |
| Stock photography licenses (pass-through at cost) | 6 | $12.00 | $72.00 |
| Domain registration, 1 year (pass-through) | 1 | $14.00 | $14.00 |
| Total due | $3,185.00 |
Why it is structured this way:
- The milestone line references the proposal number. The invoice does not re-argue scope; it points at the document that defined it.
- The change order has its own line and ID. The client sees exactly what the mid-project addition cost.
- Pass-throughs are itemized, not buried. Lumping a $99 plugin into "development" invites the question "what am I actually paying for?" Itemizing kills it.
- "Registered to client" appears on the plugin line. License ownership is a real dispute point in web work; put it in writing at the moment of billing.
Third-party costs: domains, hosting, plugins, stock
Almost every build accumulates third-party costs: domain registration, hosting, premium plugins or themes, stock photos, maybe a transactional email service. Developers handle these one of two ways, and both are fine as long as the invoice is honest about which one you chose.
At cost, client-owned. You buy it in the client's name (or have them buy it), bill it through as a pass-through line at the exact price, and the client owns the account. Cleanest for domains especially: a client whose domain is registered under the developer's account is one bad breakup away from a hostage situation.
With markup, disclosed. Some developers add a handling margin, say 15%, for sourcing and managing licenses, or resell hosting they manage at a bundled monthly rate. Common industry practice, but disclose it: "Plugin licenses billed at cost plus 15% procurement fee" in your terms beats a client discovering the retail price later. The general rules for receipts, markup, and billable cost lines are in how to invoice expenses.
Whichever model you use, keep renewals out of project invoices. A domain renewing next year belongs on next year's care-plan billing, not as a surprise line on the final build invoice.
Scope creep: every "small tweak" is a line item
Web projects attract scope creep because changes sound free. "Can the header shrink on scroll?" costs the client one sentence and costs you an afternoon. The defense is procedural, not confrontational: anything outside the written proposal gets a short written quote (even two lines in an email), and once approved, it appears on the next invoice as its own numbered line, like CO-2 in the example above.
Clients stop making casual requests once each one comes back with a number attached, and the requests that survive are the ones they actually value. The full workflow, including quoting and approval wording, is in how to bill change orders.
After launch: hourly fixes vs a monthly care plan
Post-launch work splits into two billing models, and mixing them up is where income leaks.
One-off fixes bill hourly, with a minimum. A broken contact form or plugin conflict is reactive work that interrupts other projects, so it carries a minimum billing increment: commonly a 1-hour minimum per request, then 30-minute increments, invoiced monthly with a short log line per task ("6/12: debugged checkout redirect after plugin update, 1.5 hrs").
Ongoing responsibility bills as a care plan. Updates, backups, uptime monitoring, security patches, and a small monthly bucket of content changes fit a flat monthly retainer, invoiced automatically on the 1st. An example structure: $150/month covering updates, backups, monitoring, and up to 2 hours of changes, with extra hours billed at your standard rate. Defining what a retainer covers, and what happens to unused hours, is covered in how to bill a retainer; automating the monthly invoice is covered in the recurring invoices guide.
The care plan is also your answer to the client who expects free support forever because "you built it." The build invoice ends the build; the care plan or hourly minimum prices everything after.
Launch-day terms: payment before go-live, and the handoff line
The most protective habit in web development billing is sequencing: final payment clears, then the site goes live. Once the site is on the client's production domain, your leverage is gone and the final invoice becomes a donation request. Put the sequence in the invoice notes:
"Final payment is due before production deployment. The site will be deployed to the live domain within 2 business days of payment. Upon receipt of final payment, all source code, CMS admin credentials, and hosting access transfer to the client."
That second sentence, the source-code and handoff line, confirms the client gets everything (no code held hostage after payment), and that they get it only after payment. If you retain any rights, such as reusing generic components you built, or a footer credit link, state it here too. Offering an online payment option on this final invoice also speeds up the one payment that blocks launch: invoices with online payment options get paid up to twice as fast (Xero, 2024).
If you want a starting point that already has the milestone structure, pass-through lines, and notes field laid out, the free web development invoice template pre-fills the editor with a developer-style invoice you can edit and download as a PDF, no signup needed, with multi-currency support for overseas clients and e-signature if you want the change-order approval on the document itself.
Frequently asked questions
Should the client buy their own domain and hosting, or should I bill it through?
Have the client own the domain in their own registrar account whenever possible; it avoids any perception of lock-in and removes you from renewal liability. Hosting can go either way: client-owned with you as an admin user, or developer-managed and rebilled monthly as part of a care plan, with any markup disclosed in your terms.
What if the client delays launch after the site is finished?
Do not let the final milestone float until a go-live date the client controls. Use a launch-readiness trigger: the final invoice is issued when the site is complete and approved on staging, due within 14 days, whether or not the client has launched. Go-live then happens after payment, on their schedule.
How do I bill tiny post-launch requests without nickel-and-diming the client?
Use a minimum increment (commonly 30 or 60 minutes per request) and batch small items into one monthly invoice with a one-line log per task. If a client generates more than a couple of requests a month, move them to a care plan; it is cheaper per task for them and predictable revenue for you.
Do I need to charge sales tax on web development work?
It depends on your state and how the work is categorized: some states tax digital goods or software services, while custom development labor is often treated differently. The rules vary by state, so verify yours; do freelancers charge sales tax explains how to find out and how to show tax on the invoice.