Defense startup procurement cycle: from pilot to program of record

Most defense technology startups that fail commercially do not fail because their product stopped working. They fail because the distance between a successful pilot and a funded Program of Record (POR) is longer, more bureaucratically complex, and more dependent on relationships than any product roadmap anticipates. The mechanics of winning that first government contract are well documented. What receives far less attention is the harder phase that follows: converting a one-time pilot payment into a sustained budget line that can support a growth-stage company. This article traces the full procurement cycle -- from pilot design through OTA prototype, security accreditation, program champion cultivation, coalition considerations, and the structural transition risks that end programs before they reach operational scale.

The valley of death: why good technology stalls between pilot and contract

The valley of death is not a metaphor about product quality. It is a structural funding gap that arises from a mismatch between the speed of technology demonstration and the speed of defense budget cycles. A company can complete a pilot in 90 days. The program office can confirm it worked. But the program office cannot obligate new money against a capability it just discovered -- not until that capability has survived the Program Objective Memorandum (POM) process, which runs on an 18-month cycle and requires documented requirements, cost estimates, and risk assessments that do not exist for a technology the program just evaluated.

During this interval the startup is expected to continue developing the product, maintain a trained team, support the government's evaluation documentation, and stay solvent on whatever Phase II SBIR, bridge contract, or follow-on OTA it can secure. The median duration of this gap -- between the end of a successful pilot and the first obligation under a new-start program budget -- is 18 to 36 months for a software product with no prior DoD acquisition history. Companies that plan for a 6-month gap and run out of runway at month 14 do not get second chances in most program offices; the champion moves on, and the technology is re-evaluated from zero by the next program manager.

The practical implication is that pilot design must account for the valley before the pilot begins. A pilot structured to generate the specific documentation -- capability gap analysis, operational effectiveness data, integration architecture, cost-per-unit projection -- that a program manager needs to build a POM submission will survive the transition period at higher rates than a pilot designed purely to demonstrate technical performance. Technical performance is table stakes. Administrative legibility to the budget process is what crosses the valley.

OTA agreements, SBIRs, and DIU pathways -- how they differ

Three contracting instruments dominate the early-stage defense startup engagement: Other Transaction Authority (OTA) prototype agreements, Small Business Innovation Research (SBIR) awards, and the Defense Innovation Unit (DIU) Commercial Solutions Opening (CSO) process. They are not interchangeable, and choosing the wrong vehicle for the wrong moment in the procurement lifecycle creates delays that are difficult to recover from.

OTA prototype agreements under 10 USC 4022 are the fastest path from a funded requirement to an evaluated prototype for a startup without government accounting systems. They sit outside the Federal Acquisition Regulation, meaning a program office can award an OTA to a company that has never held a DoD contract, does not have Defense Contract Audit Agency (DCAA)-approved accounting systems, and cannot produce certified cost or pricing data. The trade-off is scope: OTA awards are legally restricted to prototype activities. A transition to full production requires either a competitive FAR-based follow-on or a sole-source production award under the OTA statute's transition provision -- and that sole-source is not automatic. It requires the program office to make a written determination that the prototype was competitively awarded and that the production follow-on is a logical extension. Program offices that have not pre-planned this transition often lose the authority to sole-source and must re-compete, restarting the timeline.

SBIR Phase II awards provide up to $1.72 million (current DoD limit) for a period of 24 months. The Phase III provision -- which allows a program office to award a sole-source follow-on contract to a Phase II awardee without competition -- is the mechanism that converts SBIR research funding into a procurement contract. Phase III has no dollar cap and no competition requirement, which makes it the most powerful bridge instrument available to a small company. The limitation is that the Phase III award depends entirely on a willing program office with an open funding line -- and identifying that program office before the Phase II period expires requires the same champion cultivation work that every other procurement pathway demands. Ecosystem programs like Brave1 in Ukraine have demonstrated that structured public-private acceleration frameworks can compress this champion identification timeline by giving startups visible access to program offices that are actively seeking specific capability types.

