What Building for Veterans Taught Us About Building for Anyone

What Building for Veterans Taught Us About Building for Anyone

VeteranX taught us that trust matters as much as the AI itself.

Rahul Nayak

Apr 17, 2026

There's a version of the VeteranX story that sounds straightforward: build an AI-powered platform that translates military skills into civilian job language, help veterans find work faster, ship it. Clean problem, modern solution. That version leaves out the part where we nearly got it wrong.

The Users We Underestimated

Veterans transitioning out of service carry something most job seekers don't. A decade or more of high-stakes, deeply specialized experience that the civilian job market has almost no vocabulary for. An infantry officer who managed logistics chains under combat conditions doesn't neatly map to "Supply Chain Analyst." A signals intelligence specialist isn't obviously a "Data Analyst." The gap is real, and it costs people opportunities every day.

The platform's AI engine was built to bridge that gap, taking military occupational specialties and translating them into job-relevant skills and roles. On paper, a compelling use case for LLMs.

What we didn't fully reckon with early enough was the person on the other side of that interface.

For many veterans, transitioning out of service already feels uncertain and exposing. Handing their career history to an algorithm they couldn't see, only compounded that. What they needed, consistently and clearly, wasn't smarter recommendations. It was transparency and a sense of control.

The insight that reshaped our approach: trust isn't a UX nice-to-have. For this audience, it's the product.

The Performance Problem That Was Really a Trust Problem

Around the same time, we hit a hard technical reality: the AI recommendation engine was slow. Not unusably slow in a technical sense, but slow enough that in user testing, veterans were abandoning the flow before results arrived. They assumed something had broken. Or worse, that the system wasn't taking their input seriously.

The instinct in these situations is to fix the model. Optimize, compress, find a faster path. And some of that work happened. But the more important fix came from a different direction.

The fix wasn't just technical, it was conceptual. Rather than asking users to wait, the team turned the wait into an introduction. Sequential steps made progress visible. Visual cues drawn from the platform itself gave users a preview of what was ahead, easing them in before they'd even landed. Async processing handled heavy lifting in the background. By the time results arrived, users weren't strangers to the product. They'd already begun to understand it.

That structural shift meant rethinking how the pipeline surfaced state to the frontend, coordinating backend processing with a UI that could represent partial progress meaningfully. The engineering and design decisions had to move together. Neither could solve it alone.

The latency stopped being a wall. Users moved through the experience differently when they could see it moving with them.

That said, the latency wasn't fully resolved, and we'd be misrepresenting the work if we said it was. Some of it remains. The team continues to work through it, refining how recommendations are generated and surfaced. What shifted was the frame: from treating latency as a pure backend problem to treating, it as an experience problem with both technical and design dimensions. That reframe is what unlocked progress, even if the work isn't finished.

What This Actually Taught Us About AI Products

The temptation with AI-powered features is to let the model carry the experience. If the output is good, the thinking goes, the product will feel good. This is almost never true.

A few things we'd take into any similar engagement:

Design the wait, not just the result. Latency is a user experience, and how you fill it, shapes how people judge the output that follows. A result that arrives with context feels more credible than one that appears from nowhere.

The hardest requirements come from the user, not the client. The feature list was defined. The functionality was scoped. What wasn't on any document was the emotional contract the platform needed to honor. Getting that in front of the right people, early enough to matter, is the kind of work that doesn't show up on a sprint board.

Building for people in transition taught us something simple: get the human experience wrong, and the technology doesn't matter.

RMgX helps organisations ship digital products, deploy applied AI, and modernise platforms. If you're building something where the human experience is as complex as the technical one, let's talk.

More Articles
More Articles