Modular Contracting and Agile Delivery for Software Companies: How Agencies Buy in Increments
By Philip Luca — Founder of GovExpress; prior domain experience at Bloomberg Government and GovWin IQ.
Federal agencies used to buy large IT systems the way they buy buildings: write a complete specification, award one contract, and wait years for delivery. Many of those programs ran late, over budget or were cancelled. Congress responded in 1996, and today the default for large IT buys is to split them into smaller pieces that each deliver something usable.
For a software company, that changes what you bid on. Instead of one multi-year system contract, you may see a short first increment, a pilot, or a task order for one release, with later work competed or ordered separately. This guide explains the rules behind that approach, how agencies contract for agile work, and how to position a bid.
Where modular contracting comes from
The Clinger-Cohen Act of 1996 directed agencies to use modular contracting for major IT systems, and the FAR puts that into practice in Part 39, at FAR 39.103. The rule says agencies should, to the maximum extent practicable, divide a major IT acquisition into smaller increments. They may do the same for smaller systems.
The FAR describes what a good increment looks like. Each one should:
- be easier to manage on its own than one comprehensive acquisition would be
- deliver, implement and test a workable system or solution that doesn’t depend on a later increment to perform its main functions
- leave room for later increments to use newer technology or meet needs that have changed
- limit the government’s exposure if a later increment fails or is never bought
The FAR also sets timing norms. Normally, the contract or order for each increment should be awarded within 180 days of the solicitation, and the IT it buys should be delivered within 18 months of the solicitation. An increment that can’t meet those norms is a signal the agency should reconsider how it has split the work.
The FAR is being rewritten through the Revolutionary FAR Overhaul, and many agencies now apply the new text by class deviation, so section numbers and wording may differ. Check the solicitation and the current FAR text for the rules that apply to a given buy.
What agile looks like in a federal contract
Modular contracting is about how the purchase is split. Agile is about how the work is done. They fit together, and agencies have published practical guidance on combining them, including OMB guidance on contracting for modular development and the TechFAR Handbook from the U.S. Digital Service.
In a solicitation, agile work usually shows up in a few recognizable ways:
- A statement of objectives instead of a full specification. Under FAR Subpart 37.6, an agency can describe the outcomes it wants and ask offerors to propose how they’ll get there, including the performance work statement itself.
- A product backlog instead of a requirements list. The agency owns priorities, and the contractor delivers working software against them each iteration.
- Short periods of performance. A base period of months rather than years, with options the agency exercises if the work is going well.
- Task orders per release. An IDIQ contract or a blanket purchase agreement holds the terms, and each increment is ordered separately.
- Technical challenges in the evaluation. Agencies often ask offerors to build something or work a scenario, which is covered in our guide to oral presentations and technical demos.
Choosing a contract type for agile work
Agile work raises a pricing question: how do you fix a price when the scope is meant to change? Agencies use several answers, and each one shifts risk differently.
- Fixed price per iteration or release. The agency pays a set price for a team working a set period, and the scope inside each iteration is agreed through the backlog. This keeps price risk predictable for both sides.
- Labor-hour or time-and-materials. The agency pays for hours at fixed rates. The FAR treats these as the least preferred types because they give the contractor little incentive to control cost, and the contracting officer must document why no other type is suitable before using one.
- Hybrid structures. A fixed-price core for defined work, with a labor-hour line for discovery or support.
Our guide to federal contract types covers the trade-offs in more detail. Whatever the type, the price reasonableness rules still apply, so be ready to explain how your team rate or iteration price compares with the market.
Defense software buys
The Department of War (DoW) has its own path for software. Its Software Acquisition Pathway is built around delivering a minimum viable product early and then shipping updates on a short, regular cadence, rather than reaching a single final delivery. Defense buyers also use Other Transaction agreements and Commercial Solutions Openings to move quickly on prototypes and commercial technology, and successful prototypes can lead to follow-on production work.
If you sell to defense customers, expect the same questions about security and data handling that any federal buyer asks, plus CMMC requirements where the work involves controlled unclassified information. A self-attested status is not the same as a third-party assessment, and buyers increasingly ask which one you have.
How to bid on a modular or agile buy
- Price the first increment to win it. The first increment is often small, and the agency is testing whether you can deliver. A strong first increment is how you earn the options and the next order.
- Show working software, not a process. Evaluators have read many proposals that describe agile ceremonies. A demo, a live environment or a short case study with real release dates is more convincing.
- Make each increment stand alone. The FAR asks for increments that work on their own. Proposals that depend on a later phase to deliver value cut against the way the buy was designed.
- Be clear about what’s commercial. If your offer combines a commercial SaaS product with development or configuration services, separate them. The subscription is usually a commercial product with its own license terms, and the services are where the modular and agile terms apply.
- Plan for the handoff. Because the agency can switch vendors between increments, expect requirements for documentation, code delivery and data portability. Read them before you bid, not after you win.
To see where your company stands before your next federal bid, score your company’s federal readiness.
Related reading
- Federal Contract Types for Software Companies
- IDIQ Contracts and Task Orders for Software Companies
- Oral Presentations and Technical Demos for Software Companies
- Price Reasonableness for Software Companies
- How to Sell Software to the Federal Government: The Complete 2026 Guide for ISVs
- Glossary: FedRAMP · CMMC · SAM.gov
Frequently Asked Questions
What is modular contracting in federal IT?
It's the practice of buying a large IT system as a series of smaller, separate acquisitions instead of one big contract. Each increment should deliver something that works on its own, so the agency can stop, change direction or switch vendors between increments without losing what it already bought.
Can a federal agency contract for agile software development?
Yes. Nothing in the FAR requires a fixed, fully specified requirement up front. Agencies contract for agile work with statements of objectives, task orders per release or iteration, and fixed-price or labor-hour structures sized to a team and a time box rather than a complete feature list.
Is a commercial SaaS product bought the same way as custom development?
Not usually. A commercial SaaS subscription is normally bought as a commercial product under FAR Part 12, often through a GSA Schedule or a reseller. Modular and agile contracting matter most when the agency is paying for development, integration or configuration work around the product.
The CMMC brief
What the Phase 2 suspension changed and what it did not — the obligations that still bind, the assessment path a contract puts you on, the scoping decision that drives the cost, and the sequence that fits inside a pipeline. Sourced from the primary record.