Choosing a development partner is mostly an interview problem. The proposals will all look competent, the portfolios will all look polished, and the price differences won’t tell you much on their own. What separates the firms is how they answer direct questions about the unglamorous parts of the work.
We’ve sat on both sides of this conversation, and the pattern is consistent. The questions that predict how an engagement will go aren’t about technology choices or team size. They’re about ownership, sourcing, handover, and what happens when something changes, because those are where a weak partner’s answer gets vague and a strong one’s gets more specific.
This guide gives you the questions, grouped by what they’re actually testing, with what a good answer sounds like and what a weak one reveals. It applies whether you’re commissioning hardware, software, or both. For the wider selection process rather than the interview itself, our guide to choosing a software development partner covers the full roadmap.
Questions About Ownership
Start here, because the answer shapes everything else and because it’s the question a partner with a lock-in business model least wants to answer plainly.
- “What exactly do I own at the end, and in what format?” A strong answer names artifacts and formats without hesitation: editable schematics and PCB layout, mechanical CAD, firmware source with build instructions, infrastructure definitions. A weak answer talks about “full documentation” or “all deliverables” without saying what those are. The tell is the difference between owning a design and owning a PDF of one.
- “When does ownership transfer?” The answer you want is on payment, or progressively as work is delivered. If ownership transfers only at project completion, every dispute in the program is negotiated with your own design as the hostage.
- “Where does the code live during development?” Our own answer is that work is committed to the client repository, under the client organization, in cloud accounts held in the client name, from the first commit. That means on day two you can go and look. A partner who develops in their own repository and delivers a zip file at the end is asking you to take the whole engagement on trust.
- “Is any part of this built on tooling I can’t access?” Proprietary frameworks, in-house libraries, and internal build systems are all legitimate engineering choices and all potential dependencies on the firm that wrote them. Ask what happens to those at handover. We go through this in more depth in how to avoid vendor lock-in.
Questions About Sourcing and Second Sources
For anything with a bill of materials, sourcing is where a design either survives contact with the supply chain or doesn’t.
- “How are components selected?” You’re listening for availability, lifecycle status, and lead time alongside electrical performance. A partner who selects purely on the datasheet will hand you a design that’s correct and unbuildable.
- “Which parts are single sourced, and what’s the alternative?” A good answer is a list, with named alternatives and a note on what the layout would have to accommodate to accept each. That work reduces a supply interruption from a redesign to a substitution. A weak answer is that they’ll deal with it if it happens, which means dealing with it becomes your problem at the worst possible moment.
- “Was the bill of materials checked against live stock, or against a catalog?” These are different activities. Catalog availability tells you a part exists. Live distributor inventory and lifecycle status tell you whether you can buy several thousand of them in eight months.
- “What happens if a part goes end-of-life after handover?” There’s no perfect answer, and a firm claiming one is overselling. What you want is evidence they’ve thought about it: flagged alternatives, documented rationale, and a design not wrapped so tightly around one component that substitution means starting over.
Questions About Firmware and Who Writes It
Firmware is where hardware programs most often split into two suppliers, and the seam between them is where the schedule goes.
- “Who writes the firmware, and are they the same team doing the board?” If the answer is a different company, ask how the interface between them is managed and who owns a problem that could be either. Handoff risk is real, and it concentrates precisely at that boundary. We hold electrical, embedded, and mechanical in-house under one team for this reason, with no partner network and no offshore bench.
- “What’s the firmware architecture, and why?” Bare metal, a real-time operating system, and embedded Linux are all correct answers to different problems. The reasoning is what matters. A partner who always reaches for the same one regardless of the product is telling you about their comfort zone rather than your requirements.
- “How does the device get updated in the field?” Secure field update, bootloader, and rollback should already be in the answer rather than appearing as a change request in month five. A device you can’t update is a device whose first firmware bug becomes a recall conversation.
- “What does bring-up look like, and what gets written down?” Bring-up produces surprises. A firm that records them is one you can hand the program away from. A firm that doesn’t is building institutional knowledge you can’t buy.
Questions About Handover
This is the question most buyers ask last and should ask first, because the answer tells you what the whole engagement was really structured to produce.
- “What does handover actually consist of?” The answer you want describes an event, not a delivery. Ours is a supervised session in which the client team performs a deployment or brings up a board unassisted, and independent operation is the completion criterion. A partner who describes handover as sending files has defined success as their own convenience.
- “What documentation comes with it?” For hardware: fabrication and assembly pack, functional test procedure, bill of materials with second sources, design rationale. For software: architecture documentation, runbooks for deployment and rollback, and API documentation generated from the source rather than written alongside it and left to drift.
- “Could another firm pick this up?” A confident yes, with reasons, is the answer of a firm that intends to earn the next engagement rather than inherit it. Hesitation here is the most useful signal in the entire interview. We’ve audited enough inherited systems to know how the other version ends, and our inherited platform audit case study is what that looks like from the receiving end.
- “What happens if I want to stop after this phase?” Every honest answer involves a bit of friction. What you’re checking for is whether stopping is contemplated at all, or whether the commercial structure assumes you can’t.
Questions About How Change Gets Priced
Every program changes. The question isn’t whether, it’s what the mechanism is.
- “How is the work priced, and why that model?” Fixed fee suits work with a defined edge: a review, an audit, a site. Milestone-based pricing suits product development, where each stage concludes in a decision point. Monthly pricing suits retainers and team extension. What you want is a partner who can explain why they chose the model for your work rather than one who uses the same model for everything.
- “What happens when scope moves?” The commitment worth hearing is written notification in the week an issue arises, with options and the cost of each, rather than disclosure at a milestone review when it’s too late to choose. A change that surfaces at the end was usually known at the middle.
- “Who absorbs a delay you caused?” Ask it directly. A partner willing to say plainly that delays originating with them are absorbed, and that moved requirements are re-quoted rather than recovered quietly from the finishing work, is describing a mechanism you can hold them to.
- “What’s not in this quote?” The most productive question on the list. Low bids are rarely dishonest, they’re just narrow. Test fixtures, panelization, documentation, compliance support, and the handover session are the usual omissions, and they’re the parts that make a delivery date predictable. We advise being wary of a quote that’s cheaper without being smaller.
Questions About References and Track Record
- “Can I speak to a client whose program went sideways?” Every firm can produce a delighted reference. The valuable call is with someone who hit a problem, because you’re buying the response as much as the work.
- “What was your specific role on the case studies you’ve shown me?” In our experience this is the question that separates a portfolio from a contribution. Ask which parts they designed, which they inherited, and which belonged to another supplier.
- “Have you worked in my regulatory or industry context?” Relevant experience genuinely reduces a learning curve, particularly where compliance is involved. Directly comparable experience isn’t essential, but the difference should be acknowledged rather than glossed.
- Check the independent listings. Platforms like Clutch.co and GoodFirms carry reviews and project detail that a firm doesn’t control. They’re not the whole picture, but a firm with no third-party footprint at all is worth a follow-up question.
What the Answers Are Really Telling You
Run this interview with two or three firms and the differences stop being subtle. Strong partners get more specific as the questions get harder, because they’ve had to answer them before and the answers are already structural. Weak ones get more general, because the specifics don’t exist yet and won’t until your program forces them into existence at your expense.
Watch, too, for a firm that asks you harder questions than you asked them. A partner probing your business goals, your failure costs, and your production volumes before quoting is planning to scope the work rather than sell you a shape they already have. We give every inquiry an assessment of whether the work suits the capability we hold in-house, and where an internal team or a different kind of firm would serve the program better, we say so before issuing a proposal.
Our hardware design practice page sets out our own answers to most of the questions above, and our process describes how an engagement runs from first call to independent operation. Read them as a worked example, then hold every firm you’re considering to the same standard.