How to choose an electronic product development company: 12 questions to ask

Most founders compare development firms on two things: the portfolio and the quote. Both matter. Neither tells you what happens when your Rev A board won't power up, when a key part suddenly has a 30-week lead time or when the engineer you met on the first call leaves the project. These 12 questions do.

Ask every firm the same 12 questions in the same order and write the answers down. Talking to 2 or 3 firms is usually enough. Get the important answers in writing too, because a promise on a call isn't a contract term. For each question you'll find what a good answer sounds like and the warning sign to listen for.

They fall into 4 groups of 3:

• Fit and people, questions 1 to 3: have they built something close to yours, and who'll actually do the work?
• Process, questions 4 to 6: how they handle requirements, reviews, updates and changes.
• Ownership and files, questions 7 to 9: who owns the result, in which formats, and what's in the handoff.
• Path to production, questions 10 to 12: manufacturing, certification and support after handoff.

1. What have you built that's close to my product, and which part did you do?

You don't need a firm that has built your exact product. Related experience counts for more. A team that has shipped 3 battery-powered wireless devices can design your wearable even if it's never made one. What you need to know is which part of each project they actually did, because a portfolio photo of a finished product might stand for one board, one review or the whole thing.

A good answer sounds like: two or three examples with a clear scope, such as "we did the schematic, layout and bring-up firmware, the client did the app and the enclosure", plus what went wrong and how it was fixed.

Warning sign: only finished product photos, no scope, and every project described as "end to end".

2. Who will work on my project, and who do I talk to each week?

The person who sells you the project often isn't the person who designs it. So ask for the roles: who leads the hardware, who writes the firmware, who reviews the design and who sends you the updates. Simplexity, a product development firm, advises looking for a named core team, with contractors added to it rather than making it up.

A good answer sounds like: named roles, 1 technical contact for your weekly questions and a reviewer who isn't the person who drew the design. Four people, four names.

Warning sign: "our team" with no roles, or a sales contact who can't answer a technical follow-up.

3. Will you sign a mutual NDA before we share technical details?

It's the easiest question on the list and it still filters firms. You shouldn't have to send a schematic or your feature list to get a 30-minute intro call. A mutual NDA protects you both and it's normal in engineering services.

A good answer sounds like: "yes, before any technical discussion", with a short NDA you can read before the call. Often it's 2 or 3 pages.

Warning sign: they want your full feature list or files before any agreement. Or they won't sign any NDA at all.

4. Will you help me write requirements with numbers before design starts?

You can't test "long battery life". You can test "7 days on one charge at 1 report per minute, at 0 to 40 °C". A good firm will push you to write numbers like that down before anyone opens a CAD tool, because they become the pass and fail limits for every build after. Our EVT, DVT and PVT guide shows how those limits turn into exit criteria.

A good answer sounds like: a short discovery or architecture step with a written requirements document, a block diagram and a risk list you approve.

Warning sign: they go straight to layout from your pitch deck. Or they treat requirements as your problem, not theirs.

5. Where are the review gates, and how will I see progress?

Ask them to walk you through the process from the first call to the last production file. You're listening for fixed checkpoints, like a schematic review before layout starts and a design review before files go to fabrication. And you want to know what lands in your inbox at each one.

A good answer sounds like: named steps, a review with your team at each milestone, written updates every week or two and version control for drawings and code. On a 4-layer board that might mean 3 reviews: schematic, placement and final release.

Warning sign: "we'll send it when it's done", or a first look at the design after boards are already ordered.

6. How do you quote the work, and how are changes handled?

Hardware scope changes. A part goes end of life, a sensor doesn't hit spec in week 6 or your investors want a second radio. That's normal. What isn't normal is finding out about a change and what it did to your schedule and budget on the invoice. You should hear about it before the work is done.

A good answer sounds like: a written scope per phase with a fixed quote or a clear estimate. If a change adds 2 weeks, you see that in writing and approve it before work starts.

Warning sign: no written scope, or an open-ended estimate with no checkpoint where you can stop.

7. Who owns the designs and code, and when does ownership transfer?

Don't assume that paying for the work means you own it. Under US copyright law a commissioned work counts as "made for hire" only in 9 listed categories, and only if both sides sign a written agreement saying so. That's from Circular 30 of the US Copyright Office. Firmware and design files usually aren't in those 9 categories, so you need a written assignment clause. Have your lawyer check the wording.

Two more details belong in the same clause. Background IP is what the firm brought with it, like its own code libraries and templates. Foreground IP is what it created for you. ByteSnap, an embedded design firm, notes that foreground IP often transfers only once every invoice is paid. That's fair, but you need to know it. You also need a licence to any background IP that ends up inside your product.

A good answer sounds like: "you own the designs, source code and files we deliver", written into the contract, with background IP and its licence listed.

Warning sign: the firm keeps the source and licenses it back to you. Or the contract doesn't mention ownership at all.

8. Which file formats will I receive?

A PDF schematic and a set of Gerber files let a factory build your board. They don't let another engineer change it. For Rev B you need the native design files from the CAD tool, the component library, the full firmware source with its Git history and the build instructions.

A good answer sounds like: native project files in a mainstream tool such as Altium Designer or KiCad, plus the library, BOM, fabrication and assembly outputs and a Git repository with every commit.

