Software teams take Git for granted. Hardware needs an equivalent discipline — but the unit of change isn't a line of code, it's a board revision, a BOM line, or a single substituted component.
Hardware teams sometimes borrow the phrase "version control" from software without adopting the actual discipline behind it. CAD files can live in a Git repository, but the harder problem — tracking which exact configuration of components, footprints, and firmware shipped in which units, and being able to answer "what changed and why" months later — needs practices that go beyond just storing files in a repository.
A software change is fully captured by a diff — the code before and after. A hardware change often isn't fully captured by the schematic/layout diff alone: a component substitution might change electrical characteristics in ways not obvious from the file diff, a footprint change might affect assembly without changing the schematic at all, and the actual as-built unit depends on which component revision was in stock and used at assembly time, not just which was specified. Real hardware traceability requires tracking more than file history.
A consistent revision scheme — distinguishing schematic-level changes, layout-only changes, and BOM-only substitutions — makes it possible to know at a glance how significant a given revision actually is, rather than treating every "Rev C" as equally different from "Rev B." Many teams use a scheme where a major revision number changes for functional/schematic changes and a minor one for layout or cosmetic changes, silkscreen fixes, or BOM substitutions that don't affect function — though the specific scheme matters less than having one applied consistently.
BOM changes are where version control and cost optimization intersect most directly — a substitution made to hit a price target is still a change that needs the same tracking discipline as one made for availability.
When a field issue surfaces, being able to answer "which board revision and BOM configuration is in this specific unit" is what turns a vague "some units might be affected" into a precise, actionable recall or fix scope. This requires linking manufacturing lot/serial data — coordinated with your contract manufacturer — back to the specific board revision and BOM configuration used for that production run, a connection that has to be deliberately maintained through manufacturing, not reconstructed after the fact from incomplete records.
A formal ECO process — documenting what's changing, why, what's affected (schematic, layout, firmware, documentation, certification status), and requiring sign-off before the change ships — is the hardware equivalent of a code review and merge process. It's most valuable exactly when it feels like unnecessary overhead: a small, "obviously fine" substitution made without going through the process is precisely the kind of change that causes a hard-to-trace field issue later, because it was never documented as a deliberate change in the first place.
We apply consistent revision numbering, BOM change logging, and traceability practices from the first prototype board onward, so the discipline is already in place by the time it matters at production scale. See our embedded hardware work for how this fits into a full hardware engagement.
Related reading: a design revision usually starts life as either a DFM/DFT finding or a schedule tradeoff — see our notes on estimating a realistic hardware timeline for how revision cycles factor into a schedule.
