Pricing models for defense software: FFPIF, T&M, cost-plus, and SaaS in government contracts

Selling software to a defense ministry is not like selling software to a commercial enterprise. Commercial buyers sign a subscription, activate a trial, and decide within a quarter. Government buyers operate under the Federal Acquisition Regulation (FAR), the Defense Federal Acquisition Regulation Supplement (DFARS), and a set of pricing principles that determine not just how much a vendor gets paid, but whether the contract is even legal. The pricing model -- the contract type -- is not a billing preference; it is a legal instrument that allocates cost risk between the government and the contractor, triggers audit obligations, and shapes what the vendor is incentivized to do. A software company that approaches defense procurement with a commercial pricing sheet and no understanding of FAR Part 16 will either lose to competitors who do, or win on terms that become financially damaging during execution. This article covers the main pricing structures in use for defense software today, where each type is appropriate, and how modern SaaS subscription models fit into frameworks that were written before cloud computing existed. Readers building a contracting strategy should also review the full defense procurement lifecycle from RFP to signed contract for context on how pricing type is negotiated during source selection.

Why commercial pricing models break in defense contracting

A commercial software vendor typically offers a menu: per-seat license, consumption-based API pricing, or an enterprise flat fee. The price is published, the buyer accepts the terms, and the contract is a subscription agreement governed by the vendor's standard terms of service. Government buyers cannot operate this way. The government is bound by the Truth in Negotiations Act (TINA, now codified under 10 U.S.C. 3702 and 41 U.S.C. 3503), which requires contractors above the simplified acquisition threshold to certify that their proposed prices are based on current, accurate, and complete cost or pricing data when adequate price competition does not exist. This means a vendor selling a sole-source software capability to a defense agency must open its cost structure -- labor rates, overhead, profit -- to government scrutiny, not just name a price.

Beyond transparency, the government's budget process creates constraints that have no commercial equivalent. Defense appropriations are annual. A contract funded from a single fiscal year's Research, Development, Test and Evaluation (RDT&E) appropriation cannot be paid from Operations and Maintenance (O&M) funds. Software that begins as a development effort (RDT&E-funded) transitions to a sustainment effort (O&M-funded) at a specific program milestone, and the pricing structure of the contract often has to change at the same time. A flat annual SaaS fee does not naturally map to these fund types, which is why government contracting officers frequently restructure vendor commercial pricing into contract line item numbers (CLINs) that align with appropriation categories. Understanding this constraint is prerequisite to structuring any defense software pricing proposal that will survive the contract negotiation phase.

The third structural difference is competition law. The Competition in Contracting Act (CICA) requires the government to obtain full and open competition unless a specific sole-source justification is documented. Most recurring software subscriptions are re-competed or placed against existing contract vehicles -- IDIQ contracts, GSA Schedules, or OTAs -- rather than awarded as standalone sole-source agreements. Each vehicle has its own pricing rules, and the vendor's pricing model must conform to whatever was pre-negotiated in the base vehicle, not to the vendor's commercial price list.

Firm Fixed Price and FFPIF: when fixed pricing works for software

Firm Fixed Price (FFP) is the government's preferred contract type. FAR 16.202 states that FFP should be used when contract risk is minimal or when the contractor can reasonably estimate cost. The contractor is paid the agreed price regardless of actual costs incurred. If the contractor delivers for less, it keeps the margin. If it overruns, it absorbs the loss. For well-defined, stable-requirements software work -- a specific data integration module, a defined UI component set, or a migration of a legacy system to a new platform -- FFP is appropriate and commercially familiar. The challenge is that software requirements are rarely stable enough for true FFP to be fair to either side.