Warning sign: "you'll get the Gerbers and a PDF", or source code only as a compiled image.

9. What exactly is in the handoff package?

The handoff is where projects quietly go wrong. Ask for the list now, not in the last week. Then hold it up against what your contract manufacturer will ask for: fabrication files, assembly files, a BOM with manufacturer part numbers, drawings, programming files and test instructions.

A good answer sounds like: a written deliverables list with production files, BOM, source code, test procedures and documentation, released together under one version number such as Rev A 1.0.

Warning sign: "we'll send whatever you need", or files sent piece by piece over email with no version number.

10. How do you design for manufacturing and test, and who talks to the factory?

A board that works on your bench can still be hard to build or slow to test. Design for manufacturing (DFM) and design for test (DFT) checks catch that before fabrication, when a fix costs an edit and not a respin. Ask when those checks happen and who answers the factory's questions when they email about your files.

A good answer sounds like: DFM and DFT checks before files are released, a test point on every power rail and bus you'll need to probe, and support for your contract manufacturer during the first 2 builds.

Warning sign: "the factory will sort it out", or no plan for how each unit will be tested.

11. Who handles certification, and what do you do before the lab?

No design firm can certify your product on its own. Embedded Artistry places formal certification such as FCC and UL in the DVT build, and an accredited lab does that testing. What a design firm can do is design for compliance from the first schematic and run pre-compliance checks, so your lab visit confirms what you already know.

A good answer sounds like: "we design for the standards your product needs, run pre-compliance on 2 or 3 early units and support you with the lab".

Warning sign: "we'll get you certified", with no mention of an accredited lab, or certification left until after the design is frozen.

12. What happens after handoff?

Your product will need firmware updates, a second source when a part runs short and a Rev C when the first 500 units show something new. Ask what support looks like after the last file is sent. Ask whether they'll work with your own engineer if you hire one in year 2. And ask for a list of the third-party and open-source code inside the firmware, because each licence comes with its own conditions.

A good answer sounds like: a clear way to get help after handoff, documentation another engineer can pick up and a list of third-party code and licences.

Warning sign: files that only the original firm can work with, or no answer on what happens after the last invoice.

After 3 calls the answers blur together. So score each question right after each call while it's fresh. Give 2 points for a clear answer you have in writing, 1 for a good answer you only heard on the call and 0 for a vague answer or a warning sign.

#	Question	Score 2 when
1	Similar work and your role in it	Examples with a clear scope and a lesson learned
2	Who works on the project	Named roles, one technical contact, a separate reviewer
3	Mutual NDA first	NDA signed before any technical discussion
4	Requirements with numbers	A written requirements step you approve
5	Review gates and progress	Named checkpoints, written updates, version control
6	Quotes and changes	Written scope per phase, changes approved before work
7	Ownership	You own designs, code and files, in the contract
8	File formats	Native CAD, library, BOM, firmware repository
9	Handoff package	A written deliverables list released as one version
10	DFM, DFT and the factory	Checks before release, test plan, factory support
11	Certification	Design for compliance, pre-compliance, accredited lab
12	After handoff	Support path, open documentation, third-party code list

A total out of 24 is useful, but look at the zeros first. A firm that scores 20 with a 0 on question 7 or 8 is a bigger risk than one that scores 17 with no zeros. Ownership and file formats decide whether you can ever move your project to someone else.

Some signals show up before you even get to question 1. None of them proves a firm is bad. Each one is worth a direct follow-up, though.

• A firm ship date in the first 30-minute call. Nobody can promise you a ship date for a product they haven't scoped. A range with its assumptions written next to it is honest.
• No questions back to you. A good engineer asks about your users, your volumes, your power source and which markets you'll sell in before talking about solutions.
• Everything is a strength. Simplexity suggests asking which service is the firm's strongest. A firm that says all of them hasn't answered.
• No references. Client work is often under NDA, but a firm should be able to share some past work or a reference who agreed to talk.
• Pressure to sign quickly. A real offer is still on the table after your lawyer has read the ownership clause.

We'd want every founder to ask us these 12 questions. Here's how we answer them.

• Questions 3 and 7, NDA and ownership. We sign a mutual NDA before any technical discussion. You own the designs, source code and files we deliver: schematics, PCB layouts, firmware, documentation and the production files.
• Questions 4 to 6, process. Every project runs through 6 steps: Discovery, Architecture, Design, Review, Prototype and Handoff. Requirements and a risk list come first. You'll get written updates and a review checkpoint at each milestone.
• Questions 2 and 10, who reviews. Our lead engineer is IPC CID+ certified. That's the advanced level of the IPC designer certification. Designs go through DFM and DFT checks and a design review with your team before files go to fabrication.
• Questions 8 and 9, files. You get native project files in Altium Designer or KiCad, with the BOM, production files, source code and documentation in one handoff package.
• Question 11, certification. We design for certification from day 1 and support the manufacturing steps. An accredited lab does the formal compliance testing, and we'll say so up front.
• Scope. You can take any step on its own. Some teams only want a design review before their next build. Others want firmware for a board they've already got.

Electuni LLC is a US company founded in 2016. We've delivered 500+ PCB designs since then. The full process with the deliverables at each step is on How we work. If you're a US team looking for extra hardware capacity, see hardware product development for US teams. You can also browse our services, including hardware design, firmware development and PCB design for startups.