You can spend three weeks on a layout — careful routing, a clean stackup, a DRC report with zero violations — and then undo all of that impression in the last five minutes by dropping a board_final_v2.zip into an email. The board might be excellent. The handoff says otherwise.

How you hand off a PCB communicates as much about your professionalism as the board itself. A raw zip attachment says "figure it out." A clean, documented, shareable package says "I know exactly what I built, and here's everything you need." The engineering is the same. The perception — and the number of back-and-forth emails — is not.

The complication is that "the handoff" is not one thing. A fab house, an assembly house, and a client each need a different package, and confusing them is where most delays come from. Here's what each one actually wants.

What a fab house needs

The fab house builds the bare board. It does not care about your BOM or your part numbers — it cares about copper, holes, and the notes that remove ambiguity. Give it:

  • Gerbers for every copper layer, both solder masks, both silkscreens, and the paste layers if relevant (RS-274X or the newer X2 format).
  • An NC drill file (Excellon) with plated and non-plated holes distinguished.
  • A board outline / mechanical layer so the router knows the exact shape.
  • Fab notes: layer stackup, finished board thickness, copper weight, surface finish (ENIG, HASL…), solder mask color, and minimum trace/space if you're near their limits.

The single biggest favor you can do a fab house is leave nothing to interpretation. Every unstated parameter becomes a default or a guess, and a wrong guess is a re-spin.

What an assembly house needs

The assembly house populates the board. It needs an entirely different set of files, and this is where handoffs quietly fall apart:

  • A BOM with valid, orderable part numbers — manufacturer part numbers or distributor SKUs, not "0.1uF cap" or an internal library reference nobody outside your company can look up.
  • A CPL / centroid (pick-and-place) file with each component's reference, X/Y position, rotation, and side.
  • An assembly drawing showing component placement, orientation, and any hand-assembly or do-not-populate notes.

A BOM that lists vague values instead of part numbers stops the line and generates a quote-blocking email. If you're targeting a specific assembler, match their expected columns and rotations exactly.

What a client needs (and it is not a zip)

Here's the part most engineers get wrong. When you hand off to a client, a project manager, or a non-EE stakeholder, they do not want your Gerbers. They cannot open them, and a folder of .gbr files reads as noise. What a client needs is confidence, delivered as something readable:

  • A summary they can skim — board name, revision, layer count, dimensions, status.
  • A 3D preview so a non-specialist can actually see the product.
  • DRC and ERC status — a green check communicates "this passed its own design rules" far better than a report they'll never open.
  • Access to the underlying files if they want them, without forcing the raw files on them up front.

A client who receives a clean dashboard link comes away thinking the work is under control. A client who receives rev_C_FINAL.zip comes away wondering what's inside and whether it's the right version. Same board, very different signal.

Audience at a glance

Audience What they need What they do not need
Fab house Gerbers, NC drill, board outline, fab notes (stackup, thickness, finish) BOM, CPL, 3D renders
Assembly house BOM with valid MPNs, CPL/centroid, assembly drawing Fab stackup notes
Client / stakeholder Readable summary, 3D preview, DRC/ERC status, optional file access Raw Gerber and drill files
Your future self Everything above, tied to a specific revision

A handoff checklist

Before you send anything, run through this:

  1. Every output comes from the same revision. One source, one export pass, no mixing.
  2. Gerbers open and render in a viewer that isn't the tool that made them.
  3. The drill file is present and included in the package (the most-forgotten file).
  4. The BOM has orderable part numbers, not values or internal references.
  5. The CPL matches the BOM — same references, correct rotations for your assembler.
  6. DRC and ERC are clean, or the exceptions are documented.
  7. Fab notes state the stackup, thickness, copper weight, and finish.
  8. The revision is visible on the package, the summary, and ideally the silkscreen.
  9. You're sending the audience-appropriate package — fab gets fab files, the client gets a link.

Common handoff mistakes

  • Mismatched revisions. A Gerber set from one commit and a BOM from another. The board comes back not matching its own documentation, and nobody notices until assembly.
  • Missing drill file. Gerbers describe copper and mask; the drill file describes holes. Ship without it and the fab house stops and emails you.
  • A BOM with the wrong columns. Values instead of part numbers, missing quantities, or an internal reference nobody can order from.
  • No fab notes. Leaving stackup and finish unstated forces the fab house to guess or ask.
  • Sending everything to everyone. Dumping the full raw package on a client, or sending the fab house your 3D renders, buries the files each party actually needs.

Sharing a link vs emailing files

Emailing a zip has three failure modes: it expires in an inbox, it captures a single frozen moment (so the "latest" version is whoever emailed last), and it drops raw files on people who can't read them. A shared link fixes all three — it always points at the current revision, it survives past the email thread, and it can present the right view to the right audience. We wrote more on the deeper problem behind all of this in KiCad's missing manufacturing package.

None of this requires a premium EDA suite. Altium bundles polished Output Jobs and a data-management layer, and if you're standardized on it, that handoff story is genuinely strong. But KiCad ships kicad-cli, which can export every file above from the command line — the raw capability is already there and free. What's missing in a bare KiCad setup is the packaging: turning those exports into one revision-locked bundle and a readable view.

That's the gap GoForFab fills. Connect a KiCad project and every push regenerates the whole package from one source in a single pass — Gerbers, drill, BOM, CPL, DRC/ERC, 3D renders — then presents it as a shareable dashboard and a downloadable bundle. The fab house gets its files, the client gets a link with a 3D preview and a green DRC check, and everything is tied to the same revision. It's free forever, so a professional handoff isn't something you assemble by hand at 11pm before a deadline — it's just what happens when you save your board.