Firm Fixed Price Incentive Fee (FFPIF), governed by FAR 16.403, adds a sharing mechanism. The parties negotiate four parameters: a target cost, a target profit (fee), a ceiling price, and a share ratio. If the final cost is below target, the contractor earns more than target profit in proportion to the underrun, up to a maximum fee cap. If the final cost is above target but below the ceiling, the contractor earns less than target profit. Above the ceiling, the contractor bears 100% of overruns -- the ceiling becomes a de facto FFP cap. This structure is well-suited to software development engagements where the general scope is clear (a specific capability, a defined integration boundary) but the effort estimation carries moderate uncertainty. The government gains cost reduction incentive without requiring full cost transparency during execution; the contractor retains upside if its engineering team is efficient. For companies navigating defense pricing and compliance obligations, FFPIF is often the pragmatic middle ground between pure fixed-price risk and the administrative burden of cost-reimbursement accounting.

A critical practical point: FFP and FFPIF require a realistic basis of estimate (BOE) at proposal stage. A software team that has no history of tracking labor hours against deliverables will struggle to produce a credible BOE. Government cost analysts will compare proposed labor rates and hours against historical data in their databases and challenge outliers. Vendors new to government contracting often underbid FFP contracts to win, then discover that the fixed price does not cover the actual cost of meeting government-specific security, documentation, and testing requirements that were implicit in the performance work statement but not costed in the proposal.

Time and Materials: appropriate use and audit exposure

Time and Materials (T&M) contracting, governed by FAR 16.601, is the contract type closest to how commercial software development services are typically priced: the contractor bills hourly rates for labor categories plus cost of materials at no markup (or with a negotiated materials handling rate). The government pays for the hours actually worked, up to a not-to-exceed ceiling price. T&M is appropriate when neither the government nor the contractor can define the work scope with enough precision at contract award to price it as a fixed-price effort. Legacy system maintenance, where the volume of defects is inherently unpredictable, is a textbook T&M use case. Rapid prototyping phases under a research agreement, where the requirements evolve daily, are another. Emergency software support following a cybersecurity incident, where the government needs contractor hours immediately and cannot wait for a detailed SOW, is a third.

The audit exposure of T&M contracts is substantial. FAR 16.601(c) requires the contracting officer to determine that no other type is suitable before authorizing T&M, and contracting officers are audited on this determination. Because T&M provides no cost-reduction incentive -- the contractor's profit on labor is embedded in the fixed hourly rate and does not change with efficiency -- the Defense Contract Audit Agency (DCAA) scrutinizes T&M billings closely. Auditors review whether billed labor hours are supported by contemporaneous timekeeping records, whether the labor category billed matches the labor category of the actual person who worked, and whether any hours billed were for work outside the contract's statement of objectives. Contractors without a DCAA-compliant timekeeping system will encounter billing disputes, withholds, and potentially allegations of fraudulent billing under the False Claims Act. For any defense software company expecting to use T&M vehicles, establishing a compliant timekeeping system before the first task order is a prerequisite, not an afterthought.

Government buyers increasingly push contractors off T&M toward FFP or hybrid structures as programs mature. A task order that starts as T&M during initial discovery is expected to transition to a fixed-price delivery order for the production phase. Contractors who resist this transition -- preferring the revenue predictability of hourly billing -- signal to the government that they cannot estimate their own costs, which is a competitive disadvantage in follow-on procurements. The most defensible T&M strategy is to use the T&M phase to build a labor-hour history that then supports a credible FFP BOE for subsequent work.

Cost Plus structures: CPFF, CPAF, CPIF and their software implications

Cost Plus contracts reimburse the contractor for all allowable, allocable, and reasonable costs incurred, plus a fee. They are used when the work is too uncertain or too technically risky for the contractor to bear fixed-price risk, and when the government needs the work done by a specific contractor despite the cost uncertainty. Three variants are relevant to defense software: Cost Plus Fixed Fee (CPFF), Cost Plus Award Fee (CPAF), and Cost Plus Incentive Fee (CPIF).

