How to invoice as a web developer

Web and software work has its own billing shape: big build projects with clear stages, ongoing maintenance that never really ends, and a steady stream of “can you just add…” requests. Invoice it the way the work actually runs and you’ll get paid faster and argue less.

Pick the right billing model

Three models cover almost everything developers do, and most freelancers use more than one:

Fixed price per milestone — best for defined builds where the scope is clear (a marketing site, a Shopify theme, an API integration). You quote a total and bill it in stages as you hit them.
Hourly / time-and-materials — best for discovery, vague scope, or open-ended work. You bill the hours you actually log. Keep a timesheet so every invoice line traces back to real, dated hours — that’s what stops “why is this so much?” queries.
Monthly retainer — best for maintenance, support, hosting, and “keep the lights on” work after launch. See how to set up a retainer.

Fixed price rewards you for being efficient; hourly protects you when the scope won’t hold still. Pick per project, not per career.

Structure a build project: deposit + milestones

Don’t fund the client’s project out of your own bank account. For a fixed-price build, split it across milestones and take money before, during, and at the end. A common split is 30 / 40 / 30:

30% deposit on signing — work doesn’t start until it’s paid.
40% at build / sign-off — e.g. when the core build is approved on staging.
30% on launch — due before you deploy to production and hand over.

Each milestone is its own invoice with its own due date, so you’re never carrying weeks of unpaid work. Tie deliverables to payment, not just to dates: “deploy to production” is a milestone, “two weeks have passed” is not.

Bill maintenance as a recurring retainer

Once a site is live it needs updates, security patches, backups, hosting, and the occasional fix. Bundle that into a monthly retainer billed in advance rather than chasing tiny ad-hoc invoices. It gives the client a predictable cost and gives you predictable income — and it’s far less admin than invoicing every small task. Define what the fee covers (hours or response time) and what falls outside it.

What to put on a developer invoice

Beyond the standard invoice fields, make a dev invoice self-explanatory:

A project or sprint reference (and PO number if the client uses them) so it routes to the right budget;
Milestones reached or hours logged — itemised, with the timesheet behind the hourly lines;
Pass-through expenses broken out separately — hosting, domains, third-party licences, paid plugins, SaaS or API costs. Mark whether they’re at cost or with a handling margin, and agree that up front;
The total and any tax, plus clear payment details.

Spin one up with the invoice generator.

Payment terms — and protecting yourself

Set explicit terms (e.g. NET 14) and read payment terms explained if you’re unsure what they mean. Protect yourself with two habits: handover and production deployment happen on final payment, not before — you keep the leverage until the invoice clears — and everything is in a contract. The AI contract generator covers scope, milestones, IP transfer on payment, and what counts as out of scope.

Bill change requests separately

The fixed price covers the agreed scope — full stop. Every “while you’re in there, can you also…” is a change request, quoted and invoiced on its own. Saying so politely up front (“happy to — that’s outside the current scope, I’ll send a quick quote”) keeps a friendly relationship from quietly eating your margin.

Get the structure right and most invoices pay themselves. For the few that drift overdue, Duefy chases them automatically so you can stay in the editor instead of the inbox.