Design Written in Blood

Why veteran-led teams build the mission systems that survive first contact

In the US, “Veteran-Founded” is not just a good line on a slide. It is written into procurement rules. The Small Business Administration runs a certification program for veteran-owned firms, and the federal government has a legal goal of directing five percent of contracting dollars to service-disabled veteran-owned businesses, with the right to skip open competition entirely on some contracts. That is not sentiment. That is a line item in the law.

I won’t pretend to inherit that mechanism automatically. We are a Ukrainian company, and the US set-aside programs are built around US ownership and control.

But the underlying signal still travels wherever procurement officers and investors are reading a pitch deck: leadership that has stood inside the problem carries a different kind of credibility than leadership that has only studied it.

Here is what that credibility is actually built on.

Civilian engineers design for demos. Veterans design for the worst day.

Give a talented civilian engineer a blank sheet and he will build you something impressive. Multiple screens. Layered menus. A configuration option for every scenario he can imagine. It will look excellent in a conference room.

Then put that same interface in the hands of an operator who has not slept in two days, whose fingers are numb, who is working through smoke, and who has maybe four seconds before the situation changes.

Every extra tap is a decision he does not have time to make. Every unclear label is a mistake waiting to happen. The feature that looked clever in the office becomes the reason a mission fails.

I have sat through enough of those failures to know they are never one big design flaw. They are ten small ones, each added by someone who never had to use the product under fire.

What combat actually teaches you to cut

Veterans do not bring some mystical design talent to a company. They bring a filter. When someone proposes a new feature, they ask one question first: will this still work when the operator is exhausted, cold, and being actively jammed? If the answer is no, the feature does not ship, no matter how good it looks in a pitch.

That filter shows up as very specific, unglamorous decisions. Fewer steps to arm, fewer steps to abort.

Controls that work with gloves, not just a fingertip. Systems that keep functioning when the network doesn’t, because in this war the network is often the first thing the enemy takes away.

Nothing that asks the operator to trust something he cannot verify at speed.

None of that is exciting to build. All of it is the difference between a product that survives contact and one that gets left in a truck.

But veteran instinct alone does not build a system

I want to be clear about something, because I have seen this misunderstood. Combat experience tells you what has to be true about a system. It does not, by itself, build the system.

That takes engineers who can turn a hard operational requirement into working software, under real constraints, on a real production timeline. And increasingly it takes people trained in applied mathematics, who build the computational models a system needs to keep flying with GNSS-free navigation when the usual satellite signals are jammed. That is not a job for instinct. That is a job for someone who has spent years with the underlying mathematics.

The strongest mission-software teams I have watched emerge from this war are not veteran-only, and they are not engineer-only. They are the combination. The veteran sets the requirement and kills the features that would get someone killed.

The engineer builds the thing that actually works in production. The scientist builds the model that makes the system reliable when the easy assumptions stop holding. Take away any one of the three and you get a product that is either unusable, unbuildable, or unreliable exactly when it matters.

That is the team we are building. Not because “veteran-founded” is a good line for investors, though it is. Because a system designed by someone who has been on the other end of a bad interface asks a different first question than a system designed by someone who has not: not “what can this do,” but “what can this do when everything is going wrong.”