Pipeline playbook

How to build new logo pipeline for contract firmware and embedded engineering

Not software development in general. The firmware bench that hardware companies cannot hire: drivers, bootloaders, bring up, power management, connectivity stacks, test harnesses and the certification support nobody budgeted for. Your buyer is a hardware company that is behind schedule and has a requisition open that nobody is answering.

Who actually signs

At a company of any size, the vice president or director of engineering signs. They own the ship date and they are the person who will have to explain, in a board meeting or an all hands, why an outside firm is doing work their team was hired to do.

At a funded hardware startup, the chief technology officer or a technical founder signs, and they evaluate you in a single conversation. There is no procurement process and no evaluation committee. There is one person deciding whether your engineers are real, usually within twenty minutes of technical conversation, and they are also privately worried about losing control of their own codebase.

The systems architect or hardware lead is the technical gate. They will ask you about a specific peripheral, a specific silicon errata or a debugging story, and the answer decides everything that follows.

And there is the internal firmware engineer, who is either drowning and grateful or territorial and quietly obstructive, depending entirely on whether your arrival removes work they hate or work they enjoy.

The one sentence version

Your buyer has a requisition that has been open for four months, a ship date that has not moved, and a growing private certainty that those two facts cannot both survive.

How they think about it now, and where you need them

The distinctive thing about this sale is that your competitor is not another firm. It is a job posting, and the belief that hiring is the responsible answer.

What they believe today.

  • We are hiring for this. The requisition is approved, we have a recruiter on it, and bringing in a firm would be admitting that plan is not working.
  • Contractors are expensive. A senior firmware engineer costs a certain salary and an outside team costs multiples of that per month.
  • The last time we did this, the code arrived, the contractor left, and nobody here could maintain it. We are still living with that.
  • Our firmware is our product. Handing it to outsiders means handing over the thing that makes the device ours.
  • Offshore is a third of the price and other companies seem to manage.

What has to be true before they can buy.

  • The requisition is not free while it is open. The cost of a hire is the salary plus every month the role stays unfilled, and in this discipline that is commonly four to six months during which the programme slips anyway. Run that arithmetic in front of them and the comparison stops being contractor against salary and becomes contractor against a slip that has already started.
  • You take the plumbing, they keep the product. This is the sentence that makes the decision politically safe. The outside team takes drivers, bootloader, bring up, test harness and certification support, and the internal team stays on the part that differentiates the device. A vice president can say that upward without it sounding like a failure, and no other framing of this purchase is as easy to repeat.
  • The deliverable is a maintainable handover, not a working binary. Everyone in this market has been burned by code they could not maintain, so the product is documentation, test coverage, a reproducible build and a defined handover period. Leading with that answers the objection before it is raised and separates you from the last three firms they spoke to.
  • A hire cannot be unhired when the programme ends. Firmware demand is spiky by nature, peaking through bring up and certification and falling afterwards, and a permanent hire made at the peak is a fixed cost carried through the trough. That is an argument for a contract team that a hardware executive feels immediately.
  • Distance is a schedule risk, not a quality risk. Bring up is interactive debugging with a physical board on a bench, and every hour of time zone gap multiplies during the exact weeks when there is no slack left.

The reframe compresses into one line worth putting in an email: you are not competing with their engineers, you are competing with a requisition that is not going to be filled in time, and you take the unglamorous half so their team keeps the interesting half.

The triggers, and where each one is visible

  • Firmware and embedded job posts, tracked by age. This is the single best trigger in the niche because it measures both need and failure to meet it. A post that is sixty days old is a conversation. One that is a hundred and twenty days old is an emergency nobody has admitted yet. Log the first seen date and let the clock do the qualification.
  • Equipment authorisation and certification filings. Public, dated, and they name the applicant, the product and the test laboratory. A filing means bring up is done and the next programme is beginning. A confidentiality request attached to one tells you a launch date is being protected.
  • Hardware funding rounds. New money produces a hiring plan and a hardware schedule, and firmware is the discipline every hardware plan underestimates. The first six months after a round is the most reachable this buyer ever gets.
  • Announced launch dates and slipped ones. A public ship date is a commitment with a countdown, and a publicly acknowledged delay is a company that has already had the difficult internal conversation.
  • Departures. A firmware lead leaving a small hardware company is a capability hole that no requisition closes quickly, and role changes are visible.
  • Silicon end of life and part obsolescence notices. A microcontroller going end of life forces a port that nobody planned, on a schedule set by the semiconductor company rather than by the customer.
  • New device security and update obligations with dated compliance deadlines. These force firmware work on products already shipped, which is work with no product manager pushing for it and no team assigned.

