“You own all the IP” is a contract clause. Whether it means anything depends entirely on what’s in the handoff folder. Most clients don’t find out the two are different until they try to take a design to a second manufacturer or hand firmware to a new engineer. That’s when they discover that owning the IP and being able to use it are not the same thing.
A handoff can be legally complete and practically useless. Here’s what separates the two.
Hardware: Native Files, Not Just Outputs
PDF schematics are an output, not a deliverable. You need the native CAD project (KiCad, Altium, whatever was used) with every library, symbol, and footprint that project references. A PDF shows you the design. The native files let you change it, or hand it to a different engineer who can.
Gerbers plus drill files plus an IPC-356 netlist, not gerbers alone. The netlist is what lets a new fab house or a new assembly house verify their output matches the design intent, rather than trusting that their interpretation of the gerber layers is correct. Without it, a second-source fab run is a leap of faith.
A BOM with manufacturer part numbers and at least one approved alternate per critical component, not just values. “10uF ceramic capacitor” isn’t a BOM line, it’s a placeholder that forces whoever builds the next batch to make sourcing decisions the original design never validated.
Assembly drawings with orientation and polarity marked, and a stencil file if the board uses fine-pitch parts. Without these, a new assembly house is reverse-engineering placement from a bare PCB.
Firmware: Source, Build, and the Path Between Them
Source code, not compiled binaries. This sounds obvious and is the single most common gap. A binary lets you flash the device. It does not let you fix a bug, add a feature, or pass the project to a new firmware engineer without a full rewrite.
A build system that reproduces the exact binary that shipped, including toolchain version, compiler flags, and any vendor SDK version pins. Firmware that only builds on the original engineer’s laptop, because of an undocumented toolchain version or an environment variable nobody wrote down, is source code in name only.
Flashing and provisioning documentation: what programmer, what interface, what sequence, and what factory calibration or unique-per-unit data (serial numbers, calibration constants, keys) gets written and how. Without this, manufacturing can build the boards and have no way to bring them to life.
Design rationale for the non-obvious decisions, especially around timing, interrupt priority, and any workarounds for silicon errata. A comment explaining why a delay exists, or why a peripheral is configured in a way that looks wrong but isn’t, saves the next engineer the exact debugging session the original engineer already went through.
Test and Validation Records
Test procedures, not just test results. A report saying “unit passed EMC pre-compliance” is far less useful than the procedure that produced it: what setup, what limits, what configuration was under test. Procedures let you re-run validation after a change. Results alone just tell you what happened once.
Any custom test fixtures or jigs, with their own schematics and firmware if they have any, and the calibration procedure for them. A functional test fixture that only the original team knows how to calibrate is a second undocumented product hiding inside the first one.
What Incomplete Looks Like in Practice
The common failure mode isn’t a vendor withholding files out of bad faith. It’s a handoff built from whatever the engineering team happened to save along the way, with no one responsible for the question “could someone else build and support this without us.” PDF-only schematics because that’s what got emailed to a fab house. A binary because the firmware engineer never set up a clean build environment on a second machine. A BOM with values because the actual sourcing happened ad hoc during procurement and nobody wrote the decisions back into the document.
None of it is a legal problem. All of it is a practical one, and it surfaces at the worst possible time: the original team is gone, the manufacturer needs a second production run, or a bug shows up that needs a firmware fix. That’s when “we own the IP” turns out to mean “we own a folder we can’t do anything with.”
Why This Should Be Specified Upfront, Not Discovered at the End
A handoff package this complete takes deliberate effort to produce. It doesn’t happen by accident from an engineering team focused on making the board work, because “does it work” and “can someone else maintain it” are different goals that pull in different directions under schedule pressure. If a handoff isn’t scoped explicitly at the start of an engagement, what you get at the end is whatever was convenient to save, not what you’ll actually need eighteen months from now when the original engineers are on a different project.
Ask what’s in the handoff before the engagement starts, not after it ends. “Full IP ownership” is only worth what the files behind it let you do.
If you’re scoping a program and want the handoff spec written down before work starts, that’s part of how we structure every engagement.