Development hours
Per hour
Feature work, bug fixes and technical tasks billed by time spent.
Sprints · Retainers · Support
Create Professional Developer Invoices
Software work is billed in shapes that clients do not always recognise: sprints, hours, fixed-scope builds, support retainers and the infrastructure that runs underneath.
The generator opens with development line items in place — sprint work, review and deployment, and a maintenance retainer — ready to edit and download as a PDF.
Loaded with developer line items you can edit, rename or remove.
A developer's invoice bills for engineering time and the deliverables it produced: features shipped, systems integrated, bugs resolved or ongoing maintenance provided. It often covers a billing period rather than a single job, because software work continues across months.
The challenge is legibility. A client sees a working product, not the hours behind it, so invoices that name the features, tickets or sprint periods are approved far faster than invoices that state a number of hours and nothing else.
Sprint, hourly, fixed scope or retainer — matching whatever the engagement agreed.
Features, integrations or ticket references rather than internal technical shorthand.
New development, maintenance and incident response are different budgets on the client's side.
Hours spent shipping and coordinating are chargeable when the agreement says so — list them, don't bury them.
Hosting, APIs and licences as separate expense lines, ideally owned by the client's own accounts.
A one-paragraph summary of what shipped, plus the PDF, makes approval a formality.
Per hour
Feature work, bug fixes and technical tasks billed by time spent.
Per sprint
A fixed period of capacity, usually one or two weeks, at an agreed rate.
Project fee
A defined deliverable specified up front and invoiced on completion or by stage.
Per hour
Review, release management and deployment support around the build itself.
Per month
Ongoing updates, monitoring and a defined response commitment.
At cost
Infrastructure, APIs and licences paid on the client's behalf.
A month of sprint work with deployment support, a maintenance retainer and a passed-through service cost.
| Description | Qty | Rate | Amount |
|---|---|---|---|
| Sprint work — checkout feature build (hrs) | 40 | 110.00 | 4,400.00 |
| Code review and deployment support (hrs) | 4 | 110.00 | 440.00 |
| Monthly maintenance retainer — April | 1 | 500.00 | 500.00 |
| Hosting and error monitoring (expense, at cost) | 1 | 128.00 | 128.00 |
| Subtotal | 5,468.00 | ||
| Tax (10%) | 546.80 | ||
| Total due — Net 30 | 6,014.80 | ||
Monthly or per sprint, on the same date. Predictable invoices get budgeted for; irregular ones get queried.
Company clients often cannot pay without it. Ask for the PO before the work starts, not after the invoice bounces.
A short list of delivered features turns an approval into a two-minute read for a non-technical manager.
Scoping, estimating and architecture are the highest-value hours you spend. Charge for them.
'40 hours development' invites scrutiny. Name the features or tickets those hours produced.
Silently absorbing extra hours on a fixed-price build rewards under-scoping and erodes your rate.
Services on your card become an unbilled subscription. Pass them through or transfer the accounts.
A retainer with unlimited scope becomes an unlimited obligation. Define included hours and response times.
Sprints suit ongoing product work with a predictable cadence, hours suit ad hoc tasks, and a fixed price suits a clearly specified build. All three can appear on the same invoice when a month contained all three.
One line naming the month and what the retainer covers — for example response times, security updates and a block of included hours. Work beyond the included hours goes on a separate line at your standard rate.
Yes, when they are part of the engagement. These hours are real and often invisible to the client, so name them explicitly rather than absorbing them into feature work.
List each service as its own expense line at cost. Where possible, have the client own the accounts directly, so a cancelled engagement does not leave you paying their infrastructure bill.
Distinguish warranty fixes covered by the agreement from new work. Fixes to what you built are usually included for an agreed period; changes to requirements are chargeable and belong on their own line.
As a paid piece of work with its own deliverable, such as a technical specification or estimate. It protects the time spent scoping and gives the client something of value even if the build never starts.
Edit the line items, add your details and download a clean PDF. Free, no account and no watermark.