Aged job posts and certification filings are the two to build on. One tells you they cannot hire, the other tells you where they are in the programme cycle.

Qualify in sixty seconds

  • Is there a date? A ship commitment, a certification submission, a trade show demonstration. Firmware engagements without a date get discussed for months and funded never.
  • Where is the hardware? Boards in hand means you can start next week. Still in layout means the first phase is development kit work, and you should scope it that way rather than absorb the delay.
  • How many firmware engineers do they have? Zero means you are the whole capability and the handover conversation is the sale. Two or three means you are augmenting, which is easier to sell and easier to deliver.
  • Is there version control discipline and a reproducible build? If not, add a phase and price it, because you will otherwise spend three weeks of unbilled time building the foundation before you can write a line.
  • Who owns the intellectual property, and is there an existing agreement template? At a startup this is a twenty minute conversation. At a large device maker it is six weeks of legal, and knowing which one you are in changes your forecast.

The angle that gets replies

Lead with the requisition. It is public, it is specific, it is theirs, and its age is a fact about their programme that nobody has ever said back to them.

Then take the political weight off the decision in the same paragraph, by describing the split where they keep the interesting work.

Three openers you can adapt

  • On an aged requisition"Your embedded firmware role has been open since the spring. That is normal for this discipline and it is also four months of programme time. The usual way out is not replacing the hire, it is splitting the work: an outside team takes the drivers, the bootloader and the test harness while your own people stay on the part that makes the product yours. Happy to sketch that split against your job description, which is the only thing I have to go on."
  • On a certification filing"Saw the certification filing on the new product, which means bring up is behind you and the next one is already being scoped. The pattern we see is that firmware headcount gets planned from the last programme rather than the next, and the next one usually has a connectivity stack or a security requirement the last one did not. Two paragraphs on how teams staff that gap, no meeting needed."
  • On a silicon end of life notice"The part in your current design has an end of life notice attached to it, which means a port that nobody put in this year's plan and a schedule set by the semiconductor company rather than by you. The awkward part is usually not the port, it is revalidating the peripherals afterwards. Here is how we have sequenced that twice, including the one where we got the order wrong."

Admitting a mistake in the third one is deliberate. This audience trusts engineers who describe what went wrong and distrusts firms whose every reference project went perfectly.

What not to send

  • We have expert embedded engineers. Every firm in the category opens with that sentence, including the ones with three contractors and a website.
  • A rate card in the first email. It invites an immediate comparison with offshore pricing, which is a conversation you lose on the axis they are looking at rather than the one that matters.
  • A capabilities list naming every microcontroller family you have touched. It reads as a resume rather than as help, and the architect will assume breadth means shallow.
  • Any suggestion that their team is failing. The vice president already suspects it, will never say it, and cannot buy from the person who said it for them.
  • A fixed price for a build phase against hardware you have not seen. The buyer will love it, you will regret it, and the relationship ends at the second board revision.

The objection you will hit

We are hiring for that role. The defining objection, and the answer is arithmetic rather than argument. How long has the requisition been open, what is the typical time to fill in this discipline, and what happens to the ship date across that period. You are not telling them to abandon the hire. You are pointing out that the hire and the deadline are two different problems and only one of them is solvable this quarter.

The last contractor left us with code we could not maintain. Do not defend the category. Ask what specifically was missing, and the answer is almost always the same three things: no documentation, no tests, and a build that only worked on one person's machine. Then describe your handover as a deliverable with a definition, including a period where their engineer owns the code while you are still available. This objection is your best opening in disguise, because the firm before you set the bar on the floor.

Our firmware is our intellectual property. Agree completely and get specific fast: work for hire assignment, what you retain, how you segregate customer code, and how you audit open source licences in anything shipped. Precision here is reassuring in a way that reassurance is not.

We can get this done offshore for a third. Never criticise the alternative, because someone senior may have chosen it already. Move to where the hours actually go during bring up, which is interactive debugging with a board on a bench, and describe what a twelve hour turnaround does to a two hour problem during the weeks when the schedule has no slack. Then offer the hybrid honestly if that is what fits.

