How to Invoice as a Web Developer: Rates, Terms and Templates

Web developers often bill implementation sprints, bug-fix buckets, and ongoing retainers. Invoices should separate build phases from hosting, domains, and third-party API fees so clients see recurring versus one-time costs. Staging environments, content migration, and analytics setup frequently get lost in a single “build” line—break them out so non-technical stakeholders understand the bill.

When clients delay content or approvals, your contract should allow pause billing or milestone re-timing—reference that clause on revised invoices if needed. Accessibility remediation and performance budgets are increasingly contract clauses—if you priced them, echo them on the milestone where you shipped the fix. Third-party script audits (tag managers, chat widgets) that bloated Core Web Vitals deserve their own line when you spent days untangling them.

Typical rates

Hourly for support and unclear scope; fixed milestones for launches (design handoff → build → QA → go-live). Maintenance retainers monthly. Benchmarks fluctuate; Stack Overflow’s developer survey illustrates how specialisation affects earning power—use as context, not a quote. Retainer buckets (e.g. “up to 6 hours/month”) should show hours used versus rolled on each invoice to justify renewals. Emergency support can be 1.5× with a minimum increment—state it before the pager goes off. Headless CMS content models and webhook integrations often take longer than visual pages—split them on the invoice so stakeholders see where backend time went.

Payment terms

Deposit (30%–50%) before heavy build, progress invoices per milestone, final before DNS cutover or within Net 14 after launch per agreement. Net 30 for larger clients with good credit. Document out-of-scope work as separate line items. For due-date language, use invoice payment terms. Agency pass-through work sometimes needs client name + parent brand on the invoice header for AP routing—ask your PM contact.

What to include

Project or ticket reference, description per milestone (features shipped, environments), hours and rate if hourly, licences and pass-through (hosting, plugins), support window if selling a post-launch package, tax, total, due date. Use how to write an invoice for numbering and business details. Accessibility fixes beyond the original WCAG target should reference the change ticket or audit finding ID so product understands why hours spiked. Content entry you performed for the client belongs on its own line when it was not part of the build estimate.

Common mistakes

Bundling hosting into dev fees with no renewal date—clients forget to pay. “Bug fix” ambiguity—define severity or SLAs in the contract and summarise on the invoice. No kill fee language for cancelled builds—address in agreement and reflect any partial invoices. Third-party API keys on your card without recharge—pass through or mark up transparently. SEO or analytics tag implementation buried in “launch” when it was half the sprint. Single currency assumed for distributed teams—state USD/GBP/EUR explicitly. Cookie consent or CMP implementations treated as “small JS tasks” when they were multi-sprint compliance work—split legal-driven work on the invoice so privacy teams recognise the effort.

Template link

Start from our web design invoice template for milestone-friendly structure (design plus dev phases).

---

Join early access to generate web project invoices faster.