DIU's CSO process is optimized for commercial technology with a defense application and produces a Commercial Solutions Opening award that can transition to a production contract under 10 USC 4022. DIU's strength is speed -- awards can close in 60 to 90 days -- and its network, which connects selected companies to operational users and program offices across the services. The structural limitation for a startup is that DIU is a transition mechanism, not a sustained funder. A DIU award proves the concept and provides an introductory budget line; it does not substitute for a service program office owning the requirement in its POM.

Building an evaluable minimum viable product for procurement officers

A minimum viable product (MVP) for procurement is not the same artifact as an MVP for a commercial software launch. Commercial MVPs are designed to test a market hypothesis with paying early adopters. Defense procurement MVPs must satisfy a different set of evaluators -- contracting officers, program managers, operational testers, and security assessors -- each with distinct requirements that are not fully captured in any single evaluation framework.

The contracting officer needs to confirm that the proposed price is fair and reasonable and that the vendor is responsible (i.e., has the financial, technical, and managerial capacity to perform). This means the MVP must be accompanied by a rough order of magnitude (ROM) cost structure that the company can defend under scrutiny, a CAGE code and SAM.gov registration, and at minimum one past performance reference -- even from a commercial or allied-nation program -- that demonstrates the company has delivered comparable work. Understanding the full RFP-to-contract flow helps startups prepare this documentation before it is requested rather than scrambling to assemble it under a 72-hour response deadline.

The program manager needs to confirm that the technology addresses a documented capability gap and that the integration burden on the government is manageable. An MVP that requires the program office to modify existing C2 systems, retrain operator populations, or maintain two parallel data pipelines adds transition cost that the program manager must justify to higher authority. The most procurement-legible MVPs connect to existing data standards (CoT, STANAG, Link 16, NIEM) without requiring middleware that the government must separately fund and maintain. Every integration dependency that a startup removes from its MVP reduces the friction cost the program office must absorb to champion the product.

Security accreditation timelines and how to shorten them

Security accreditation -- obtaining an Authority to Operate (ATO) under the DoD Risk Management Framework (RMF) -- is the most consistently underestimated timeline element in a defense startup's procurement plan. First-time ATO candidates routinely budget 6 months and arrive at month 18 still waiting for the authorizing official to sign. The delays do not occur because the product is insecure; they occur because the control documentation is incomplete, the system boundary is poorly defined, or the assessment organization does not have bandwidth to schedule the security assessment until months after the documentation package is submitted.

The fastest ATOs are built on inherited controls from a pre-authorized hosting baseline. If the product runs on an infrastructure-as-a-service environment that already holds a DoD Impact Level 2 or Impact Level 4 provisional authorization -- AWS GovCloud East, Azure Government, or comparable -- the startup inherits a substantial portion of the NIST SP 800-53 control set from the cloud service provider's existing authorization package. The startup's assessment then covers only the controls that are not inherited: application-layer controls, configuration management, access control at the software level, and the overlay controls specific to the data classification level. A well-scoped cloud-native product can reduce its standalone control implementation set from the full 325-control NIST 800-53 Rev 5 baseline to 80 to 120 application-specific controls, cutting the assessment duration proportionally.

The second acceleration lever is documentation discipline from day one of product development. RMF requires a System Security Plan (SSP) that describes how every applicable control is implemented. Writing an SSP retroactively for a product that was built without security architecture documentation is slow and error-prone; writing it as the product is built -- with DevSecOps pipelines that produce continuous compliance evidence -- reduces the SSP to an editorial task rather than a forensic reconstruction. Startups that instrument their CI/CD pipelines with OSCAL-formatted control evidence and automated compliance scanning can present an assessor with machine-readable evidence packages that compress the assessment planning phase from weeks to days.

Finding the program office champion: relationships over proposals

No procurement pathway produces a Program of Record without a government employee who is willing to advocate for the technology inside the program office when the vendor is not present. That person -- the champion -- is not found through proposal submissions or industry day attendance alone. Champions are cultivated through persistent, technically credible engagement over 12 to 24 months that demonstrates the startup understands the operational problem as well as any incumbent contractor.