Deal shape

  • Discovery and architecture phase: fixed price, two to four weeks, commonly $15K to $40K. This is the paid qualification and it should produce a document useful to them even if they stop there.
  • Dedicated team: two to four engineers on a monthly commitment, commonly $30K to $80K a month depending on seniority and mix, which is the structure that survives hardware revisions.
  • Time and materials for defined work packages: commonly $125 to $225 an hour blended in the United States, and the right structure for certification support and bug work rather than for a build.
  • Post launch maintenance retainer: small, unglamorous, and the thing that turns a project business into a company with predictable revenue.
  • Signer: vice president of engineering, or the founder at a startup. Cycle: two to eight weeks, which is fast, because the purchase is triggered by a slip rather than by a plan. Expansion happens on the next programme, not by growing this one.

The short cycle has a consequence people miss. You cannot create the trigger, you can only be present when it fires, which makes coverage and timing matter more than persuasion. A nurture list that you touch every quarter is worth more in this niche than a clever sequence.

A cadence you can actually run

  • Weekly, pull embedded and firmware job posts and record the date you first saw each one. The age of the post is your qualification score, and it is the one piece of data your competitors are not tracking.
  • Monthly, pull certification and equipment authorisation filings in your product categories, and note both the applicant and the test laboratory, because laboratories refer work.
  • Weekly, watch hardware funding announcements and treat the following six months as the reachable window.
  • Quarterly, scan silicon end of life notices and dated device security obligations against the parts and product classes your customers use.
  • Continuously, watch firmware role changes at target companies. A departure creates the same hole as a failed requisition, faster.
  • Fifteen to twenty accounts a week, plus a standing nurture list touched quarterly. In this niche the nurture list produces more revenue than the new outreach does, because the trigger is unpredictable and the buying window is short.

Nobody in this market is choosing between two firms. They are choosing between an outside team and a requisition that has been open since spring, and only one of those two options can hit the date.

The sending mechanics most people get wrong

Everything above is about who and what. This is about how, and it is where most outbound in this niche quietly dies. Seven rules. None of them are optional.

1.Three to five sentences. That is the whole email.

Your reader is on a phone between meetings. One observable fact about their company, one consequence they have not thought about, one specific thing you would do. Anything past five sentences is a memo, and memos get archived unread.

2.Lead with a technical differentiator that turns into a number.

The messages that work best name something concrete you do differently and translate it into time or money saved. In this niche the differentiator is evidence of having shipped rather than a list of technologies. Name the classes of device you have taken through bring up and certification, the peripherals and stacks you have debugged at the register level, and one specific hard problem you solved with the mechanism described. Then convert it into schedule: weeks from board arrival to first boot, and what your handover contains. A firm that quantifies handover is doing something almost nobody else in this category does.

Most services firms do not have a technical differentiator, and pretending to have one reads as exactly that. The substitute is a verticalized case study: a company like theirs, what you did, what happened, in one sentence. For this niche the line is: a comparable device, what state the programme was in when you arrived, what your team took and what the internal team kept, the date they hit, and what the handover looked like six months later. That last clause is the whole proof, because every buyer has been abandoned by a contractor before. Ask for permission when the product ships, and ask the engineer rather than the marketing team.

3.Ten to twenty emails a day per mailbox. Not a hundred.

Sender reputation is scored per mailbox and per sending domain. One inbox pushing a hundred cold emails a day looks like exactly what it is, and the penalty lands on the domain, which means it lands on your client correspondence too.

If the math says you need more volume, the answer is more mailboxes on more warmed sending domains, separate from the domain you invoice from. It is never more volume per mailbox. Eighteen accounts a week at three touches is around eleven emails a day from one mailbox, with a quarterly nurture pass on everyone you have already written to. Budget for the nurture volume when you size mailboxes, because in this niche it grows every quarter and it is where the revenue comes from.

4.Write ten versions of every step and test them.

Versions A through J, not A and B. Rotate subject lines and bodies. You learn which angle is actually working instead of guessing, and there is a second reason that matters more: identical bodies going out over and over is one of the patterns postmaster tools flag. Variation is a deliverability tool as much as a testing one.

