Aerospace Manufacturing Software for AS9100 Suppliers: Problems, Solutions, and What It Costs to Build

Why aerospace supplier software makes or breaks an AS9100 supplier

It is 6:40 on a Monday and your quality engineer is on hour three of a first article. The part is a machined bracket for a nacelle assembly: 212 characteristics on the ballooned print. The balloons came out of InspectionXpert. The CMM data came out of PC-DMIS as a text report. The AS9102 Rev C Form 3 is an Excel template somebody built in 2016, and she is alt-tabbing between three windows typing measured values into cells, because your ERP has no concept of a characteristic. At 9:15 the prime pushes a drawing revision through Exostar. Two of the 212 characteristics moved. You now owe a partial FAI, and there is no button anywhere in your stack that tells you which two.

This is the normal operating model for suppliers between roughly $8M and $80M in revenue. The stack looks like this: E2 Shop System or JobBOSS2 or Global Shop Solutions or Epicor Kinetic for jobs, routers, and inventory. A SharePoint or Dropbox tree named by job number for mill certs and C of Cs. Net-Inspect because Boeing or Honeywell told you to use it. High QA or InspectionXpert for ballooning. Excel for gage calibration and shelf-life on sealants. A whiteboard for MRB. Email for supplier corrective action requests. Not one of those systems agrees with the others on what a part number, a revision, or a lot is, so a human is the integration layer.

Across our aerospace and precision manufacturing engagements, the consistent pattern Digital Heroes sees is that quality headcount grows faster than revenue. A $30M shop with nine people in quality, and when we shadow them, 30 to 40 percent of the quality engineer's week is transcription: moving numbers from one screen to another screen so a document exists. That is the leak. Not scrap, not machine hours. Typing. And it is worse than the labor cost, because the same gap is what turns an escape into a two-week investigation and what turns a Nadcap audit into a fire drill.

Problem: the first article takes 14 hours of typing, and the print changes anyway

In the shops we have walked, an AS9102 package on a 200-plus characteristic part takes a QE 10 to 14 hours the first time. Forms 1, 2, and 3 all restate the same identity data. Form 2 wants every material and special process with its certification source. Form 3 wants every characteristic, its design tolerance, its measured result, and the method. Then engineering releases Rev G, and because AS9102 requires a partial FAI on affected characteristics only, somebody sits with two PDFs side by side and eyeballs the delta.

Net-Inspect, High QA, and InspectionXpert each solve one slice: ballooning, or the prime's submission format, or a characteristic library. None of them know your router, your lot, your operator, or your gage. So the characteristic data lives in a quality island while the production data lives in E2, and the join happens in a person's head. E2 and JobBOSS2 were architected around jobs and operations. There is no first-class object called "characteristic" in them, and there never will be, because the addressable market for that object is aerospace and medical, not the general job shop they sell to.

What a custom build does differently: model the characteristic as a real entity, keyed to part number plus revision plus balloon number, with design nominal, tolerance, classification (key characteristic or not), inspection method, required gage type, and frequency. Import CMM output directly by parsing the Zeiss Calypso or PC-DMIS report and matching by balloon number, so measured values land without a keystroke. Generate Forms 1, 2, and 3 as output, not as input. Then, on a revision, diff the characteristic set programmatically and open a partial FAI containing exactly the affected balloons. AI earns its place here in one narrow spot: a vision model reading the ballooned PDF and the model-based definition to extract dimension, tolerance, and GD and T callouts into draft characteristics, with the QE confirming rather than typing. In our delivery experience, the correct target is not full automation, it is getting the QE from 14 hours to under 2, with a human sign-off gate that the auditor can see.

Problem: traceability lives in three systems and none of them agree

AS9100 clause 8.5.2 wants identification and traceability. In practice this means: this serialized part came from this heat lot of 15-5PH, which came from this mill cert PDF, which was cut on this machine by this operator, then went out to a Nadcap heat treat house on this purchase order, came back with this cert referencing this AMS2750 furnace run, then to chem film, then to a source inspection. When Spirit or Collins calls about a suspect lot, you need every part number and every ship date touched by that heat lot within hours.

