What files should I get from a hardware design firm?

The short answer

At To Be Named Labs, handover means you can take your product to any manufacturer or engineer without calling us. You should get native source files for every discipline — CAD, schematics, PCB layout, firmware, app and backend — plus manufacturing outputs, test procedures and a signed IP assignment. PDFs and exports alone do not count.

Owning Your Hardware5 min read

Most founders discover what they don't own on the day they try to switch vendors. The enclosure exists as a STEP file nobody can edit cleanly. The PCB exists as Gerbers with no layout source. The firmware exists as a binary. At that point you own a product you cannot change.

This checklist exists so that day never comes.

The rule: source, outputs, and the instructions to rebuild

Every discipline produces three kinds of files. You need all three.

Source — the editable native file the engineer worked in.
Outputs — what a factory or a phone actually consumes: Gerbers, STEP, binaries, app builds.
Rebuild instructions — tool versions, settings and steps so a new engineer can regenerate the outputs from the source.

Outputs without source lock you in. Source without rebuild instructions costs weeks of archaeology.

Mechanical and industrial design

File	Why it matters
Native CAD (SolidWorks, Fusion, Onshape, Creo — whatever was used) with full feature history	Editable geometry. A STEP file loses the design intent.
STEP / IGES exports of every part and the assembly	What toolmakers and machinists quote from.
2D drawings with tolerances, critical dimensions and material callouts	What the toolmaker is held to. No drawing, no accountability.
CMF specification — colour, material grade, finish, texture references	Without it, the second production batch looks different from the first.
Packaging dielines and inserts	Packaging is part of the product.

Electronics

File	Why it matters
Schematic source (KiCad, Altium, Eagle)	The only place the circuit logic lives.
PCB layout source with the board stack-up	Lets anyone revise the board.
Gerbers or ODB++, drill files, pick-and-place file	What the fab and assembly house consume.
BOM with manufacturer part numbers and approved alternates	Alternates keep your line running through shortages.
Assembly drawings and polarity / orientation notes	Prevents the classic reversed-diode batch.
Design notes: impedance-controlled nets, antenna matching, layout constraints	Stops the next engineer from breaking RF or high-speed routing.

The BOM deserves extra attention. A BOM with only distributor SKUs, or with single-source parts and no alternates, is a supply-chain risk you inherit silently.

Firmware

File	Why it matters
Full source repository with commit history	History explains why things are the way they are.
Build instructions with exact toolchain and SDK versions	Embedded SDKs break between versions. Pin them.
Bootloader source and configuration	Without it, you cannot change how updates work.
OTA update pipeline and documentation	Shipping devices you cannot update is shipping a liability.
Signing keys and credentials — transferred securely, with custody documented	Whoever holds the signing keys controls your fleet.
Test firmware used on the production line	Needed for every future batch.

Ask this directly: who holds the firmware signing keys after handover? If the answer is vague, your fleet belongs to someone else.

Software, app and cloud

Mobile app source with build configuration for each platform.
Backend source, database schema and migration scripts.
Infrastructure configuration — ideally as code — so you can redeploy elsewhere.
Admin access to every account: app stores, cloud provider, domain, email, analytics, certificate authorities. These should sit in your company's name from day one, not the studio's.
API documentation for the device-to-cloud protocol.

Test and manufacturing

Test plan and the results from every validation stage.
Test fixture designs — mechanical and electrical.
Assembly instructions for the factory, with photos.
A golden sample: a physical, signed-off reference unit.
Known-issues list. Every product ships with some. You should know them.

Legal

IP assignment signed by the studio covering everything created for your product.
Open-source component list with licences. A GPL library inside your firmware has real consequences.
Third-party licences for any paid SDKs, fonts or libraries, transferred to you or documented.

When full transfer isn't the default

Some engagements license parts of the stack — a firmware framework or backend platform the studio reuses across products — and price the engagement lower in return. That can be a fair trade. It must be explicit in the contract, before work starts. The bad version is discovering it at handover.

Red flags before you sign

The contract says "deliverables" without listing file types.
Accounts and repositories get created in the studio's name.
No mention of signing keys, alternates or test fixtures.
Handover happens "at the end" instead of continuously, milestone by milestone.

We push source to the client's repositories as we go. Handover then becomes a confirmation, not an event.

Questions founders ask

Who owns the IP when a studio builds my hardware?

It depends entirely on the contract. The default should be full assignment to you on payment. If any part is licensed instead, the contract must say which parts and on what terms.

Are Gerber files enough to own my PCB design?

No. Gerbers let a fab build the current board. You need the schematic and layout source to change anything.

What is a golden sample?

A physical reference unit that both you and the manufacturer sign off. Every production unit gets compared against it.

Should firmware signing keys be handed over?

Yes. Whoever controls the signing keys controls which firmware your devices accept. Transfer them securely and document custody.

When should handover happen?

Continuously. Source should land in your repositories at every milestone, not in one bundle at the end.

Tell us what you're building.

Send us the one-line version of your product. We'll come back with a technical read: the hard parts, what to cut for v1, and a realistic path from prototype to field.

Start A Project Hardware development See our work