PCB Assembly Supplier Interview: 15 Questions and Red Flags
Direct answer: The practical answer to "What should a startup ask before trusting a PCB assembly supplier with a build?" is to use a documented decision gate, not a generic supplier promise. The target outcome is an interview scorecard pairing each question with useful evidence and warning signs. Start with the project fit gate: Ask which project characteristics trigger extra review or a different manufacturing route. Then review the package and people who can approve exceptions. Hold the project when the supplier claims every project is a fit. Exact manufacturing, inspection, sourcing, and test scope depends on the selected design and partner. This guide makes scope explicit before quotation, release, or the next build decision.
What decision does this guide support?
Capability lists are hard to compare and can hide how exceptions, changes, and failures are handled. This guide helps hardware startup founders and engineering leads shortlisting suppliers make decisions about supplier interview and evidence. Its information gain is question, evidence, red-flag, and follow-up columns. The framework below is a project-control tool, not a claim that one process, supplier, quantity, or lead time fits every board.
Hardware Startup Supplier Interview
Use this framework at the point where a project could otherwise move forward on an assumption. Each row names the evidence needed and a condition that should stop release until an owner resolves it.
| Evaluation area | Strong evidence | Red flag / hold condition |
|---|---|---|
| Project fit | Ask which project characteristics trigger extra review or a different manufacturing route. | The supplier claims every project is a fit. |
| File control | Ask how revisions, variants, and superseded packages are separated. | The answer is to email the latest files. |
| Sourcing | Ask how source traceability, alternates, shortages, excess, and approval are recorded. | Equivalent parts may be purchased without engineering review. |
| Build control | Ask what evidence gates setup, first article, continued assembly, and rework. | Equipment is discussed but release decisions are not. |
| Test | Ask who owns fixtures, software, limits, data, and failed-unit disposition. | Testing means only power-on unless later specified. |
| Failure response | Ask for the issue report format, containment steps, decision owner, and closure record. | A failure is handled without preserving evidence. |
Start with project fit
For the start with project fit step, use Project fit as the control point. Ask which project characteristics trigger extra review or a different manufacturing route. Treat this as a release decision rather than an administrative detail. Place the build on hold when the supplier claims every project is a fit. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Ask how changes are handled
For the ask how changes are handled step, use File control as the control point. Ask how revisions, variants, and superseded packages are separated. The useful evidence is a record another person can review without reconstructing the conversation. Place the build on hold when the answer is to email the latest files. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Ask for sourcing controls
For the ask for sourcing controls step, use Sourcing as the control point. Ask how source traceability, alternates, shortages, excess, and approval are recorded. This check should connect engineering intent to a purchasing or manufacturing action. Place the build on hold when equivalent parts may be purchased without engineering review. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Ask how test scope is agreed
For the ask how test scope is agreed step, use Build control as the control point. Ask what evidence gates setup, first article, continued assembly, and rework. A short written rule is more valuable than a broad assurance because it exposes the next owner. Place the build on hold when equipment is discussed but release decisions are not. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
Ask what happens when a build fails
For the ask what happens when a build fails step, use Test as the control point. Ask who owns fixtures, software, limits, data, and failed-unit disposition. The aim is not maximum paperwork; it is to prevent an unapproved assumption from entering the build. Place the build on hold when testing means only power-on unless later specified. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
15-question interview scorecard
For the 15-question interview scorecard step, use Failure response as the control point. Ask for the issue report format, containment steps, decision owner, and closure record. Close the step with an explicit pass, hold, or approved-deviation result. Place the build on hold when a failure is handled without preserving evidence. Record the input reviewed, its revision or date, the decision owner, and the action required. That record keeps a later sourcing, assembly, test, or repeat-batch decision tied to the same baseline.
How to use the framework on a real project
- Define the baseline. Identify the board revision, assembly variant, quantity, intended learning or delivery outcome, and files being reviewed.
- Assign decisions. Name who can approve engineering changes, sourcing substitutions, process deviations, test failures, and schedule tradeoffs.
- Record the result. Store the pass, hold, or deviation outcome with the build package so a repeat order does not depend on memory.
Questions to close before release
What evidence is sufficient?
Evidence should match the risk. A file reconciliation may be enough for one decision; a datasheet comparison, inspection record, controlled test, or engineering approval may be needed for another. The key is that the evidence is named before work proceeds.
Who owns an exception?
The party executing purchasing or manufacturing can identify an issue and present options, but changes to functional intent require an authorized customer engineering decision. Put that boundary in the RFQ or release record.
When should the project stay on hold?
Hold when the next action would make an unresolved assumption expensive, irreversible, unsafe, or difficult to trace. A documented hold is usually less costly than discovering after assembly that teams used different revisions or acceptance criteria.
Related Cyrionix resources
This guide strengthens the services topic owner. Supporting resources:
