Product Revisions Done Right: How AN Factory Tracks Every Hardware Change

It's 2 AM and your phone is buzzing. Your CM in Shenzhen just finished a production run of 3,000 units — but your engineer realizes they built from rev B schematics, not rev C. Rev C fixed a voltage divider that causes the sensor to drift after six months. The boards work. They'll pass every test. But in six months, your first customers will start reporting intermittent failures, and nobody will remember why.

This isn't a hypothetical. According to a study by Arena Solutions, the average hardware company processes 200–500 engineering change orders per year, and poor change management is the leading cause of production delays and quality issues. A single wrong-revision build can cost $50,000–$250,000 in rework, scrap, and delayed shipments.

The core problem isn't negligence. Your CM is building exactly what they were given. The problem is that "what they were given" lives in an email chain, a shared folder with seventeen versions of "final_BOM_v3_REAL_final.xlsx," and a Slack message from three months ago that said "use the updated resistor values." Hardware product revision management isn't a nice-to-have — it's the difference between a smooth production run and a costly recall.

Why Spreadsheets and Shared Folders Break Down

Every hardware startup begins the same way: the BOM lives in a Google Sheet, schematics get shared via Dropbox, and revision history is tracked by file naming conventions. It works for one product, one revision, one CM.

Then things get real. You have two products in different stages of development, three revisions in the field, and a CM asking which BOM to use for the reorder. The Propel PLM 2024 survey found that 67% of hardware companies still manage BOMs in spreadsheets, and the average engineer spends 8 hours per week just searching for the right version of a design file. A study from NIST (GCR 04-867) estimated that inadequate interoperability in the U.S. automotive supply chain alone costs $1 billion annually, with a significant share attributed to version mismatches and translation errors between design and manufacturing systems.

The failure modes are predictable:

• Stale files: The CM downloads a BOM on Monday. You update it on Tuesday. They build from Monday's version.
• Ambiguous naming: "SmartSensor_BOM_rev2_final_updated.xlsx" — which revision is this, exactly?
• No audit trail: When something goes wrong, you can't trace back to who approved which change and when.
• Cross-revision contamination: Components ordered for rev A get used in rev B because nobody flagged the substitution.
• Test program mismatch: The test program references pin mappings from an older revision, so functional tests pass on hardware that's wired differently.

Traditional PLM systems like PTC Windchill or Siemens Teamcenter solve this for large enterprises, but they're designed for organizations with dedicated configuration management teams. Licenses start at $5,000–$15,000 per seat per year, implementation takes 6–18 months, and the learning curve is steep enough that startups abandon them within weeks. What hardware startups need is revision control that's as natural as git — structured, auditable, and integrated into the tools their CM already uses.

How AN Factory Handles Product Revisions

We built revision management into the AN Factory platform because we kept seeing the same pattern: founders losing weeks to revision confusion that better tooling could prevent entirely. Here's how it works.

Products are first-class entities. Each product has a name, description, logo, and a list of revisions. You create a product once, and every revision, test program, and production run links back to it. The API is straightforward — POST /api/products to create, GET /api/products to list, full CRUD with update and delete. Every product gets a unique ID that becomes the anchor for everything downstream.

Revisions track every hardware change. Under each product, revisions represent distinct hardware versions — rev A, rev B, rev C. Each revision carries its own set of design files: schematics, Gerbers, BOMs, assembly drawings, whatever your CM needs to build from. POST /api/products/:id/revisions creates a new revision; GET /api/revisions/:id/files shows exactly which files belong to it. No more guessing which BOM goes with which board. Files are uploaded per-revision with a unique constraint — re-uploading the same file name overwrites cleanly instead of creating duplicates.

Test programs link to specific revisions. This is the detail that catches most teams by surprise. When your board layout changes between revisions — maybe the test pad locations shifted, or a sensor changed addresses — the test program needs to change with it. AN Factory lets you assign test programs directly to revisions: POST /api/revisions/:id/programs/:pid. When your CM pulls up a revision, they see exactly which test program to run. No ambiguity, no mismatch. According to Keysight Technologies, test program mismatches account for 15–20% of false test failures in electronics manufacturing.

