Bring in an embedded systems partner when firmware is the bottleneck between your hardware and your business: when the demo works but production doesn't. When hiring can't keep pace with the roadmap, or when the problem has moved past what a strong generalist team should be expected to solve.

For context: we're LeafLabs, an embedded systems engineering firm founded in 2009 out of MIT. We've shipped upwards of 400 projects, from Google's Project Ara to MIT neuroscience instrumentation to complex warehouse robotics. We've also told plenty of prospects not to hire us. This post is the sorting logic we use on those calls.

1. The demo works. Production doesn't.

The prototype performs beautifully in a controlled environment. Sales has the video to prove it. Then units meet real customers, real environments, and real duty cycles, and the defect reports start arriving.

This is the demo-to-production gap, and it's where hardware companies most consistently underestimate the engineering effort that remains. Reliability is an architectural property: fault handling, state recovery, observability, and the discipline to find root causes, instead of shipping workarounds.

You're in this category if:

• Field units have intermittent faults nobody can reproduce on the bench

• Watchdog resets and power cycles are your de facto recovery strategy

• Every firmware fix seems to ship with a new regression

• You can't state your MTBF because nobody is measuring it

Quick test: Pick your three most common field failures. If no one can reproduce them in-house by Friday, you don't have a bug problem — you have an observability problem, and more debugging hours won't fix it.

2. Hiring can't keep up with the roadmap.

Senior embedded engineers routinely take six to nine months to hire, and the market is thin. Meanwhile, your hardware milestones don't move, and firmware sits on the critical path.

There's also a version of this where you shouldn't hire yet: the work ahead is a nine-month spike — board bring-up, an architecture rebuild, a certification push — not a permanent seat. Hiring a full-time specialist for a temporary peak leaves you paying for that post-deployment.

You're in this category if:

• An embedded req has been open 90+ days while firmware blocks the schedule

• Your EE or mechanical engineer is writing firmware because someone has to

• One engineer holds all the firmware context — a bus factor of one

• The work ahead is a defined push, not a steady-state load

Quick test: If your firmware lead resigned tomorrow, how long until someone else could cut a release? If the answer involves nervous laughter, the risk is already on your books; a partner can first make it visible, and then make it smaller.

A caveat we give prospects directly: a partner is not a substitute for eventually hiring. The good ones leave behind documented architecture and clean interfaces that make your future hires productive faster, not dependent on us longer.

3. Your software team is strong — one layer up.

Many excellent product teams are solid at the top of the stack: cloud, applications, ML. Below the RTOS, things get thinner. But hardware milestones die at the bottom of the stack, and "probably firmware" becomes the place bugs go to stall.

The subtle version of this problem: your architecture is whatever the vendor SDK example did. It worked for the prototype. It will not survive contact with your actual requirements.

You're in this category if:

• Bugs triaged as "probably firmware" sit unresolved for weeks

• Driver, BSP, and RTOS work lives permanently in the backlog

• Board bring-up delays every hardware revision

• Power budget, boot time, or latency targets have no clear owner

• Nobody on the team is fluent with both a schematic and a logic analyzer

Quick test: Ask who owns the layer between the silicon and your application code. If the answer is a vendor, an intern, or a shrug, you've found the gap.

4. You're going from one to many.

Ten units hand-tended by the engineers who built them is a different product than a thousand units in the field. Scaling firmware means manufacturing test, provisioning, fleet updates, and remote diagnostics — a second product that usually nobody scoped or budgeted.

This is the stage where companies discover that "we'll add OTA updates later" was a load-bearing assumption.

You're in this category if:

• Firmware updates require a person, a cable, and an afternoon

• There's no manufacturing test firmware; the line's test plan is "does it boot"

• Field units are running unknown or mixed firmware versions

• Diagnosing a field failure means shipping the unit back

• Your contract manufacturer keeps asking design-for-manufacturing questions nobody owns

Quick test: Can you answer "what firmware version is unit #214 running, and when was it last healthy?" without physically walking to unit #214? If not, every field issue costs you a truck roll or an RMA.

5. The problem is specialist-hard.