Your ERP tracks a lot number for inventory value. It does not link that lot to a scanned PDF sitting in a folder named 2023-Q3, and it does not track the outside processor's cert as a child record of the operation. So the answer to "which parts touched heat lot 7A2214" is a person opening folders. Bolt-on QMS tools like ETQ Reliance or uniPoint add document control and CAPA workflow on top, but they inherit the same broken link, because they do not own the router either.

What a custom build does differently: one traceability graph. Serial or lot to heat lot to mill cert document to work order operation to machine to operator to outside process PO to returning cert to shipment to prime. Every edge is queryable, so a containment question becomes a search, not an archaeology project. Certs get ingested by AI document extraction on receipt: the mill cert PDF or the heat treat house's cert is parsed for alloy, heat number, spec revision, and expiration, then auto-matched to the receiving line and flagged when the spec called out on the PO does not match the spec on the cert. That single check catches the failure that produces most DPRV findings we have seen: the paperwork is present and technically wrong. Add shelf-life and cure-date tracking for sealants and prepreg driven off the same ingestion, with freezer log capture, and the Excel tab dies.

Problem: audits become a two-week fire drill instead of a query

Nadcap reaccreditation, AS9100 surveillance, and prime audits all ask the same shape of question: show me evidence, sampled at random, for the last 12 months. Calibration records for the gage used on this inspection. Operator certification for this weld. Pyrometry compliance for this furnace run. Training records tied to the revision of the work instruction in effect on the date the part was made. Most shops answer this by pulling three people off the floor for a week and building a binder.

Off-the-shelf QMS modules store the documents. They rarely store the point-in-time link, which is what the auditor actually tests. Your ERP knows the current revision of the work instruction. It does not know which revision was in effect on 14 March when serial 0042 ran, and it does not know that the operator's certification lapsed for eleven days in that window.

What a custom build does differently: everything is versioned and time-stamped, and the association is stored at the moment of use, not resolved at query time. When the operator scans into an operation, the system captures the work instruction revision, their current certification status, and the gage's calibration state and due date, and refuses the scan if the gage is out of cal. Audit prep becomes a filter: pick a date, pick a job, print the evidence chain. We have shipped this in a first release, and the honest result is not that the audit gets easier, it is that the shop stops paying three weeks of payroll to rehearse for it twice a year.

Problem: every prime wants a different format, and the scorecard punishes you for it

Boeing wants Exostar. Some programs want Net-Inspect for FAI and NCR submission. Lockheed, Northrop, and the rest have their own portals, and your name sits in the IAQG OASIS database while your delivery and quality scores sit on a prime scorecard that decides whether you get the next package. Meanwhile purchasing runs through SAP Ariba or Coupa and your ASN and packing slip formats differ per customer.

No ERP vendor will build first-class connectors to a dozen prime portals for a customer base your size. So you pay a person to be the portal. They rekey the same FAI into two places, and they find out about a scorecard hit six weeks after the shipment that caused it.

What a custom build does differently: one canonical record, many renderings. The FAI, the C of C, the ASN, and the packing list are all generated from the same data model, with a per-customer output profile that handles their part numbering scheme, their required fields, and their file format. Where an API exists, push directly; where only a portal exists, generate the exact upload file and log the submission. Then mirror the scorecard: track your own on-time delivery and quality escape rate against each prime's definition of it, including their clock (ship date versus dock date matters, and they do not use the same one), so the number surprises nobody. Forecasting helps concretely here: a model over your own routing history and current WIP that flags at day 4 of a 30-day lead time that this job will miss, while there is still time to expedite the outside process.

Problem: one escape turns into 40 hours of 8D archaeology

A prime returns 12 parts with an out-of-tolerance bore. You owe an 8D, containment within 24 hours, root cause and corrective action in 30 days. Containment means answering: what else did we ship with that same condition. If your inspection results are values typed into a PDF that got scanned back in, that question cannot be answered with software. It is answered by reading PDFs.

