The starting point
Working code isn’t the same thing as a product.
There was example code showing that the underlying technology could do something useful. It answered an important question: could this capability work? But it did not define the application people would actually use.
We still had to learn which problems mattered, which workflows the product needed, how people should interact with it, how they could evaluate its output, and what belonged now versus later. My work began in that ambiguity—not with a complete specification waiting to be implemented.
Product through iteration
The requirements weren’t sitting in a ticket queue.
I worked with stakeholders to identify an important problem, build enough to explore it, and put working software in front of people. Their use of the product exposed which assumptions held up and which needed to change.
Some ideas became more important. Others moved down the list. New problems became visible only after there was something concrete to use. Shipping was part of discovery: at 0-to-1, the goal is not to implement the original wishlist efficiently, but to learn what deserves to become the product.
Product around the technology
The model was only one part of the product.
An impressive technical capability is not yet usable production software. My responsibility was the application and product layer: shaping the experience, workflows, architecture, and deployment needed to make that capability useful to people doing real work.
Deployment progression
Then the deployment assumptions changed.
The product journey eventually had to survive environments very different from ordinary startup SaaS.
Prototype
Technical capability demonstrated.
Production Product
A real application and usable workflows.
Cloud
Production deployment in a connected environment.
On-Premise
Software deployable inside customer infrastructure.
Air-Gapped
Software able to operate in an isolated nuclear environment.
A connected cloud application can assume internet access, external services, remote operations, and familiar paths for updates and telemetry. Those assumptions change when software must run on-site inside isolated nuclear environments.
The important engineering story is not one particular infrastructure choice. It is the growing operational responsibility: the product had to mature as its environment became more demanding.
What it became
From an early product bet to an industry platform.
The product continued evolving after those early iterations. Atomic Canyon now describes NIVA—the Nuclear Industry Virtual Assistant—as powered by its Neutron technology and developed with nuclear industry organizations. In 2026, the company announced NIVA’s fleetwide launch.
That later progress belongs to Atomic Canyon’s expanding research, engineering, and leadership teams, and to its partners and customers. Read Atomic Canyon’s own accounts of NIVA, its fleetwide launch, and Neutron’s launch and deployment.