Build for What Comes After the Demo

Introduction

The Department has made real strides in C2.

The strategic direction is clearer than it's been in years. As recently as FY2024, the budget request put $1.4 billion behind JADC2 initiatives alone, and the strategic momentum behind modern software delivery has only grown since. The services are running real experiments - Project Convergence, Project Overmatch, ABMS - that are producing operational insights. Common data standards are advancing. DevSecOps adoption is accelerating. The joint force is meaningfully more connected than it was five years ago.

A lot of the progress is visible in what we'd call the first 80% of C2 - the capability that looks similar across most programs. Maps that respond. Data layers that populate. Messaging that works. Workflows that hold together in a clean environment. That surface area is well understood. The platforms, components, and integration patterns that support it have matured.

But there's a pattern that keeps showing up, across programs and services and acquisition approaches. The 80% comes together. The demo looks right. The capability is real. And then integration starts - against the actual network, the actual echelon authorities, the actual operators who have been doing this job for years in ways no requirements document fully captured.

That last 20% turns out to be where the mission actually lives. This is where Accelint's Neo for Rapid Prototyping becomes critical. If the initial 80% is built on a reusable foundation, teams can spend less time recreating baseline capability and more time iterating on the mission-specific details that actually determine success.

Echelon-specific authorities. Network realities that only surface under operational conditions. Domain constraints. Operator muscle memory that no platform anticipated. It's where schedules compress, costs grow, and the distance between what the software does and what the warfighter needs becomes most visible.

That gap isn't a sign that the program failed. It's a sign that the last 20% of C2 is genuinely hard, and that getting the 80% right doesn't automatically solve it. It just determines whether you have a fighting chance.

The Pattern Behind the Failures

The history is instructive. According to a RAND retrospective commissioned by the Army, Future Combat Systems was cancelled in 2009 and widely regarded as a failure — brought down not by lack of ambition but by the complexity of integrating too many things that hadn't been tested against real operational constraints. DOT&E's assessment of DCGS-A Release 2 found usability rated "low-marginal" and the system not survivable against cyber threats — a last-20% failure, not a platform failure. The F-35's ALIS wasn't user friendly and didn't deliver promised sustainment capabilities, ultimately requiring replacement with ODIN.

In each case, the platform didn't fail because it lacked ambition. It failed where the workflow and the operational guarantees actually mattered.

Standardize the Pieces, Not the Mission

The instinct when facing this problem is to build a more comprehensive platform - one that anticipates more use cases and covers more ground. But that instinct tends to make the last 20% harder, not easier. Echelons are different. Networks are different. Operators are different. The mission can't be standardized. The foundation beneath it can.

That means investing in shared foundations - common UI components, common state patterns, common map and geospatial primitives - so teams doing mission-specific work aren't starting from scratch every time. Not shared apps, but shared parts. Parts that have already survived contact with real operational environments and real operator feedback.

The DoW Software Modernization Strategy frames reuse and modern delivery ecosystems as explicit enablers of speed. DoW's DevSecOps Fundamentals describes platforms as reusable foundations, expected to be instantiated from hardened infrastructure and artifact repositories.

The direction is clear: don't handcraft every brick.

For us, that work is already underway in Neo. The shared component library underpinning our mission command interface - UI primitives, map layers, state patterns - is maintained across programs and actively hardened through use.

With Neo for Rapid Prototyping, teams use that same foundation at the very beginning of a program. Designers and developers prototype against real constraints before a line of production code is written, which means fewer surprises hit engineering and the mission-specific work starts closer to operational reality.

When a new program kicks off, teams aren't starting from scratch. They're starting from something that has already survived operational environments and been shaped by feedback from the warfighters who used it. Those prototypes aren’t throwaway - they become the starting point for the system that gets delivered.

The Governance That Makes Speed Sustainable

A hardened foundation only holds if it's treated like a product, with promotion criteria, behavioral guarantees, and measurable contracts between the foundation and the mission.

Components should earn their place through a deliberate process: exploration to prove real workflows against real constraints, incubation to harden and instrument and test, integration to ship with clear guarantees.

How fast does the map respond at p95 on target hardware? What happens to workflows when the network is intermittent? These are the operational reality warfighters live in every day. That same discipline applies to what begins as a prototype - only what proves itself under real conditions gets promoted into the shared baseline.

The Warfighter Is the Measure

Soldiers, airmen, and commanders have one question for any system: does it help me do my job when it matters? When the network is degraded, when the data is incomplete, or when the mission has changed and the timeline hasn't?

That question gets answered in the last 20%. And the programs that get it right are the ones that showed up there with a solid foundation already underneath them. Tested, trusted, and built for operational reality from the start.

The fastest teams aren’t the ones who prototype the quickest - they’re the ones whose prototypes survive contact with reality and carry forward.

That's the standard worth building toward.

‍