Invoicing for Web Developers: Milestones, Hosting, and Maintenance

Web projects go sideways financially in one predictable way: the site is 90% built, the client has gone quiet on content, and the final invoice is chained to a launch date that keeps sliding. Milestone billing exists to prevent exactly that. Here's how working developers structure deposits, progress payments, maintenance plans, and hosting so the money keeps pace with the work instead of waiting on it.

Milestones Beat Halves

The classic split, 50% up front and 50% at launch, has a flaw: the second half is hostage to a launch date you don't fully control. Three milestones tied to deliverables work better. A common shape is 40% at signing, 30% at design approval, and 30% when the site is ready to launch on staging. Each trigger is something observable that you control the delivery of, never a calendar date and never the word “launched.” On larger builds, add a fourth milestone at development complete. The signing payment does double duty, by the way: it books your calendar and it filters out the clients who were never going to pay. Spell the whole schedule out in the proposal so the first invoice surprises nobody.

The Client Delay Clause

Projects stall because clients stop sending content and approvals, not because developers stop building. The fix is a clause: milestone invoices come due when your work for that milestone is delivered, and if client feedback or content runs more than 30 days late, the pending milestone bills anyway. After 60 days of silence the project parks, and a restart fee applies to bring it back. That sounds stern right up until you've carried a six-week project into its sixth month as an interest-free loan. Clients who know a payment is attached to their own response time find their content remarkably fast.

Final Payment Before Launch

Bill the final milestone when the site is approved on staging, and flip DNS after the payment clears. The same rule covers handing over admin credentials and repository access. This isn't hostility; it's sequencing, the same as any trade that collects on completion before handing over the keys. Your leverage drops to zero the moment the site is live on the client's domain, and every developer who has launched first and invoiced second has learned exactly how long “I'll send it this week” can stretch. If a client needs the site live before they can pay in full, that's fine too: put the remainder on a short written payment plan first, then launch.

Care Plans Turn Launches Into Recurring Revenue

A care plan at $50-250 a month covers updates, backups, security scans, uptime monitoring, and a capped allowance of small content edits, usually 30-60 minutes. Define the exclusions in writing: new features, new pages, redesigns, and integrations get quoted separately. The plan is also your scope-creep pressure valve, because “can you just quickly add” requests now have a home: inside the allowance, done; beyond it, quoted. Bill plans as recurring invoices on the first of the month, and price the no-plan alternative honestly: your full hourly rate, with a response time of whenever you can fit it in.

Hosting and Domains: Pass Through or Mark Up

Two workable models. The clean one: hosting and domain accounts belong to the client, billed to their card directly, and you administer them with delegated access. No middle-of-the-night liability, no markup conversation. The profitable one: you resell managed hosting at $25-60 a month bundled into the care plan, and you own the 2am problem when the host has one. Both are legitimate. What isn't legitimate is registering the client's domain under your own account, which turns every future disagreement into a hostage negotiation. The domain is the client's name on the internet, and it belongs in their name from day one.