Ground Truth | Everything After the Prototype

Everything After the Prototype: Why cheap prototyping strengthens our position rather than eroding it

By Ben Gould, Senior Director of Technology Strategy, RealmOne

I came to RealmOne almost fifteen years ago, on contract, doing the work. Somewhere along the way, I found myself part of what is now the RealmOne Foundry, and I've spent most of my time there building and integrating things quickly for people who needed them yesterday.

For most of those years, speed was the pitch. If you could stand up something working in a few weeks while everyone else was still writing requirements, you won. We got good at it.

That game is dying. I don't think that's bad news, but I'd rather say it out loud than wait for a customer to say it for us.

The hard part is everything after.

An engineer with current tools produces in a week what used to take a small team a quarter. I'm not quoting a vendor. That's what I watch happen, and the time to a first working thing has dropped by an order of magnitude in two years without showing any sign of leveling off. Which means anyone whose value proposition is "we build fast," is selling something on its way to free.

Making something work once was always step one of about ten. Steps two through ten haven't moved: hardening it, getting it accredited, integrating it with real data at real volume, proving it doesn't break the system next to it, keeping it alive after the person who wrote it moves on. AI compressed step one and left the rest exactly where it was.

Our customers aren't drowning in prototypes yet. I think that's timing, not a reprieve. When producing something plausible costs two weeks instead of two quarters, the number arriving on a sponsor's desk only goes one direction, and the ability to tell them apart doesn't move at all.

When everyone can produce a demo, a demo stops being evidence.

We have an answer to that, and I want to be careful how much credit I take for it. Foundry has spent more than a decade building engineering discipline around fast work: review, CI/CD, static analysis, dependency and vulnerability scanning, testing that actually runs. When something comes out of our shop quickly, it comes out with all of that behind it. That matters more than it used to, because code that a person didn't write by hand is code a person doesn't yet fully understand.

Discipline buys us time. It doesn't buy us a moat.

Everything I just listed will be purchasable off the shelf within a couple of years. Someone will sell a pipeline tuned for AI-generated code, and it will be good. Our lead there is measured in quarters, not decades, and any strategy resting on it is renting. So, what doesn't evaporate?

You can't download proximity.

The last twenty percent of getting something fielded is almost never algorithmic. It's certificate handling inside one specific enclave. It's the data convention nobody wrote down because everyone who touches the file already knows it. It's a transfer process between networks that changed two years ago and now lives in three people's heads. And more often than not, it's the operator's real workflow, which the prototype quietly assumed away.

AI is strong where information is public and weak where information is environmental. It can't retrieve what was never written down. For that, you have to be on the network, with the data, next to the person doing the job.

That's the part of this business I'd defend hardest. Our people aren't adjacent to the mission, they're inside it. Work doesn't reach us as a sanitized problem statement routed through a quarterly review. It reaches us as someone down the hall describing what slowed them down last week. The fix goes back the same way. When building is nearly free, the team that corrects fastest wins, and access is what sets the correction rate.

A small example - because the small ones make the point better than the big ones:

Operators were pulling a data feed, hand-picking the records they needed, reformatting them, and loading the result into a commercial modeling tool. Two to three hours a shift. Four to six hours a day, done by senior people who had better things to do.

The code to fix that is trivial. Kilobytes of text in, kilobytes of text out. Any current model writes it correctly in under a minute, and I wouldn't have needed a model for it in 2015 either.

The project still took weeks. Not because of the parser, but because of certificate discovery on user profiles, a truststore we had to embed, a transfer process between networks that nobody could name, a VPN blocking the endpoint we actually needed, and a single undocumented character in the feed that separates a real record from a false hit. None of that is written down anywhere a model could find it. All of it came from being close enough to ask and iterate.

That tool is part of a program baseline now, and other mission teams have asked for it. Here's the part I keep coming back to: The data volume those operators handle has more than doubled since we delivered, so the manual version of that job got twice as expensive. The tool costs what it always did. It's saving more today than the day we shipped it.

A prototype is worth what it was worth on demo day. A capability that made it into the mission appreciates.

That's the shift, and I think it favors us. It rewards knowing what's worth building, being honest about what already exists, and being willing to finish something somebody else started. It rewards the discipline to carry a thing from working to fielded, and the relationships to get it funded once it's there.

AI made the first step free. Every step after it is as hard as it was two years ago, and a few are harder.

That's where Foundry already lives. We live there because of where we sit.