CPFF (FAR 16.306) pays a fee that is fixed at contract award as a percentage of the estimated cost, typically 6--10% for development work. The fee does not change based on actual cost performance. CPFF is the most common cost-reimbursement type for early-stage defense software research and development: the government gets the work done, the contractor recovers costs and earns a modest fee, and neither side benefits from inflated cost. The downside is that CPFF provides no incentive for cost efficiency -- the contractor earns the same fee whether the project runs at estimated cost or 40% over. Government program managers on CPFF contracts must manage cost through active oversight and earned value management rather than through financial incentives in the contract itself. Understanding the full lifecycle cost of CPFF and sustainment is addressed in depth in the analysis of total cost of ownership for defense software.

CPAF (FAR 16.305) adds an award fee pool on top of a base fee and reimbursed costs. The award fee is evaluated periodically -- typically every six months -- by a government Award Fee Determining Official (AFDO) who scores the contractor on criteria defined in the award fee plan: technical performance, schedule adherence, management effectiveness, and similar qualitative measures. The AFDO's determination is not subject to the disputes clause, making CPAF uniquely powerful for the government as a performance management tool. For software development programs where quality of execution matters as much as cost -- delivering secure, well-documented, interoperable software -- CPAF aligns contractor incentives with the government's non-cost priorities in a way that pure CPFF cannot. The risk to the contractor is that AFDO evaluation can be subjective, and a contractor who believes it performed well may receive a poor fee score with limited recourse.

Hybrid contract structures for phased software development

Real defense software programs rarely fit cleanly into a single contract type for their entire lifecycle. A typical trajectory moves through three phases: a high-uncertainty design and prototype phase, a better-defined development and integration phase, and a mature sustainment and operations phase. Each phase has a different risk profile, and each warrants a different pricing structure. Hybrid contracts -- contracts with multiple CLINs priced under different contract types -- allow the government and contractor to apply the most appropriate pricing type to each phase without requiring a full re-competition at each transition.

A common pattern is a phased hybrid with a CPFF CLIN for the initial design phase (say, six months), followed by an FFPIF CLIN for the core development delivery (twelve months), and a T&M CLIN with a not-to-exceed ceiling for the first year of sustainment maintenance. Each CLIN has its own period of performance, obligated funds, and acceptance criteria. The government retains the option to negotiate the FFPIF terms for the development CLIN after reviewing the design phase output, rather than having to price the development work with full precision at the time of the original award. This is sometimes structured as a contract with options, where the base period covers the CPFF design phase and the option periods cover subsequent FFP or FFPIF deliveries, each exercisable after the government reviews the preceding phase's output.

Software Acquisition Pathway (SWP) programs under DoDI 5000.87 formalize this phased approach within the DoD's acquisition framework. SWP programs are encouraged to use iterative delivery cycles with fixed-price delivery orders against an IDIQ base contract. The IDIQ establishes the contractor's qualifications, rates, and terms; individual delivery orders define specific software increments with fixed-price deliverables. This allows the program to absorb requirement changes between delivery orders without contract modification, while maintaining the cost discipline of fixed pricing within each increment. For defense software vendors, winning a position on an SWP-aligned IDIQ is often more commercially valuable than winning any single delivery order, because it provides a multi-year channel for recurring task orders without re-competition at the order level.

SaaS subscription pricing in government contracts: IDIQ, BPA, and OTA paths

The defense establishment has been slowly building mechanisms to accommodate commercial SaaS pricing, but the fit is still imperfect. The fundamental tension is that SaaS vendors price on consumption (seats, API calls, data volume) in a continuous subscription model, while the government's budget structure is annual and appropriation-specific. A 36-month enterprise SaaS agreement is legally problematic if it spans multiple fiscal years without being structured as a multi-year contract under FAR 17.1 or an IDIQ with annual delivery orders. Every defense SaaS engagement eventually has to be reconciled with this constraint.