This is the compounding cost of the FAI problem. Because measurement data was never structured, you have no process capability history, no Cpk trend per characteristic per machine, and no ability to see that the bore drifted for three weeks before it went out. Off-the-shelf SPC tools can chart it if somebody feeds them, and nobody feeds them, because feeding them is more typing.

What a custom build does differently: because in-process and final inspection results are captured as structured values against the characteristic, containment is a query returning every serial with that characteristic outside limits, filtered to the ones already shipped, with the customer and ship date attached. Capability charts fall out for free. AI is useful in a narrow, verifiable way: drafting the 8D from the linked evidence (the NCR, the inspection history, the machine, the operator, the tool change log) and surfacing the three closest historical NCRs with the same characteristic and machine, so the QE argues with a draft instead of staring at a blank template. The signature and the root cause stay human.

What this costs and how long it takes

These bands are Digital Heroes delivery experience across 2,000+ projects, not a market survey. A focused first release in this category typically lands at $60k to $130k and ships in 12 to 16 weeks. Focused means: the characteristic data model, FAI generation with CMM import and revision diffing, the traceability spine with cert ingestion, and a read integration with your existing ERP. That is the release that stops the bleeding. A full platform, adding shop floor scan-in with gage and certification gating, NCR and CAPA and SCAR workflow, prime portal outputs, supplier quality, and scorecard mirroring, runs $150k to $400k phased over 6 to 12 months.

What drives price up specifically in aerospace supply: CMMC 2.0 Level 2 and NIST 800-171 scope, which can add meaningful engineering for access control, audit logging, FIPS-validated encryption, and a documented boundary, and which pushes you toward GovCloud hosting. ITAR handling, which constrains where data sits and who can touch the codebase, including your developer's own staffing. Deep CMM and DPD integration beyond report parsing. Multi-site with different Nadcap accreditations per site. And the number of prime-specific output profiles, because each one is a small integration with its own quirks. What does not drive price much: the number of users. Price scales with regulatory surface and integration count, not seats.

Build versus buy: take the position

Buy, without apology, if you are under roughly 25 people, single site, running a handful of part numbers on repeat orders, and your FAI volume is low. E2 Shop System plus High QA plus disciplined folder hygiene is a rational stack at that size, and a $90k build will not pay back. Buy also if your problem is accounting and inventory. Kinetic and Global Shop are better at that than anything we would write for you, and we will tell you so.

Build when these signals show up, and they show up together. Your quality headcount is growing faster than revenue. Somebody's full-time job is retyping data between systems. A containment question takes more than a day to answer. You have added a second site or a second Nadcap-accredited process and the tribal knowledge did not clone. Or a prime has made a scorecard number a condition of the next package and you cannot see that number in real time. At that point the off-the-shelf stack is not cheaper, it is just billed as payroll instead of capex, and it does not compound. Our position: keep the ERP for jobs, inventory, and money. Build the quality and traceability layer on top of it and own it, because that layer is the thing your primes are actually buying from you.

How to choose a developer for aerospace manufacturing software

Make them draw the data model on a whiteboard before you sign anything. If they cannot separate part, revision, characteristic, lot, heat lot, serial, and operation instance without prompting, they will build you a document manager with an aerospace paint job. The characteristic and the point-in-time association are the whole game, and a team that has not built this before gets it wrong in week two and finds out in month six.

Ask what they have integrated, specifically. Not "we do integrations." Have they parsed a PC-DMIS or Calypso report. Have they pushed to Exostar or Net-Inspect. Have they read from E2 or JobBOSS2 or Kinetic, including how they handled the vendor's read-only database posture and the fact that some of these systems will not give you an API worth the name. The answer tells you whether the estimate is real.

Test them on compliance before they test you. They should ask you about ITAR and CMMC scope in the first conversation, unprompted, and they should have an opinion about where the data lives and who on their team can see it. A developer who says "we will figure out hosting later" has just told you they will re-architect on your budget.

Insist on code ownership, a repository you control from commit one, and a written exit path. You are buying an asset that has to outlive the relationship and survive an auditor asking who can change a signed record. If the contract does not spell out who owns the code, the auditor question and the vendor question become the same question, and you will not like the answer.