Weld Tracking Software: Why Finding Every Weld One Welder Made Takes Three Days and a Binder

Why the weld record is the product, whatever you think you are selling

A radiography report lands on Thursday afternoon. Three rejects on spool 4412. The client's inspector is on site Monday and he will ask four questions: which welder made them, under which procedure, what is that welder's repair rate on this project, and what else has he welded on this order that has not been shot yet. Answering that means a marked up isometric for the weld numbers, a binder for the continuity log, a folder of PDF reports from the NDE subcontractor, and the production travellers from the shop floor. Three people spend most of Friday on it and the answer arrives Monday.

That is the shape of the problem in every fabrication shop we have worked with. You are not selling a vessel or a pipe spool. You are selling a vessel plus documented proof it was made correctly, and a vessel with a perfect weld and a missing procedure qualification record is a rejected vessel. The documentation is not wrapped around the product, it is half the product.

The stakes are asymmetric. A welder who drifts outside his qualified range for two weeks produces suspect welds distributed across every job he touched, and you find out when someone audits the continuity log. The cost is rarely the rework. It is that you cannot bound the problem quickly, so you re-examine far more than you needed to.

Problem 1: a weld does not have an identity, and everything else depends on one

Weld number 14 exists on this isometric, on the revision superseded last month, and on eleven other drawings across four jobs. On paper that is fine because the drawing gives it context. In a database it is the exact reason spreadsheet based weld logs collapse past a certain size.

What a custom build does first: give every weld a durable identity that combines job, drawing, revision, spool or component, and joint number, generated at the point the weld map is created rather than typed by whoever fills in the traveller. Everything else attaches to that identity: the procedure used, the welder, the filler lot, the parent material heat numbers on both sides, the fit up inspection, the visual, the NDE request, the result, the repair if any, and the repair's own examination. Once that spine exists, the Monday morning question becomes a query that runs in under a second. Without it, every feature you add is decoration on top of a paper process.

Problem 2: qualification range is computable, and almost nobody computes it

ASME Section IX defines what a welder qualification actually covers: process, filler metal grouping, base material grouping, thickness range, diameter range, and position, with continuity maintained if the welder has used the process within the preceding six months. Those are rules. Rules are the easiest thing in the world for software to check and the hardest thing in the world for a shop supervisor to check at seven in the morning when he is short two people and the spool has to move.

So it gets checked by memory. The supervisor knows Dawid is qualified for 6G on stainless. He does not have in his head that Dawid's continuity on that process lapses in August, or that the thickness on this joint is above the range his coupon covered.

What a custom build does: hold each welder qualification as structured data rather than a scanned certificate, then refuse the assignment. When a supervisor allocates a welder to a joint, the system checks process, base metal grouping, thickness, diameter and position against the qualification, checks continuity date, and either allows it or tells him exactly which parameter fails and which of his other welders is clear. It also produces the continuity report the client's inspector will ask for, current to that morning rather than to whenever the binder was last updated. This feature usually pays for the build, because it converts an error that is expensive and hard to bound into one that cannot happen.

Problem 3: what the incumbents do well, and where they stop

Give them fair credit. Kemppi WeldEye is strong on digital welding procedures and welder qualification, and it captures real arc data because it is built around connected Kemppi power sources. Fronius WeldCube is excellent at machine level data from Fronius equipment, down to parameter deviation per weld. Weldnote is a focused, sensible documentation tool for procedure specifications, qualification records and weld logs, and it does not pretend to be a shop floor system.

Two gaps show up in real shops. The first is that the arc data platforms are strongest inside their own hardware ecosystem, and most fabrication shops run mixed brands accumulated over fifteen years, including machines that will never be connected to anything. A system that only sees your Fronius units is a system that sees part of your shop.

The second gap is the one that actually hurts: none of them models your production flow. Your weld record has to travel with the spool through cutting, fit up, welding, examination, post weld heat treatment, hydrotest and painting, and it has to gather signatures at points your quality plan defines. Your NDE sampling rule, your customer's hold points, your data book structure and your repair authorisation route are yours. That is why the paper traveller survives alongside the software: the software holds certificates and the traveller holds the process.

Problem 4: progressive sampling is a rule you are applying by hand

Random examination regimes bring an obligation with them. When a random weld is rejected, the applicable code requires additional examination, typically of further welds by the same welder on the same run, and if those fail the scope expands again. This is exactly the kind of branching rule that gets applied inconsistently under schedule pressure, because expanding the scope on a Thursday costs you the weekend.