Access control is per-product. Not every team or CM should see every product. AN Factory's access control grants or revokes organization access at the product level — POST /api/products/:id/access to grant, DELETE /api/products/:id/access/:org_id to revoke. Your CM sees only the products they're building. Your engineering team sees everything. Your investor demo account sees the products you choose to show. Role-based access follows NIST SP 800-162 attribute-based access control principles.

The Audit Trail That Saves You

When the FDA investigates a medical device failure, or when a customer returns a unit that shouldn't have shipped, the first question is always: which revision was this unit built from, and who approved that revision for production?

For medical devices under FDA 21 CFR 820, design control requires that every change to a product's design be documented, reviewed, and approved — with records that trace from the design input through verification and validation to manufacturing. The ISO 13485 quality management standard makes similar demands across international markets. Even outside regulated industries, ISO 9001 requires documented procedures for controlling product and service changes.

AN Factory's revision system creates this trail automatically. Every revision has a creation timestamp, a list of associated files with upload times, and the linked test programs. When your CM builds from a revision, the test results tie back to that specific version. You can answer the question "what exactly did we build, test, and ship?" without digging through email.

The NIST interoperability study found that 31% of the cost of poor data exchange in manufacturing comes from the need to manually verify, re-enter, or correct design data that moved between systems. When your revision data lives in one place — with files, test programs, and access controls attached — that verification cost drops to near zero.

What This Looks Like Day-to-Day

Here's a realistic workflow for a two-person hardware team shipping a consumer IoT device:

Monday: Your electrical engineer finishes the rev C board layout. They create a new revision in AN Factory, upload the Gerbers, updated BOM, and assembly drawing. The system records exactly what changed from rev B.

Tuesday: Your firmware engineer updates the test program to match the new pin mapping on rev C. They assign the updated test program to the rev C revision. The old test program stays linked to rev B — because you still have rev B units in the field that might need retesting.

Wednesday: You grant your CM access to the product. They log into the portal, see rev C with all its files, and know exactly what to build. No email chains, no "which version?" Slack messages.

Two weeks later: The CM runs production. Every unit tested gets results linked to rev C. You can see, from your dashboard, that 2,847 of 3,000 units passed first-time — a 94.9% first-pass yield. The 153 failures are logged with specific measurements, not just pass/fail, so your engineer can diagnose whether it's a design issue or a manufacturing variation.

Six months later: A customer reports an issue. You pull the serial number, see it was built from rev C, and check the test data. The voltage measurement that's now drifting was at the upper limit of the pass band during production. You tighten the limit for rev D and know exactly which other units from that batch might be affected.

This kind of traceability isn't luxury — it's the baseline for any hardware company that ships more than a few hundred units. The IPC Connected Factory Exchange (CFX) standard exists precisely because the industry recognized that machine-to-machine traceability data must flow automatically, not through spreadsheets and manual entries.

Getting Started

If you're currently managing revisions in spreadsheets and shared folders, the transition is straightforward. Create your product in AN Factory, upload your current revision's files, and assign your test program. The next time your CM asks "which BOM should we use?" the answer is a link, not an attachment.

The platform exposes everything via REST API and CLI (v0.6.0), so you can integrate revision management into your existing workflows — CI/CD pipelines, automated test setups, or scripts that sync design files from your EDA tool.

Every revision you track is a question you'll never have to answer from memory. Every file you attach is a miscommunication that never happens. Every test program you link is a mismatch that never reaches the production floor.

Your CM wants to build the right thing. Give them a system where the right thing is the only option.

Sources

• Arena Solutions — Engineering Change Management
• Arena Solutions — BOM Management Best Practices
• NIST GCR 04-867 — Cost Analysis of Inadequate Interoperability in the U.S. Automotive Supply Chain
• Propel PLM — BOM Management Survey 2024
• Keysight — Introduction to Electronic Test and Measurement
• NIST SP 800-162 — Guide to Attribute Based Access Control
• FDA — Design Control Guidance for Medical Device Manufacturers
• ISO 13485 — Medical Devices Quality Management Systems
• IPC — Connected Factory Exchange (CFX)
• LinkedIn — PLM System Cost Guide 2025