How to Evaluate an Embedded Systems Design Partner?

The criteria that predict success in embedded design partnerships have little in common with software vendor evaluation. What to ask, what to test, and what to watch for before signing.

---

If you’ve outsourced software development before, you’ll be tempted to evaluate embedded design partners the same way. Check portfolios, call references, compare rates, negotiate the contract. The process feels familiar because the surface looks similar: a technical team building something to your specifications.

The failure modes are different. A software vendor who misunderstands requirements delivers code you refactor. An embedded design partner who misunderstands your hardware constraints delivers a board that doesn’t work. The software fix takes days. The hardware fix takes months and costs orders of magnitude more. That difference should change how you evaluate.

Why software vendor criteria miss what matters in embedded

Software outsourcing has a forgiving iteration cycle. Deploy to a server, run tests, see results, push a fix. The feedback loop runs in minutes or hours. Embedded development works on a different clock. Firmware gets flashed to physical hardware through JTAG or SWD debuggers. Each build-flash-test cycle takes longer, and when you’re dealing with high-speed transceivers or mixed-signal interfaces, simulation alone won’t tell you if the design works. Testing requires actual boards, oscilloscopes, spectrum analyzers, and thermal chambers, not emulated environments.

This matters for evaluation because the things that go wrong in embedded outsourcing are structurally different. Embedded outsourcing delays frequently trace back to incorrect RTOS task priorities, misconfigured DMA channels, or hardware abstraction layer issues that the vendor introduced through unfamiliarity with the specific silicon platform. These aren’t bugs a code review catches. They’re architectural mismatches between what the vendor assumed about the hardware and what the hardware actually does. Hardware integration surprises are the industry norm when vendor evaluation doesn’t account for these failure modes.

The evaluation criteria need to target the actual risk surface: technical depth across disciplines, design methodology rigor, and IP protection infrastructure. The first of those risk surfaces, and the one most vendor scorecards miss entirely, is cross-discipline technical depth.

Technical depth across disciplines

The first question isn’t “can they do FPGA design?” or “do they have embedded software engineers?” The first question is “can they show projects where multiple disciplines shipped together on the same board?”

Most embedded projects touch at least three disciplines. An FPGA-based data acquisition system involves FPGA logic design (custom data paths, DDR memory controllers), embedded firmware for the host processor (BSP, drivers, application layer), PCB layout with controlled impedance routing for multi-gigabit interfaces, and SI/PI analysis for the SerDes links and power delivery network. If your design partner subcontracts half of those disciplines, you’re managing cross-vendor interfaces through a proxy, and the proxy has limited visibility into what happens at the boundaries.

Evaluation questions that actually predict technical capability:

Discipline	What to ask	Red flag
FPGA	“Walk me through a clock domain crossing review on a recent project.”	Vague answer about simulation tools without methodology detail
Embedded software	“How do you handle RTOS configuration for a new hardware platform?”	“We use the default configuration and tune later”
Hardware/PCB	“What’s your DFM review process before sending to fabrication?”	No formal review gate, reliance on manufacturer’s DRC
Signal integrity	“At what point in the design do you run SI/PI analysis?”	“After layout” (should be before and during)
Cross-discipline	“Show me a project where an FPGA decision changed the PCB layout.”	Can’t provide an example

The cross-discipline question is the most revealing. A design partner that truly operates across disciplines will have stories about moving FPGA transceiver pin assignments to shorten PCB trace lengths, or rearchitecting FPGA-software integration to simplify the power delivery network. A partner that operates as siloed teams under one brand won’t.

Avoiding PCB respins requires catching cross-discipline issues before fabrication. Respins on advanced boards can cost millions when mask charges, extended lead times, and downstream schedule impacts are included. Ask the partner what percentage of their projects achieve first-pass success, and how they define it.

Design methodology and first-pass success

First-pass success means the design works correctly the first time it’s built in silicon or assembled on a board, without requiring respins or rework. In embedded systems, where each iteration cycle adds weeks or months, first-pass yield is the single metric that most directly correlates with project timeline and total cost.

The industry reality is that most embedded projects don’t achieve first-pass success. The ones that do share common methodological practices: rigorous simulation before hardware implementation, formal design review gates at each stage, documented constraint checking, and experienced designers who recognize failure modes from previous projects.

What to evaluate in a partner’s methodology:

