For technicians and integration engineers on the world’s most complex hardware programs, the gap between “what we designed” and “what actually got built today” is the difference between confidence and chaos.
At Stoke Space that gap became existential. While racing to build a fully reusable launch vehicle with daily design iterations, every off-the-shelf manufacturing software tool failed under real shop-floor pressure. So, the team built their own. That system is now Boltline — and it’s commercially available to any team fighting the same fight.
We sat down with Brent Bradbury, Head of Business at Boltline, to hear how a rocket program inspired the launch of a software business.
“At Stoke, we set out to build a rocket, but even while we were still in early prototyping, off-the-shelf software tools were insufficient to meet our demands. It became clear we needed an engineering toolset that could manage design, engineering, and production of a highly complex, fast-paced project, while offering traceability, repeatability, and audit readiness. None of the tools that already existed met the needs of our complex hardware and fast-paced environment—so we built it ourselves.”
- Brent Bradbury, Head of Business for Boltline
Origins from Stoke Space
How did a rocket program force a software company into existence?
Stoke’s entire bet is full and rapid reusability — both stages flying again with airline-like cadence and minimal refurbishment. Because the goal is to recover and reuse the second stage, it needed an entirely new actively cooled metallic heat shield designed for rapid turnaround after reentry.
“The real bottleneck wasn’t propulsion or materials. It was iteration speed”, explained Bradbury. “When you’re rebuilding, retesting, and reconfiguring hardware daily, any gap between ‘what’s built’ and ‘what’s recorded’ becomes a liability.” Software stopped being an IT concern and became core engineering infrastructure.
Instead of bolting together separate tools for every discipline, Stoke built one unified system from the ground up: the same real-time software that runs both the vehicle and test stands also provides a single data layer tying test data to BOMs and as-built history, with thin, team-specific layers on top. These core elements became Boltline.
What does Boltline actually do to control daily hardware interactions?
At Stoke the cycle is simple and unforgiving: design → build → test → analyze → repeat — often inside 24 hours. At that pace, configuration drift is the enemy. Engineers and techs need instant, certain answers to key questions:
- What was actually built?
- How was it built?
- Which parts were used?
- Where does everything sit right now?
- When was this step completed?
- Why did it behave differently than expected?
“Boltline sits directly in this loop so we can preserve the state and intent across that cycle,” says Bradbury. “It captures the as-built state of hardware while work happens, not after the fact. When a test is run, the data is automatically tied to the exact configuration that was on the stand. Snapshots can be taken before hot fires, reassemblies, or major changes, so results are anchored to reality. Without that, teams burn time reconstructing history before they can even start diagnosing a failure.”
Can you give a concrete example of how that plays out?
One of the clearest examples involves a complex welded barrel assembly that was taking too long to complete. The initial instinct—common in capital-intensive settings—was to add welding stations and expand floor space.
“Instead, we used Boltline to map the work plan in detail and found that the bottleneck wasn’t welding—it was inspection sequencing,” Bradbury recalls. “By moving certain checks earlier, deferring others into downstream test, and reducing redundant sign-offs, we cut the cycle without adding welders, stations, or square footage.”
That kind of decision only becomes obvious when the work itself is visible and structured. Boltline didn’t just record the process; it made the inefficiency legible.
Another example: A batch of washers was found to be out of spec after 10,000 had been purchased. Bradbury explains: “Using Boltline, the team traced where that batch had been issued and identified the specific shelf locations and affected assemblies. Four washers were ultimately found inside an engine. The issue was contained within two hours, the engine was reworked, and a hot fire happened the same day.”
“That kind of speed builds confidence. Confidence keeps people using the system. Usage keeps the data accurate.”
What does using Boltline look like day-to-day for an engineer or technician?
For technicians, Boltline is the authoritative build guide. Work instructions, torque values, configuration steps, redlines from responsible engineers, and sign-offs are available directly where the work happens. QR codes on parts pull up full history back to design, so technicians don’t have to hold details in their head or backfill information later.
Engineers and integration leads keep Boltline open next to CAD. One screen shows what the system is supposed to be. The other shows reality: exactly what’s built, what’s open, what changed, what failed, and the exact configuration at any given time. Anomaly investigations that once required hours, now only takes seconds.
The system runs on tablets and devices already used in the flow of work, instead of forcing people to remember details and backfill them later at a desktop. That matters for adoption.
In theory, any system—even a sprawling network of spreadsheets—can technically track a single washer. In practice, it’s impossible. Technicians simply won’t enter the required information unless the system makes their job dramatically easier. And even if they could, keeping a network of systems connected in a meaningful and scalable way is inoperable.
Broader Landscape
Why do existing ERP and MES tools fall apart on fast hardware?
Traditional ERP and MES systems assume slow cycles, stable products, and heavy overhead. In programs moving at Stoke speed, they add friction. Engineers work around them. Techs keep notes in their heads or on paper. The “system of record” quietly drifts from reality.
“Boltline is built from the shop floor up,” says Bradbury. “It looks and behaves like modern software. Things are where you expect them to be.”
Boltline overlaps with MES but goes far beyond it — upstream into engineering, downstream into test, operations, and maintenance. It replaces disconnected tools with a single source of truth that stays accurate even when hardware changes daily. For advanced hardware programs, it functions more like the digital backbone of the factory.
“Our customers don’t adopt it because leadership mandates it,” Bradbury notes. “They adopt it because it helps them do their job.”
Is this just a rocket problem?
The same dynamics hit aerospace, defense, energy systems, robotics, EV platforms, and biotech hardware. As iteration speeds increase, lagging tools don’t just slow teams down — they create real risk.
Good communication between hardware and software teams isn’t about more meetings. It’s about shared confidence in the underlying data. Boltline links technicians, engineers, and leadership end-to-end so the whole team operates from the same reality instead of negotiating whose version is correct.
What’s the long-term goal?
“It’s simple,” says Bradbury. “Make real-time hardware development the new normal and close the intent-to-reality gap.”
In that future, traceability isn’t something teams scramble to reconstruct after a failure or an audit. It’s ambient—maintained continuously as work happens, so hardware teams can move fast without losing confidence in what they’ve built.
To see Boltline’s shop-first hardware development platform in practice, visit boltline.com/demo.