The most reliable path to champion identification is through operational users rather than acquisition offices. A program manager who receives consistent positive feedback from uniformed end users who have used the product -- even in an unofficial evaluation or exercises context -- is far more motivated to advocate for a budget line than one who has only read a capability brief. This means startups should invest in access to operational exercises, wargames, and coalition events where their technology can be tested by actual operators, even without a formal contract vehicle. The feedback loops from these touchpoints generate the operator endorsements that program managers use to justify new-start requests to program executive officers.

Coalition and NATO procurement: additional layers and preparation

A defense startup that has proven its product in one national market faces a structurally distinct set of requirements when pursuing coalition or NATO procurement. The technology may be identical, but the legal, security, and interoperability requirements multiply with each additional nation. Companies that approach coalition procurement as a simple geographic expansion of their existing contract strategy consistently underestimate the preparation required and lose time at exactly the moment when their first-mover advantage is most valuable.

Export control is the first constraint to resolve. US-origin software or hardware with defense application is subject to International Traffic in Arms Regulations (ITAR) or Export Administration Regulations (EAR) controls. A startup that has not determined its product's Export Control Classification Number (ECCN) and obtained any required licenses before pursuing a UK, German, or Finnish program office is creating legal exposure for both itself and the foreign government counterpart. The export classification analysis should be completed before the first meeting with a foreign program office, not after a letter of interest is received.

For NATO common-funded procurement through the NATO Support and Procurement Agency (NSPA), the product must satisfy both the acquiring nation's security requirements and applicable NATO security policies. This introduces a dual accreditation path -- national ATO plus NATO accreditation -- that can run in parallel but requires coordination between two security management structures that do not share documentation formats or assessment schedules. Startups entering this space should identify whether their architecture supports segregated national instances or a multi-tenant deployment with cryptographically enforced data segregation, since the answer determines whether a single accreditation package can be adapted across nations or whether separate packages must be built for each. The NSPA contracting timeline for a new-start capability contract runs 24 to 36 months from initial requirement to award, which must be factored into cash flow planning from the outset.

From proof of concept to full deployment: managing the transition risk

Transition risk -- the risk that a successfully piloted technology fails to reach operational scale -- is the primary reason program offices hesitate to commit to a Program of Record with a startup vendor. The hesitation is not irrational. Program offices that have invested in new-start programs with small vendors have experienced technology discontinuity when the vendor ran out of runway, product pivots that invalidated the initial capability assessment, and integration failures that emerged only during full-scale deployment. Addressing these risks explicitly in the transition planning documents is more effective than asserting stability in capability briefs.

The data rights assertion is the most operationally significant document in a transition plan. Under DFARS 252.227-7013, the government is entitled to government purpose rights in technical data developed with mixed funding -- but the scope of those rights depends on how the startup documented its independent research and development (IR&D) investment at the time of development. A startup that has not maintained contemporaneous records of which product components were developed with company IR&D funding versus government funding will find it difficult to assert the limited rights it is entitled to, and may inadvertently grant the government broader data rights than intended. Conversely, a startup that asserts overly broad limited rights on government-funded development will create a contracting dispute that delays transition. The correct approach is to maintain a funded IR&D program with documented expenditures, assert mixed-funding rights narrowly and accurately, and negotiate a license structure that gives the government sufficient data access for re-competition at the end of the contract period without transferring the startup's core IP.

Sustainment planning receives less attention than it deserves during the pilot phase, and the gap shows at transition. A Program of Record requires not just the capability but a defined support structure: a logistics support analysis (or equivalent for software), a software support plan, a cybersecurity sustainment strategy, and -- for deployed hardware -- a spare parts and maintenance chain. Startups that present these artifacts at the program office review before being asked demonstrate institutional readiness that distinguishes them from competitors who treat sustainment as a post-award problem. The operational user who championed the pilot will be held accountable for the support structure that follows. Reducing that accountability burden is one of the most effective ways to strengthen the champion relationship through the transition phase.