The SaaS Pricing Model Has No Business Being in a Defense Contract

Most founders who come out of enterprise software carry a mental model that gets them into serious trouble when they start selling to the DoD: they assume the government buys the way a Fortune 500 does. Subscription seat licenses. Annual renewals. Usage tiers. A clean ACV that investors can underwrite.

Photo by Jakub Zerdzicki on Pexels.

It doesn't work that way. And the misalignment costs more than most people realize.

Government procurement runs on appropriations cycles, not fiscal quarters. Money is color-coded: operations and maintenance funds, research and development funds, procurement funds. Each color expires on a different schedule and can only be used for specific categories of spend. A software subscription that crosses fiscal years? That's an obligation problem. A usage-based model that charges per API call? The contracting officer may not be able to obligate funds against a number that isn't knowable at the time of award.

Founders hear this and think it's bureaucratic noise they can work around. It isn't. Contracting officers have personal liability exposure on improper obligation of funds. They will not take risks to accommodate a startup's preferred billing structure.

So what does work?

Firm-fixed-price contracts with defined deliverables remain the most reliable vehicle for early-stage defense software companies. You scope a capability, attach a price, and deliver. The government knows exactly what it's obligating. You know exactly what you're building. The tradeoff is that you absorb cost overrun risk, which means your internal cost discipline has to be tighter than anything a typical SaaS startup bothers with.

Time-and-materials contracts are the second common path, particularly for software development and technical services work. T&M gives you flexibility on scope but introduces a different problem: the government is now in your business, watching labor categories and hours. Overhead rates matter. If you haven't set up a compliant accounting system before you land a T&M contract, you're going to have a bad time during the first DCAA audit.

Beyond contract type, there's the question of what you're actually selling. Defense software companies that price by capability delivered rather than by user seat tend to survive the procurement process more cleanly. Think: a delivered software module, a fielded system with defined performance specifications, a data product updated on a defined schedule. These translate into government acquisition language in ways that "up to 500 users, $X per seat per month" simply does not.

The longer-term play, once you're into a Program of Record, is to structure your work around a performance-based logistics or sustainment model. You deliver the capability and charge for keeping it operational and updated. This can generate recurring revenue that looks, from an investor's perspective, a lot like subscription revenue. The difference is that it's grounded in contracts the government actually knows how to execute, rather than a billing model that creates legal ambiguity at the obligation stage.

Here's a rough picture of how the transition tends to flow for companies that get this right:

graph TD
    A[OTA Prototype / SBIR Phase II] --> B(Firm-Fixed-Price Delivery Contract)
    B --> C{Program of Record Entry}
    C --> D[Sustainment & Maintenance Contract]
    C --> E[Follow-on Development Task Orders]
    D --> F((Predictable Recurring Revenue))
    E --> F

The mistake investors make when evaluating defense software companies is importing SaaS metrics wholesale. ARR, net revenue retention, CAC payback period: these are useful proxies, but they distort when the underlying contract structure doesn't match the assumptions baked into those formulas. A company with $8M in firm-fixed-price contracts and a strong pipeline of follow-on task orders can be a substantially better business than a company with $8M in "ARR" structured as subscriptions the government has already flagged as problematic during a legal review.

Due diligence on a defense software company should include a read of at least a sample contract. Look at how revenue is structured, how deliverables are defined, and whether the billing model is actually executable under the FAR. Many founders don't know what they've agreed to. Some investors never bother to find out.

Pricing is strategy. In defense, it's also compliance. Founders who figure that out early build companies that can actually scale through a government customer base without hitting a wall every time a new contracting officer inherits the relationship and decides to reread the fine print.