What Building Software for Rig Manufacturing Taught Us About Production Systems

Before Cerberus Labs, before insurance integrations and restaurant platforms, I worked on fabrication floors. The facilities - two in Houston and two in Barranquilla’s zona franca – held API Q4 certification and manufactured land drilling rigs - masts, substructures, and structural components for Pioneer Energy’s 60 and 80 series fleet, among other operators.

The work was steel cutting, machining, welding, and assembly. The only way to optimize productivity, cost control, and prevent loss was to lean into enhancing systems to extract, track, and monitor inputs and outputs throughout the production process. Behind every fabrication process, there had to be a synchronization of software systems and tools to function correctly, but in a world of fabricators and old school foremen production & materials management was lacking many key controls. I observed, learned, advised, and helped build those systems. What follows is what that work taught me about building software for environments where the requirements aren’t yet gathered, the domain rules are physics, and business logic is a very broad term.

The fabrication floor

A land drilling rig’s mast is the vertical structure that supports the crown block and traveling equipment - typically 100 to 160 feet tall on modern rigs. The substructure is the base that elevates the rig floor, supports the mast, and provides clearance for the BOP stack underneath. Both are structural steel assemblies that carry enormous loads: hook load from the drill string, setback load from racked pipe, wind load, and dynamic loading during operations.

The primary material is A992 structural steel - I-beams and H-beams with a minimum yield strength of 50 ksi. The steel arrives as raw plate and structural shapes from the mill. It leaves the facilities as welded, inspected, painted, documented assemblies ready for rig up field deployment.

Between arrival and departure: cutting, fitting, welding, inspection, assembly. Each step governed by fabrication blueprints, welding procedure specifications, and quality requirements that trace back to API and AWS standards. The steps were understood by the people doing the work. The controls connecting those steps - material traceability, consumable tracking, revision management - were where the gaps lived.

Welding consumables: where inventory management meets metallurgy

Every welder on the floor understood moisture. It’s fundamental to the trade - you learn early that wet electrodes produce bad welds. But understanding a principle and systematically enforcing it across shifts, work orders, and hundreds of electrode cans are two different problems. The knowledge lived in the hands of experienced welders. The controls didn’t exist in any system.

E7018 low-hydrogen electrodes are the workhorse consumable for structural steel welding via SMAW (stick welding). They’re hygroscopic - they absorb atmospheric moisture. AWS D1.1, the structural welding code that governs this work, requires that once a sealed container is opened, E7018 electrodes must be stored in a rod oven at 250-300°F. When a welder pulls an electrode for use, the exposure clock starts: a maximum of 4 hours outside the oven before the electrode is considered compromised.

Compromised how: absorbed moisture introduces diffusible hydrogen into the weld pool. As the weld cools, hydrogen migrates to the heat-affected zone and can cause hydrogen-induced cracking - delayed fractures that may not appear for hours or even days after welding. On a rig mast that will carry hundreds of thousands of pounds of hook load, a hydrogen crack in a structural weld isn’t a quality annotation. It’s a potential failure point, and failures in oil & gas are very costly.

Nobody asked for an inventory management system that tracked oven cycles. That requirement didn’t exist on paper. It came from watching the process - observing how electrodes moved from storage to oven to welder’s pouch to the weld joint, and recognizing what wasn’t being monitored. The system that emerged tracked:

• Lot numbers for full traceability - every weld tied to a consumable lot with a certificate of conformance
• Oven cycles - when electrodes entered the oven, how many reconditioning cycles they’d undergone (limited per AWS D1.1)
• Out-of-oven exposure time per electrode class, per shift
• Consumption rates per welder, per work order, for production planning and cost allocation
• Reorder triggers calibrated to production schedules, not just stock levels

The same discipline applied to flux-core wire (E71T-1C for FCAW), arc welding flux, shielding gas (CO2 and 75/25 argon-CO2 blends), and grinding consumables. Each had its own storage requirements, shelf life constraints, and traceability obligations. None of these had been systematically tracked before. The requirements came from the floor, not from a spec document.

Document control: when the wrong revision means scrap

Fabrication blueprints are the source of truth on a shop floor. Every cut, every weld joint preparation, every assembly sequence references a drawing revision. When I arrived, revision control was manual - paper drawings at work stations, updates distributed by hand, superseded copies pulled when someone remembered to pull them.

The failure mode was well known to everyone on the floor: a design change comes in mid-fabrication, engineering updates the drawing, and if the shop floor doesn’t receive the updated revision before the next shift starts cutting, the work proceeds against an obsolete design. Best case: rework, which costs time and material. Worst case: the part is scrapped because the old geometry can’t be modified to meet the new spec.

The foremen knew this risk. They managed it through communication and vigilance - walking the floor, checking stations, relying on experience to catch discrepancies. It worked most of the time, but “most of the time” in a production environment where scrap means losing thousands in material and labor isn’t a control, it’s really just a pattern waiting to fail.

