For technicians and integration engineers working across aerospace, defense, energy systems, robotics, and EV programs, having software that can keep up with the complexity and pace of hardware development means the difference between confidence and guesswork. When designs change daily, the hardest part is keeping design intent, build state, and test results aligned.
That problem came to a head at Stoke Space as the team worked to build a fully reusable launch vehicle under extreme iteration pressure. Boltline emerged from that effort, not as a product idea, but as a response to the failure of existing tools under real shop-floor conditions.
This conversation with the extended Boltline team unpacks how a reusable launch vehicle program produced a software startup, and what that experience reveals about building complex hardware under real constraints.
""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
Stoke’s core bet is full and rapid reusability. First-stage reuse changes launch economics, but most cost and operational friction remains in the second stage, which is still typically discarded. If the second stage remains expendable, true airline-like cadence is impossible.
Our premise was straightforward: both stages must launch, return, and fly again with minimal refurbishment. That need drives everything downstream, including a second stage with an actively cooled metallic heat shield designed for rapid turnaround after reentry.
To achieve this goal in record time - just 6 years after its founding - we realized the real constraint isn't propulsion or materials: it is the speed of engineering iteration. When hardware is rebuilt daily, tested continuously, and reconfigured between runs, any gap between what’s built and what’s recorded becomes a liability. Software stopped being an IT concern and became part of the engineering system.
Creating a Unified Software Backbone
Stoke avoided building separate software tools for propulsion, avionics, test, and manufacturing. Instead, the software team focused on shared foundations that could be reused everywhere.
For vehicle and test control, that means a single runtime. The same software that controls the rocket also runs the test stands. That means control logic, verification, and fault handling are developed once and exercised continuously throughout development.
At the same time, the team needed a unified way to track the hardware itself as it changed. On the data side, we kept a single data tier that combines time series data from tests and flights with the BOMs and configuration histories that come out of manufacturing. Everyone is operating against the same understanding of what was built, what was tested, and what flew. From there, we only add thin layers for the needs of specific teams.
That unified way became Boltline.
Building with Boltline
At Stoke, the hardware loop is simple and unforgiving: design, build, test, analyze, repeat. Parts are often rebuilt and retested in under a day, where each test introduces constant, changing variables and engineers have to keep track of the performance of their system. At that pace, configuration drift becomes the enemy.
The cycle is design, build, test, analyze, and repeat.
Engineers and technicians need to answer a few basic questions with certainty:
- Did I build what I said I would build?
- Did I build it the right way?
- Does it behave the way I expected?
- Is this assembly step acting on the right part/subassembly?
Boltline sits directly in this loop so we can preserve the state and intent across that cycle. 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.
Making Bottlenecks Visible
One thing we’ve seen firsthand is that when throughput slows in a rocket factory, especially in capital-intensive settings, the first instinct is almost always to add equipment or hire more people.
At Stoke, a complex welded barrel assembly was taking too long. The initial question was whether to add welding stations and expand floor space. Instead, the team used Boltline to map the work plan in detail and found the bottleneck wasn’t welding — it was inspection sequencing.
By moving certain checks earlier, deferring others into test, and reducing redundant sign-offs, the team 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 inefficiency legible.
Boltline on the Shop Floor
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 do not have to hold details in their head or backfill information later.
For engineers and integration leads, Boltline often sits open next to CAD. One screen shows what the system is supposed to be. The other shows what is actually being built, tested, or reworked, including open work, change history, test outcomes, failures, and the configuration present when something broke. Anomaly investigations start immediately, not after hours of data archaeology.
In one case, a batch of washers was found to be out of spec. Ten thousand had been purchased. Using Boltline, the team traced where that batch had been issued and identified the specific shelf locations and assemblies affected. 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.
Where Existing Tools Break Down
In theory, any system, even a spreadsheet, can tell you where a washer is. In practice, that only works if technicians actually enter the information — and they won’t unless the system makes their job easier.
Traditional ERP and MES tools assume slower cycles and heavier overhead. In fast-moving programs, they add friction. Engineers work around them. Technicians keep notes elsewhere. The “system of record” quietly drifts away from reality.
Boltline is built from the shop floor up. It looks and behaves like modern software. Things are where you expect them to be. It 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.
Applications Beyond Manufacturing
We're building Boltline to extend beyond just build configurations. In test and maintenance environments, run time, pressures, temperatures, and duty cycles are tracked against individual parts and serial numbers. When thresholds are reached, tear-downs are triggered. If a valve fails, its full history—build, test, usage—is immediately available for forensic analysis.
This applies equally to predictive and non-predictive maintenance. Non-conformance reports, anomaly notes, and special handling instructions are visible to technicians in real time.
The system is optimized for integration engineers but abstracted cleanly for engineers, leadership, and finance. Purchasing decisions improve because inventory is trusted. Hiring and capex decisions improve because actual touch time and utilization are visible. Teams stop guessing whether they need more people or just better flow.
MES, ERP, or Something Else?
Boltline overlaps with MES, but it isn’t confined to manufacturing execution. It extends upstream into engineering and downstream into test, operations, and maintenance.
It replaces handoffs between disconnected tools with a single source of truth that stays accurate even when hardware changes daily. For high-mix, low-volume programs, it functions more like a factory operating system than a traditional ERP or MES.
Our customers don’t adopt it because finance mandates it. They adopt it because it helps them do their job.
Broader Lessons
What does good communication between hardware and software teams look like?
Good communication between hardware and software teams isn’t about meetings. It’s about shared confidence in the underlying data. For avionics, it looks like putting firmware authors and hardware engineers in neighboring desks. For control systems teams, that means creating a shared understanding of the hardware that is being controlled and giving the right tools to the operators.
For Boltline, that means linking technicians, engineers, and leadership end to end so the whole team operates from the same reality and coordination becomes straightforward.
Do the lessons from rockets carry into other domains?
These dynamics aren’t unique to rockets. Aerospace and defense see them first, but the same problems show up in energy systems, robotics, EV platforms, and biotech hardware. As iteration speeds increase, lagging systems don’t just slow teams down—they actively create risk.
Boltline exists because those teams can’t afford that gap anymore — especially in environments with high iteration, traceability, and a need for clarity.
Looking ahead, the long-term goal is simple: 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.
If you want to learn more, visit boltline.com/demo to see Boltline’s shop-first hardware development platform in practice.