• Simulation before build. Does the partner simulate critical signal paths, power delivery networks, and timing before committing to fabrication? A partner who builds first and simulates later is transferring risk to your schedule.
• Design review gates. How many formal review points exist between concept and fabrication? What happens when a review identifies an issue? In a disciplined methodology, a failed review blocks progress. In a less rigorous one, issues get logged as “known items” and carried forward.
• Clock domain crossing analysis. For FPGA-heavy designs, CDC errors are one of the most common sources of intermittent failures that only surface under specific operating conditions. Ask specifically how the partner identifies metastability risks and validates synchronizer chains.
• Design for testability. How does the partner build in test points, debug access, and diagnostic capabilities? A design that works but can’t be debugged in the field is a liability. Test points that seemed optional during design become essential when a board in the field behaves differently than it did in the lab, and the only way to diagnose the issue is to probe a signal that wasn’t brought to an accessible location.
• Constraint management across disciplines. Does the partner maintain a shared constraint database that hardware, FPGA, and firmware teams all reference? Cross-discipline constraints need to be visible to every engineer on the project. Partners who manage these in discipline-specific silos discover conflicts at integration rather than at design time.

Once you’re confident in a partner’s technical depth and methodology, the next question is how the engagement itself is structured and what you own when it’s done.

Engagement models and IP protection

How you engage a design partner shapes how your project runs, what you own when it’s done, and how much control you retain during development. Four models cover most embedded design engagements:

Model	How it works	Best for	Risk profile
Project-based	Fixed scope, defined deliverables, milestone payments	Well-specified projects with clear requirements	Scope creep if requirements change
Team augmentation	Partner engineers embedded in your team, your management	Capacity gaps with strong internal architecture	Knowledge walks out when engagement ends
Long-term partnership	Multi-year retainer, dedicated team, shared roadmap	Ongoing product development programs	Vendor dependency
Hybrid	Core architecture in-house, implementation outsourced to partner	Teams with senior architects but not enough hands	Requires strong interface specifications

IP protection goes beyond NDAs. For embedded design, the deliverables include RTL source (Verilog/VHDL), constraint files (XDC/SDC), firmware, Altium/OrCAD PCB design files, S-parameter simulation models, and test procedures. Evaluate specifically:

Who owns what. The contract should explicitly state that all design files, source code, and documentation are work-for-hire and belong to you. “Joint ownership” sounds collaborative but creates licensing ambiguity.

Security infrastructure. SOC 2 Type 2 certification, encrypted file transfer, access controls on design repositories. For defense and ITAR-controlled work, the partner needs cleared facilities and personnel.

North American delivery. For companies with IP sensitivity concerns, working with design centers in the same legal jurisdiction eliminates cross-border IP enforcement complexity. All engineering staff in your timezone means real-time collaboration without overnight handoffs that create documentation gaps. For defense work or products with ITAR-controlled technology, North American delivery isn’t a preference. It’s a requirement.

Regulatory experience compounds this. Outsourced medical device firmware frequently requires rework after regulatory audit due to missing design controls, traceability gaps, or configuration management deficiencies. If your product requires FDA clearance, ISO 26262 compliance, or DO-254 certification, your design partner’s regulatory track record isn’t a nice-to-have. It’s a filter that eliminates most candidates.

The evaluation framework

These eight questions, asked in your first substantive meeting with a potential partner, will surface more useful signal than any RFP process:

1. “Show me a project where disciplines interacted to change the design.” Tests cross-functional integration. Weak partners give abstract answers.
2. “What’s your first-pass success rate, and how do you define it?” Tests methodology rigor. Firms that track this metric have earned it.
3. “Walk me through your design review process from concept to fabrication.” Tests whether methodology is institutionalized. You want to hear about gates, checklists, and sign-offs.
4. “How do you handle a design change request after PCB layout is started?” Tests process discipline under pressure. The answer reveals whether changes are managed or absorbed.
5. “Who would be on my project team, and what have they shipped?” Tests whether you get the A-team or the bench. Ask for specific names and project references.
6. “What do you own at the end of the engagement?” Tests IP clarity. The right answer is “everything,” and pushback here is a negotiation red flag.
7. “Can you show me your SOC 2 report?” Tests security infrastructure. Partners who can produce this immediately have invested in the systems. Partners who hesitate haven’t.
8. “What’s your longest client relationship?” High repeat rates signal delivery quality. Firms with a 95% customer repeat rate across 400+ clients have earned that retention through consistent delivery.

Weight these questions based on your project. Regulatory work elevates questions 3 and 7. Complex multi-discipline integration elevates questions 1 and 2. Tight timelines elevate questions 4 and 5.