Billing a Mix of Fixed-Bid Builds and Retainers

Project revenue and retainer revenue behave differently, and conflating them is the most common reason a billing setup falls apart. Milestone payments tied to a fixed-bid build are one-time charges triggered by delivery, not a subscription cycle. Ongoing support, hosting, or a dedicated-team retainer is genuinely recurring. Map every current client to one of those two buckets, plus a third bucket for clients who have both (a build that converted into an ongoing maintenance contract), before you evaluate either platform against your actual book of business.

If your engineers are comfortable maintaining subscription logic, Stripe Billing lets you keep milestone invoices and recurring retainers on the same rails you already use for payment processing. Metered billing works well for retainers priced on hours consumed or API calls served, and one-off invoices for a delivery milestone sit alongside the recurring plan without needing a second system. The catch is that anything nonstandard, a client who wants their retainer paused for two months during a slow quarter, say, or a build-to-retainer conversion mid-contract, usually means someone on your team writing a script instead of clicking a button.

Chargebee is built for exactly the kind of contract amendments that custom software shops deal with constantly: pausing a retainer, converting a project client into a subscription client, or applying a one-time credit against a delayed milestone. Your account managers can make those changes directly without a developer in the loop, which matters more as your client roster grows past what one person can track in a spreadsheet. The cost is a heavier setup and a real monthly fee, so it's a poor fit if you're still running fewer than a handful of active retainer clients.

Median annual recurring revenue growth for private B2B SaaS companies has cooled to 25%¹, which matters for shops whose retainer clients are themselves software companies: their budgets for outside engineering help are tighter than they were a couple of years ago. If you bill primarily by retained hours or a dedicated-team fee, expect more requests to scale a retainer down or pause it, and pick a platform that lets you handle that change without renegotiating the whole contract.

The most common error is forcing a milestone build and a monthly retainer through the same invoice template because it's less setup work. That hides the difference in your own reporting: you can't tell at a glance how much of this month's cash is one-time versus recurring, which makes it hard to forecast next quarter or to explain your revenue mix to a bank or an investor. Set the two up as genuinely separate billing objects from day one, even if it takes an extra hour of configuration now.

Avoid these billing mistakes for a mixed book of builds and retainers:

• Treat a fixed-bid milestone as a one-time invoice, not a subscription with a single billing cycle that the platform will try to renew.
• Keep project revenue and retainer revenue on separate invoice templates, so reporting shows how much of each month is genuinely recurring.
• When a client converts from a project to a retainer, close the project out as a final milestone invoice and start a new subscription for the retainer.
• Let account managers own amendments such as pauses and one-time credits only if the tool lets them do it without a developer.

Not every retainer is a flat number. A dedicated-team retainer might price a junior engineer, a senior engineer, and a part-time architect at three different rates, bundled into one monthly invoice that changes whenever the team composition changes. Building that as a single subscription price hides the mix from your own reporting and makes it hard to answer a client's question about what they're actually paying for each role. The cleaner approach, in either platform, is to model each role as its own subscription item within one customer account, so a swapped engineer or an added architect shows up as a line-item change rather than a manual edit to one lump price. Stripe Billing supports multiple subscription items per customer natively, which covers this case reasonably well once someone sets it up correctly. Chargebee's item-price catalog does the same thing with less custom configuration, which matters if you don't have an engineer free to build and maintain the Stripe setup. Either way, resist the shortcut of one blended number per retainer client: it's faster to set up once and slower to untangle every time a client asks what they're paying for.