What a custom build does: apply the rule mechanically and log it. A reject automatically generates the additional examination requests, selects the welds according to your written rule rather than the QA coordinator's judgement, and blocks the affected items from progressing until the result is in. The value here is not only compliance, it is that nobody has to make an unpopular decision under pressure, because the system already made it and it is documented.

Problem 5: repair rate is your best leading indicator and you compute it once a year

Repair rate by welder, by procedure, by joint configuration and by shift is the single most predictive number in a fabrication shop, and in most shops it is calculated at the end of a project when it is useful only as an argument. Computed weekly it tells you that a welder is drifting before the client's inspector tells you, that a particular root configuration is producing lack of fusion on the night shift, or that a new consumable lot is behaving differently.

What a custom build does: compute it continuously from data the system already holds, and let a welding engineer slice it. Pair it with arc data from the machines you do have connected, because a rising repair rate on one welder plus wire feed drift on one power source is a maintenance problem rather than a competence problem, and treating it as the latter costs you a good welder.

Problem 6: the data book takes three weeks and a person

At the end of the job someone assembles the manufacturer's record: drawings, material test reports, procedure and qualification records, weld maps, NDE reports, heat treatment charts and hydrotest records. Every customer wants it structured slightly differently. It gets done by a QA coordinator with a scanner and a folder tree, and it often holds up invoicing.

What a custom build does: assemble it on demand, because every document is already attached to an object in the system and the customer specific structure is a template rather than a re-do. This is also the one place we would use document extraction. Material test reports and subcontractor NDE reports arrive as PDFs in dozens of layouts, and a model that pulls heat numbers, grades, results and weld identifiers out of them and matches them to your register removes the most tedious data entry in the shop. Route anything it is unsure about to a human queue. Do not let it write to the register unreviewed, because a wrong heat number in a code data book is worse than no heat number.

What this costs and how long it takes

A first release with the weld register tied to spools and drawing revisions, welder qualification with range and continuity checking, NDE request and result capture, and the traceability queries runs $45,000 to $110,000 in 10 to 14 weeks. Adding material heat traceability from receiving through to the weld, progressive sampling automation, repair rate analytics, arc data ingest from connected power sources, mobile fit up and visual inspection capture, and automated customer data books runs $130,000 to $340,000 over 6 to 10 months.

Cost drivers particular to this category: the number of codes you work to, because a shop doing ASME Section VIII, B31.3 and AWS D1.1 has three different rule sets for qualification range and examination and each is real work. Customer specific data book formats, where every major client has their own index. Arc data capture across mixed power source brands, where each brand is its own integration. Digitising weld maps, which is genuinely hard if your isometrics arrive as PDFs rather than from a CAD system that can export joint data. What keeps cost down: start with one code, one customer's document format, and the weld register plus qualification checking, which is where nearly all the risk sits.

Build versus buy, honestly

Buy if you have under about ten welders, one or two repeat customers, and a stable product. Weldnote plus a disciplined spreadsheet and a good QA coordinator will serve you, and a custom build would be a badge rather than a benefit. Buy WeldEye or WeldCube if your shop is genuinely single brand on power sources and your main interest is arc parameter monitoring, because reproducing what they do with their own hardware is not a good use of your money.

Build when two or more of these are true. You carry more than roughly twenty five qualified welders and continuity is managed in a binder. You work to multiple codes or produce data books to more than two customer formats. Tracing a rejected weld to everything else that welder touched takes more than an hour. Your material heat numbers are recorded on paper travellers and reconciled at the end. Or you subcontract NDE and the reports arrive as PDFs that somebody retypes.

How to choose a developer for weld tracking software

Ask them to model weld identity on a whiteboard before you sign. If they do not immediately raise the fact that weld number 14 is not unique and ask how your drawings and spools are numbered, they have not built this before and your first ten thousand welds will teach them.

Ask how they will represent qualification range. You want to hear structured attributes with rule evaluation, not a scanned certificate with an expiry date. A system that only stores the certificate cannot stop the wrong assignment, and stopping the wrong assignment is most of the value.

Ask what they know about your NDE workflow: request, subcontractor, report, acceptance, repair, re-examination and the progressive expansion rule. If examination is modelled as a pass or fail checkbox, walk.

Ask who owns the code, the repository and the hosting accounts, and get it written down before kickoff. At Digital Heroes the client owns it from the first commit. Your weld register is evidence in any future dispute or claim and it may need to be produced years after the job closed, so you need the unrestricted ability to export it and to hire anyone to maintain the system that holds it.