I have sat in the acquisitions office at OSD Policy, stared at a procurement package thicker than a phone book, and watched a program manager try to explain to a congressional staffer why a software tool that a startup could have delivered in six weeks was going to take the United States government four years and $200 million to acquire. The staffer didn’t understand. The program manager didn’t either. He just knew the rules.
Those rules have a name. The Federal Acquisition Regulation — the FAR. Two thousand pages of procurement law that govern every dollar the government spends. And buried inside those two thousand pages is a set of assumptions so outdated, so fundamentally misaligned with how modern software is built, that the most powerful military on earth cannot buy a working app faster than you can order one on your phone.
This is not a story about bureaucratic incompetence. The people inside the Pentagon are not stupid. This is a story about a system designed in 1984 to buy tanks, jets, and missiles — hardware with a 30-year lifecycle — that has never been updated for a world where software ships in two-week sprints and is obsolete in 18 months. The FAR was written for a world that no longer exists, and it is killing our ability to fight in the one that does.
The Architecture of Paralysis: How the Pentagon Actually Buys Software
Let me walk you through how the Pentagon buys software today, because until you see the machine from the inside, you cannot understand why it grinds so slowly.
A program office identifies a need. Say the Air Force needs a mission-planning tool that runs on a tablet. A startup in Austin could build a prototype in eight weeks. But the Air Force can’t just call them. First, the requirement has to be written — and the FAR demands that requirements be expressed as detailed specifications, not outcomes. Not “we need a tool that helps pilots plan missions on a tablet,” but a 200-page document specifying screen resolution, data formats, encryption standards, hosting requirements, and compliance with a dozen security frameworks, many of which were written before the iPad existed.
That requirements document takes 12 to 18 months to write. By the time it’s finished, the technology it describes is already a generation behind.
Then comes the competition. The FAR mandates full and open competition for contracts over the simplified acquisition threshold. This is a good principle — taxpayer money should be competed. But the way competition works in practice is that the 200-page specification favors the company that helped write it. And who helps write specifications? The incumbent. The big prime contractor with 60 lobbyists on K Street who have spent years building relationships with the very offices that draft these documents.
Lee Drutman documented this pattern in The Business of America is Lobbying: the complexity of policy becomes a strategic advantage for those who can afford to navigate it. In procurement, this is not theory. It is Tuesday. The incumbent contractor doesn’t need the best software. They need the best lawyers and the most patient proposal writers. And they have both.
The startup in Austin? They read the 200-page RFP, realize they’d need a full-time compliance team just to respond, and they walk away. The Pentagon never even sees their product.
The 10 FAR Clauses Blocking Defense Software Innovation
I am going to name the specific mechanisms. Not because I want to bore you with regulation, but because when someone tells you the system is broken, you deserve to know exactly where the cracks are.
1. The Specifications Trap (FAR Part 11). Requirements must be written as detailed specifications rather than performance outcomes. This means the government describes how to build the thing instead of what the thing needs to do. For hardware, this makes sense — you want the rivets in the right place on an F-35. For software, it is suicide. You cannot specify every feature of a mission-planning app 18 months before a single line of code is written. The technology will change. The threat will change. The user’s needs will change. But the specification will not, because changing it requires a contract modification that takes six months.
2. The Waterfall Mandate (FAR Part 34 & DFARS 234.2). Major acquisitions must follow milestone-based oversight — Milestone A, B, C — designed for sequential hardware development. This is the waterfall model applied to software. It assumes you can define all requirements upfront, build the entire system, then test it at the end. Every software engineer alive knows this doesn’t work. Modern development is iterative — build a small piece, test it with users, adapt, repeat. But the milestone system demands that you lock requirements before you write code, deliver the whole thing at the end, and don’t change direction in between.
3. The Color of Money Problem (31 USC 1301 & FAR 32.7). Federal appropriations are divided into strict categories — research money, procurement money, operations money — and they cannot be mixed. Software doesn’t care about these categories. A development sprint might include research, procurement, and operations in the same two-week cycle. But the money says you can’t do that. So program managers spend weeks allocating labor hours across funding lines, not because it makes the software better, but because the Antideficiency Act says they’ll go to prison if they charge a procurement hour to an R&D account.
4. The Rights Trap (FAR 52.227-14 & DFARS 252.227-7014). The government’s default position on intellectual property is: we paid for it, we own it. For a startup whose entire value is their codebase, handing over unlimited rights is a death sentence. They can’t sell the product commercially if the government owns the source code. So they don’t bid. The government gets proposals from companies that don’t care about owning their own IP — which means companies building bespoke, government-only software that nobody else uses, nobody else improves, and nobody else maintains after the contract ends.
5. The Lowest Price Trap (FAR 15.101-1). For many procurements, the evaluation criteria default to Lowest Price Technically Acceptable — LPTA. For commodity goods, this is fine. For software, where the difference between a mediocre codebase and a great one is the difference between a system that scales and one that crashes on day two, LPTA is catastrophic. You get what you pay for, and when you optimize for the lowest price, you optimize for the lowest quality.
6. The Competition Paradox (FAR Part 6). Full and open competition is mandatory, but writing a proposal for a major DoD contract costs between $500,000 and $2 million. Only companies that can absorb that cost will compete. The result is not competition — it is an oligopoly of five or six prime contractors who trade contracts among themselves while small businesses are structurally excluded from the game.
7. The Testing Death March (DFARS 252.246 & DoD 5000 Series). Acceptance testing follows hardware-era protocols — months of formal verification against the original specification. For software, this means you’re testing against requirements that were written two years ago. The test plan doesn’t ask, “Does this software solve the user’s problem today?” It asks, “Does this software match the specification we wrote when Obama was president?” If the software is better than the spec — if the developers improved it based on user feedback — it can technically fail the acceptance test.
8. The Contractor Lock-In (FAR 52.212-4 & proprietary data rights). Once a contractor builds a system, they own the tribal knowledge of how it works. Even when the government has data rights, the documentation is often so thin that switching contractors means rebuilding from scratch. The incumbent knows this. The government knows this. And so the “competitive” recompete becomes a formality — a $500 million contract renewal dressed up as a fair fight.
9. The Cloud Prohibition (FedRAMP + FAR 39 + DFARS 252.204-7012). Using commercial cloud services requires FedRAMP authorization, DFARS cybersecurity compliance, and often IL4/IL5 classification. The compliance burden is so heavy that most cloud-native startups can’t afford the process, which takes 12 to 18 months and costs over $1 million. So the Pentagon buys on-premise solutions that are slower, harder to update, and more expensive to maintain — all in the name of security that the commercial cloud already provides at a higher standard.
10. The Protest Tax (FAR Part 33 & GAO Bid Protests). Any losing bidder can protest the contract award to the GAO, freezing the procurement for 100 days. For software, 100 days is an eternity. Incumbents use protests strategically — not because they believe the award was unfair, but because delay is cheaper than losing the contract. The protest system, designed to ensure fairness, has become a weapon of delay.
Why It Stays Broken: Lobbyists, Incentives, and the Barnacle Problem
If the problems are this obvious, why hasn’t anyone fixed them? Because the people who benefit from the complexity are the same people who write the rules.
Drutman’s research shows that the largest defense contractors spend more on lobbying than the entire budget of most congressional oversight committees. They don’t lobby to change procurement rules. They lobby to prevent changes to procurement rules. Every reform effort — every attempt to streamline the FAR, to expand Other Transaction Authority, to create pathways for commercial software — faces an army of lobbyists whose job is to ensure the status quo survives. Not because the status quo is good, but because it is theirs.
The “unintended consequences” argument is their favorite weapon. Any proposed reform is met with warnings about fraud, waste, and abuse — as if the current system isn’t already the largest source of fraud, waste, and abuse in the federal government. The strategy works because policymakers are risk-averse, congressional staffers are stretched thin, and nobody wants to be the person who “broke” defense procurement. So the barnacles stay attached to the rock, and the ship gets slower every year.
There is also a cultural problem inside the Pentagon itself. Program managers are not rewarded for speed. They are rewarded for compliance. A PM who delivers a working system in 12 months but cuts a corner on documentation will be investigated. A PM who delivers a broken system in five years but has a flawless paper trail will be promoted. The incentive structure punishes innovation and rewards process — the exact opposite of what software development requires.
The Fix That Could Actually Work: A Software Acquisition Pathway
I am not naive enough to think you can rewrite the entire FAR. It is too entrenched, too layered with precedent, and too many powerful interests depend on its complexity. But you don’t need to rewrite the whole thing. You need a carve-out.
Here is what 10 lines of FAR could do. Create a Software Acquisition Pathway (SAP) — a new subpart under FAR Part 39 that applies exclusively to software-intensive programs under $100 million — built on five principles:
1. Outcomes over specifications. Requirements must be expressed as measurable performance outcomes, not technical specifications. “The system must process 10,000 intelligence reports per hour with 95% accuracy” instead of a 200-page document describing database schemas.
2. Iterative delivery mandated. Software must be delivered in increments no longer than 90 days. No more five-year waterfall programs. If the contractor can’t show working software every quarter, the contract is terminated for convenience.
3. Flexible funding authority. SAP programs receive blended funding authority that allows R&D, procurement, and O&M dollars to be used interchangeably within the program, with quarterly reconciliation instead of per-transaction accounting.
4. Commercial IP default. The default IP position is government purpose rights — the government can use the software but cannot distribute the source code commercially. Startups keep their IP. The government keeps its access. Both sides win.
5. Challenge-based acquisition. Instead of a 200-page RFP, the government issues a problem statement and a test dataset. Companies submit working prototypes. The best one wins. Total proposal cost: a demo and a five-page technical approach. Bid protests limited to procedural violations only.
None of this is radical. The Defense Innovation Unit has been piloting versions of these ideas for years. Other Transaction Authority already enables some of them. Section 804 of the FY16 NDAA created a middle-tier acquisition pathway that moves faster than traditional FAR. The problem is that these alternatives are exceptions, not defaults. What we need is for the exception to become the rule — for software.
The Clock Is Running: China Isn’t Waiting for FAR Reform
The Chinese military is not waiting for us to fix our procurement system. They are deploying AI-enabled battlefield systems on 18-month cycles while we are still writing requirements documents for the last war. Russia is fielding autonomous drones that adapt in real time while our drone software updates go through a testing death march designed for nuclear submarines.
This is not an abstract policy debate. This is a readiness crisis. Every month we spend arguing about FAR clauses is a month our adversaries spend deploying capability. The gap is not closing. It is widening. And the people who will pay the price are not the lobbyists on K Street or the program managers in the Pentagon. It is the 22-year-old sergeant in a forward operating base who needs a working mission-planning tool and instead gets a PowerPoint brief about the procurement timeline.
I have sat in rooms where people die on slides. Where the “solution” is always 18 months away. Where the system rewards the people who manage the process and punishes the people who try to deliver the product. I have watched good officers burn out trying to drag a Cold War procurement system into the 21st century, and I have watched the system win every time.
But it doesn’t have to. Ten lines of FAR. A software acquisition pathway. Outcomes over specifications. Iterative delivery. Flexible funding. Commercial IP defaults. Challenge-based competition.
We know how to build software. We do it every day in the commercial world, faster and better than anyone on earth. The only thing stopping the Pentagon from doing the same is a set of rules written 40 years ago for a world that no longer exists. Change the rules. Save the warfighter. It really is that simple — and that hard.
What This Means for You
If you’re a veteran who served in a unit that waited months or years for software that should have taken weeks, you already know this story. You lived it. The system that frustrated you wasn’t broken by accident — it was built this way, and it is maintained by people who profit from its complexity.
If you’re a taxpayer, you are funding this dysfunction. Every dollar spent on a five-year software procurement that could have been a six-month agile contract is a dollar taken from readiness, from training, from the people who actually fight.
If you’re a founder — especially a veteran founder trying to sell to the government — know that the deck is stacked against you, but not permanently. Other Transaction Authority, SBIR Phase III, and the new middle-tier acquisition pathways are real. They are narrow, and they require a program manager brave enough to use them. But they exist. Find those program managers. They are the ones who will change this system from the inside.
And if you’re a congressional staffer reading this on your lunch break — you have the power to fix this. Ten lines. One new subpart. The warfighter is waiting.
About the Author
Michael Komorous is the host of Voice for Valor, a podcast dedicated to sharing the stories of military veterans, first responders, and their families. A combat-rated Air Force officer, Mike served as a nuclear missile operator, C-17 pilot, and MQ-1 Predator pilot before managing rated personnel across the Air National Guard. His policy career spans legislative affairs, defense acquisitions, and geopolitical strategy at OSD Policy, including analysis of the war in Ukraine.
Today Mike builds AI systems and leads Alpha Zulu Solutions, a service-disabled veteran-owned small business focused on defense technology and government contracting. He holds advanced analytics training from George Mason University’s Innovation Lab.
Watch the podcast on YouTube | Visit voiceforvalor.com | Connect on Facebook