Some problems don't yield to headcount. Control loops with real bandwidth requirements. Sensor pipelines pushing data rates your microcontroller can't move. Timing budgets that don't close. FPGA work when nobody on staff has shipped an FPGA. In robotics, this is the whole perception-to-actuation chain: getting from sensor data to correct physical motion, fast enough, every time.

Strong generalist engineers shouldn't be expected to have this scar tissue. It comes from having shipped these exact systems before — which is precisely what you're buying from a specialist partner.

You're in this category if:

• Control tuning is trial-and-error

• Your sensor-to-actuation latency budget doesn't close on paper, let alone on hardware

• You're considering an FPGA and no one on the team has taken one to production

• The DSP works in simulation, but fixed-point behavior on the device is another story

• Mixed-signal gremlins: everything works until the motors turn on

Quick test: Can someone on your team state your end-to-end sensor-to-actuation latency and its jitter — measured, not estimated? If that number doesn't exist, neither does your control story.

6. The firmware has to stand up to scrutiny.

Medical devices, scientific instrumentation, industrial safety systems: someone is going to audit this work. A regulator, a customer's QA team, or your own counsel after an incident. At that point, "the engineer tried it and it worked" is not a verification strategy, and git log is not a design history file.

There's a newer version of this question, too. As AI-generated code spreads through the industry, auditors and customers have started asking about provenance: where did this code come from, and who is accountable for it?

You're in this category if:

• Your regulatory pathway (FDA, IEC 62304, IEC 61508) requires traceability you don't have

• Verification is ad hoc rather than tightly tied to requirements

• A customer asked how your firmware is validated and the answer took a meeting to assemble

• You need to state the provenance of your code — and can't

Quick test: Could you hand an auditor a requirements-to-test traceability story for your safety-relevant functions this week?

When you should NOT bring in a partner

Three situations where we tell prospects no, and mean it:

You have a strong embedded team that just needs headcount. If your in-house team is good and the work is well-understood, recruit. Adding a partner to a machine that already works mostly adds coordination overhead.

The budget math doesn't work yet. A good consultancy costs less than a bad year of hiring, but it doesn't cost less than not spending. If funding a real engagement would starve the rest of the company, scope the problem down or wait. A partner that takes that engagement anyway is optimizing for their revenue, not your outcome.

You want a fixed-bid guarantee on novel work. If nobody has solved your control problem before, anyone quoting a firm fixed price is pricing in either failure or padding. The honest structure is phased: a scoped discovery effort that retires the biggest technical risks, then commitments you can actually hold someone to. Distrust certainty that arrives before understanding does.

Once you've decided: seven questions to ask any partner

Deciding you need help is half the problem. The other half is not hiring the wrong team. These are the questions we'd ask if we were on your side of the table — including of us.

Who actually writes the code? Some firms sell you their senior engineers and deliver subcontractors. If the people in the pitch meeting and the people doing the work are different, ask why. (Our answer: everything is done in-house, by the team you meet.)

How do you price work nobody has done before? Listen for phased structure; discovery that retires risk before larger commitments. Suspicious certainty on novel problems is a red flag.

Who owns the IP? For anything core to your product, the answer should be "you". But do ask yourself which IP actually matters: sometimes a partner's hardened, field-proven building blocks get you to market faster and more reliably. It can be a good trade for components that aren't on your proprietary path.

What do you leave behind at handoff? Documented architecture, design records, tests, and a codebase your future hires can pick up. If the answer is vague, budget for paying again to reopen the black box.

Can we talk directly to the engineers? Layers of account managers between you and the people writing your firmware turn every technical decision into a game of telephone.

Do you use AI to write production code? We use AI wherever it makes expert engineers more effective and efficient, and a human owns every line that ships.

What work do you turn down? A firm with no answer has no focus. Our no-list includes weapons and surveillance technology.

Whichever category brought you here, the shape of a good engagement is the same underneath: direct access to the people doing the work, capacity you can plan around, and code that outlives the contract.

The half-hour version

If one or more of these sections resonates with you, a technical call costs thirty minutes. Meet our engineers to talk through your specific problem and whether we're the right shape for it. And if the honest answer is one of the three above, we'll tell you that too.