Three vehicle paths accommodate SaaS subscription pricing in practice. The first is an IDIQ contract with annual or quarterly delivery orders. The base IDIQ pre-negotiates unit prices (per seat per month, per API call, per GB of data processed), security terms, and data rights. Annual delivery orders fund the subscription for each fiscal year from the appropriate appropriation. This structure works well for commercially available software with a FedRAMP Authorized status, because FedRAMP authorization provides the security documentation the government needs to execute delivery orders quickly without a full system security assessment for each order. The second path is a Blanket Purchase Agreement (BPA) against the GSA Multiple Award Schedule (MAS). MAS Schedule 518210C covers IT professional services and many SaaS platforms; a BPA against a vendor's MAS contract pre-negotiates a government-specific discount and terms, with individual BPA calls funding each subscription period. The third path is an Other Transaction Agreement (OTA) under 10 U.S.C. 4022. OTAs do not require full FAR compliance, which means a defense agency can engage a commercial SaaS vendor under the vendor's standard commercial pricing terms, provided the OTA includes mandatory government provisions for data rights, security, and audit access.

The OTA path is increasingly used for pilot engagements with commercial AI and software platforms that have not yet pursued FedRAMP authorization. The limitation is that OTAs cannot be used for production deployment of a system that will handle classified information, and they are generally limited to research, development, and prototyping activities. A program that begins under an OTA must transition to a FAR-based contract vehicle for full operational deployment -- and at that transition point, the commercial SaaS pricing terms must be reconciled with FAR cost principles. Vendors who have not thought through this transition often find that their OTA commercial terms are incompatible with FAR 31.201 cost allowability principles, requiring significant contract restructuring before the transition can be executed.

Profit margins, indirect cost rates, and what drives government price evaluations

Government price evaluation looks at more than the bottom-line price. For negotiated procurements (as opposed to sealed bids), the government evaluates whether the proposed price is fair and reasonable by analyzing cost elements: direct labor, indirect rates, other direct costs, and profit. Profit is not capped in commercial contracting, but government profit policy under FAR 15.404-4 establishes weighted guidelines that limit profit to a range typically between 5% and 15% of cost for most defense software work, with the specific ceiling varying by contract type and risk allocation. A software vendor proposing 30% profit on a cost-reimbursement contract will not win a source selection; a vendor proposing 8% on a highly competitive FFP contract may leave money on the table. Understanding where the evaluators' profit expectations sit for a given procurement type is part of competitive pricing strategy.

Indirect cost rates are the multiplier that converts direct labor dollars into fully burdened cost. A software engineer billing at $85/hour direct may cost the government $170/hour fully burdened if the contractor's combined fringe, overhead, and G&A indirect rates total 100%. Large defense prime contractors with high facility costs, extensive compliance organizations, and large corporate overhead structures frequently carry total indirect rates of 150--250% on direct labor. Small software companies with lean overhead structures may carry rates of 60--90%. This structural difference means that a small, nimble software company can often price below a large prime on equivalent technical work even at equivalent profit margins, because the direct labor base is burdened at a fraction of the prime's rate. Communicating this clearly in a price proposal -- showing the indirect rate structure, providing a narrative on how low rates reflect lean overhead rather than cost undercounting -- is an important part of competitive positioning for smaller defense software vendors.

Price evaluation criteria also vary by acquisition type. Best Value Tradeoff (BVT) procurements allow the government to pay a price premium for superior technical or past performance ratings. Lowest Price Technically Acceptable (LPTA) procurements award to the lowest-priced technically acceptable offeror, with no premium for superior technical proposals. Defense software procurements have moved away from LPTA in recent years following recognition that LPTA drives toward lowest-cost developers rather than highest-capability solutions. DoD policy since 2017 (DFARS 215.101-2-70) restricts the use of LPTA for development work. For defense software vendors, this shift means that investing in technical differentiation -- documented methodology, reusable components, demonstrated past performance on similar programs -- can yield a price premium in source selection rather than simply raising the offer's evaluated cost relative to the competition.