Subject line seeds for this niche, each of which should become several variants: "the firmware role open since spring", "after the certification filing", "the end of life notice on your part". Lower case, no punctuation tricks, and nothing that would look odd in a reply from a colleague.

5.Stop at three.

Most replies arrive on the first and second email. The third is already thin. Every touch past that raises the odds the whole thread gets classified as spam, and that classification follows the mailbox to the next person you write to. The long cadence is over. Three touches, each with something new in it, then leave them alone for ninety days.

6.Know what good looks like.

A one percent reply rate with a quarter of those replies positive is a healthy trigger based program. Anyone quoting you double digit reply rates is counting out of office messages or selling a course.

7.LinkedIn Sales Navigator is not optional.

Every other data source tells you who held a title at some point. Sales Navigator tells you who holds it today, because the person maintains it themselves. That is the difference between a three percent bounce rate and a fifteen percent one, and bounces are scored against the mailbox the same way spam complaints are. Verify the name there before anything goes out.

It is also the cheapest trigger detector you will own. The job change filter surfaces people who arrived in a role in the last ninety days, which is the moment they have budget and no incumbent. The posted recently filter surfaces companies talking about the exact problem you solve. Account lists with headcount growth alerts tell you who is scaling before the press release does. For this niche the saved search is titles VP Engineering, Director of Engineering, Head of Hardware, Systems Architect, Firmware and Chief Technology Officer at hardware companies under five hundred people, built as an account list from certification filings and job posts rather than from an industry filter. The posted recently filter is unusually productive here because engineering leaders post about hiring difficulty, and job change alerts catch the departure that creates the hole.

Use it for the research and the verification, not for the message. InMail reply rates are a fraction of email, and the person who replies to a thoughtful email is the same person who ignores a connection request with a pitch attached. Pull the work email from a data provider once Navigator has confirmed the person is real and current.

None of this is specific to your niche. All of it is specific to whether anyone ever reads the angle you spent an hour getting right.

If you would rather not run it yourself

That is what we do. ExpertLayer runs this exact loop for expert led firms: the weekly job post pull with the age clock running on every requisition, the certification filings, the funding announcements, the end of life notices, the departures, the angle written per account against their own job description, the sending across warmed mailboxes, and the quarterly nurture pass that catches the trigger when it fires. You take the technical conversations, which is the part that closes this sale.

The first step is free and it is the same research described above. Send us your website and we will come back with 10 companies that hit these triggers right now, with the requisition, the filing or the departure, the contact, and the opening line for each.

Questions from people running this

Fixed price or time and materials?+

Fixed price the discovery and architecture phase, then move to a dedicated team or time and materials for the build, with a written change mechanism tied to hardware revisions. Boards change, and a fixed price quoted against a schematic that is still in layout is how contract firmware shops go out of business. Say this out loud in the first meeting rather than after the first revision, because the buyer's board wants certainty and the honest version of certainty is a fixed price on the phase you can actually scope.

How do we compete with offshore rates a third of ours?+

Not on rate, and not by criticising the alternative, which their chief executive may have already chosen. Compete on the specific thing that breaks at distance: hardware bring up is an interactive debugging exercise with a physical board, an oscilloscope and somebody who can walk to the bench. Twelve hours of latency turns a two hour problem into a two day one, repeatedly, at the exact point in the programme where the schedule has no slack left. Frame it as where the hours actually go, not as a quality argument.

Should we take the engagement when the hardware is not ready?+

Yes, if you scope it honestly, and it is one of the strongest things you can offer. The board will be late, everyone knows it and nobody plans for it. A firm that arrives with a plan to start on a development kit, build the test harness and stand up the build system while the layout finishes is offering to convert dead weeks into progress. Just price that phase separately so the schedule slip does not silently become your overrun.

How do we handle intellectual property and open source licensing?+

Raise both before they do. Work for hire assignment, what you retain the right to reuse, and a clear statement of how you audit open source licences in shipped firmware. That last one matters more than most firms realise, because a copyleft component compiled into a shipped device is a problem that surfaces at the worst possible moment, usually during diligence. A firm that brings a licence policy to the first meeting is signalling that it has shipped products rather than written code.

Related

Start with 10 free targets.

Send us your website and the kind of customers you want. We come back with 10 bullseye prospects, why each one is relevant, and the outreach angle we would use. No charge, no obligation.

See how the review works