The document control system formalized what the experienced people already did intuitively: ensuring that superseded revisions were pulled from active stations, current revisions were distributed and acknowledged, and no work order could proceed against an uncontrolled document. The value wasn’t in replacing their knowledge, it was in making the process consistent across every shift, every station, every crew - especially the ones without a 20-year foreman watching over them.

CNC plasma and material optimization

The facilities ran CNC plasma tables for cutting structural plate, along with turning and machining operations for components and parts. The cutting itself is straightforward - a computer-controlled plasma arc follows a programmed toolpath through steel plate. The engineering challenge is in what happens before the torch fires and after the parts are cut.

Nesting software arranges part geometries on available plate stock to maximize material yield. A bad nest - poor arrangement, excessive kerf allowance, ignoring common-line cutting opportunities - wastes significant material. On heavy structural plate, that waste is measured in thousands of dollars per run. Before the nesting was optimized, material yield was driven by whoever was programming the table that day, with no systematic approach to minimizing scrap.

The extraction protocol bridged the gap between what the design required and what was procurable. Fabrication drawings specify part dimensions. Plate stock comes in standard sizes from the mill. The system matched required cuts against available plate, optimized nesting layouts for yield, and generated procurement requests for non-standard sizes when the math didn’t work, and all before production scheduling committed to a timeline. In this industry, ebb and flow of orders is the norm due to the fluctuation of prices; delivery timelines are tight because you have to strike when the iron is hot.

This is the kind of problem where software has to understand constraints from three different domains simultaneously: engineering (what dimensions are required), procurement (what’s available and at what lead time), and production (what sequence minimizes idle time on the plasma table, or on the production floor assembling steel beams into structures). On the floor, these domains were managed by different people who coordinated through conversation and experience. The software becomes the integration point not replacing the coordination, but making it visible and systematic to where decisions can be better made and tracked.

International logistics: Colombia to Houston

We shipped materials, components, and completed rig assemblies via ocean freight between Barranquilla and Houston. The Caribbean corridor runs from Barranquilla’s zona franca to Port Houston, with 10-15 day transit times for standard sailings. The challenge isn’t the shipping, it’s the documentation chain that has to travel intact alongside the physical cargo.

Every structural member fabricated at the facilities carries a heat number stamped during production, traceable back to the mill test report (MTR) for the raw material. That traceability follows the part through every stage: cutting records, welding procedure documentation, NDT inspection reports, assembly verification, and finally the shipping manifest.

BOL creation - the Bill of Lading - ties the physical cargo to this documentation chain. Weight, dimensions, heat numbers, part serial numbers, HS codes for customs classification, DIAN compliance documentation on the Colombian side for zona franca exports. A BOL isn’t a shipping label. It’s simultaneously a receipt from the carrier, a contract of carriage, and a document of title.

On the receiving end, Port Houston inspection matches physical markings on each structural member against the packing list, the MTRs, and the fabrication records. Any break in the traceability chain means the part can’t be certified for use. The entire value of the fabrication work - the steel, the cutting, the welding, the inspection, the shipping - is contingent on the paperwork being intact, and also the expeditiousness of making it through customs and into either the customer’s hands or one of the facilities.

Before integration, the shipping documentation was assembled manually from multiple sources - fabrication records in one system, inspection reports in another, BOL creation handled separately. I integrated the BOL creation process into the parts control system so that shipping documentation was generated from the same data that tracked fabrication. No manual re-entry, no transcription errors, no mismatched heat numbers between the fabrication traveler and the shipping manifest.

What this taught me

Most of what I built on the fabrication floor started from observation, not from requirements. Nobody handed me a spec document that said “build an inventory management system that tracks electrode oven cycles.” The requirements emerged from watching the process, understanding what the experienced people on the floor already knew, and recognizing where their knowledge wasn’t captured in any system.

The domain rules are physics and metallurgy. Hydrogen doesn’t care about your database schema, and steel plate yields are governed by geometry, not by how elegant your nesting algorithm looks. Traceability requirements exist because structural failures kill people and cost money, not because a compliance officer needs a checkbox.

But “business logic” on a fabrication floor is broader than most software engineers encounter. It’s the welder who knows that a certain electrode shouldn’t be used on a certain joint configuration in humid conditions. It’s the foreman who can look at a stack of plate and tell you which sizes will nest efficiently. It’s the logistics coordinator who knows that a specific Colombian port has faster customs clearance for structural steel. That knowledge is business logic - it just doesn’t look like a Jira ticket.

Every system I build at Cerberus Labs carries what I learned on that floor: observe the process first, understand what the people already know, and build systems that make their knowledge consistent and visible. Technology is a means to an end - procurement cycles, material traceability, production schedules, quality compliance, payment processing, order management. The problem is always concrete, and the software is always in service of the operation.

That’s what rig manufacturing taught me: the tools change, but the principle doesn’t.