How to Invoice as an App Developer: Rates, Terms and Templates

TL;DR: Structure app development invoices around sprints or milestones tied to demo-able builds, separate platform-specific work (iOS, Android, backend) on each line, pass through store fees and cloud costs transparently, and bill every two weeks or per milestone to keep cash flow aligned with delivery.

Mobile and backend work benefits from invoices that mirror your backlog: epics, sprints, or fixed phases for MVP → v1 → polish. That helps founders map spend to runway and helps enterprise PMs reconcile PO lines.

TestFlight builds, store screenshots, and analytics are easy to give away—put them in scope documents and invoice line items when they are not complimentary. Backend API work and mobile UI should be separable lines when different sponsors pay for each track. Wear OS or Apple Watch companions are easy to underestimate—if you priced them, list platform explicitly so no one thinks “iOS app” included every screen size by default.

Typical rates

Time and materials with a not-to-exceed cap, fixed-price milestones, or monthly team retainers are common. Apple / Google developer fees and cloud usage may be pass-through or marked up—state your policy. For release-process context that affects timelines, see Apple’s App Store review guidelines when explaining rejection cycles on invoices or statements of work.

Hourly T&M ($100-$200+ depending on stack and market) works for ongoing feature development and bug-fix engagements. Fixed-price milestones suit MVP builds where scope is defined in a product requirements document. Sprint-based billing (every two weeks) aligns with agile workflows and keeps both sides honest about velocity. Monthly retainers ($5,000-$20,000+) work for ongoing product development where you function as a fractional CTO or embedded developer.

Raise rates when you develop platform specialisation (React Native cross-platform, SwiftUI native, Flutter), when you can demonstrate app store success metrics (downloads, ratings, retention), or when your pipeline is consistently booked. Developers with DevOps and CI/CD skills command premiums because they reduce the client's need for a separate ops hire.

Security review or penetration test remediation blocks should be separate milestones so payment is not hostage to third-party schedules you do not control. CI/CD minutes and device farm usage spike near launch—either cap included usage or bill overage. Offline-first or sync-heavy features deserve explicit QA lines—they are not “just another screen” when regression testing doubles. Push notification and deep link plumbing often spans mobile and backend—split the hours honestly so each team lead sees what they are funding.

Sample invoice line items

When to send the invoice

For sprint-based development, invoice at the end of each sprint (every two weeks) after the demo or sprint review. Tying the invoice to a demo-able build gives the client a concrete deliverable to match against the charge.

On fixed-price MVP projects, bill per milestone: typically 30% at kickoff, 40% at beta build, 30% at App Store submission. Adjust the split based on project risk -- heavier upfront payments are appropriate for new clients without a track record.

For ongoing retainers and support, invoice on the first of each month with a summary of tickets closed, features shipped, and hours used. If the retainer includes a bucket of hours, show usage and remaining balance.

Payment terms

Upfront payment for sprint 1, then every 2 weeks or per milestone; Net 30 for signed B2B contracts. Holdbacks rare unless enterprise procurement requires them—mirror their wording. For fixed-price MVPs, tie 30/40/30-style splits to demo-able builds, not calendar months alone. See invoice payment terms.

What to include

Release or sprint ID, features or tickets summarised (readable by non-engineers), hours × rate or flat sprint fee, third-party costs itemised, testing/QA if billed separately, tax, total, due date. Cross-check universal fields via what to include on an invoice.

Note platform (iOS, Android, backend) on each line when one stakeholder only cares about half the stack. Build number or tag references help QA and finance match the same release.

Common mistakes

Single line “development” for $20k—finance teams reject it. Scope creep without change orders. Store submission assumed included—bill explicitly if you handle release management. Currency mismatch on global clients—state currency on every line. Crashlytics or observability spend silently absorbed—either bundle into retainer or invoice transparently. OWASP fixes rolled into “bugs” when they were security scope—label them for audit trails. Feature flags and remote config work hidden under “polish”—they are infrastructure with ongoing cost; show them when you bill setup. App store screenshot or preview video production is marketing labour—either include it in a package explicitly or invoice it separately.

Not separating store rejection rework from normal development -- if Apple rejects the build and you spend 8 hours fixing compliance issues, that is either covered by your submission management line or billed as additional scope; ambiguity here erodes trust. Backend infrastructure costs growing silently without client awareness -- send a monthly cloud-cost summary even when you absorb it in a retainer; surprises at renewal time kill contracts. Failing to note the build number or version tag on each invoice -- engineering and finance need to match the invoice to a specific release; "Sprint 4 development" without a version reference is not auditable.

FAQ

Should I bill for App Store submission and review management? Yes. Managing the submission process -- building the archive, writing release notes, handling screenshots, responding to reviewer questions, and managing rejection cycles -- is real work. Bill it as a flat fee per submission or include it as a named line item in your milestone. Clients who assume "build the app" includes infinite store submissions will exhaust your time.

How do I handle cloud costs that fluctuate month to month? Pass through actual cloud costs with a receipt or cost-explorer screenshot attached. If you prefer predictability, set a monthly cloud budget in the contract and bill a flat amount, with overages billed at cost. Either way, show the cloud line separately from development labour so the client understands infrastructure is an ongoing commitment.

What is the best way to bill a startup with limited runway? Use milestone-based billing tied to demo-able builds so the founder can map spend directly to progress. Avoid Net 30 with early-stage startups -- collect payment before or at each milestone. If the startup runs out of cash mid-project, milestone billing means you have been paid for everything you delivered so far.

Template link

Use the app developer invoice template for milestone and technical line items.

Save sprint summary snippets from your PM tool as invoice memos to reduce copy-paste errors.

---

Join early access to invoice app work without template fatigue.