How I Built a Client Pipeline as an Embedded Contractor

I spent my first year as an independent embedded contractor living project-to-project. When one job ended, I would scramble through my inbox, call former colleagues, and hope something came up before the savings ran out. The stress was worse than any technical problem I had ever solved.

After six years, I no longer chase work. I have a pipeline of inbound leads, repeat clients, and referrals that keeps my calendar at roughly 70% utilisation — which, in embedded contracting, is full-time. The shift from "I need a project" to "I need to choose which project" did not happen by accident. It came from a system I built deliberately over several years.

Here is exactly how I did it, what worked, and what I would do differently if I started today.

Step 1: Stop Treating LinkedIn Like a Resume Hosting Service

Most embedded engineers have a LinkedIn profile that lists their skills, past projects, and a job title. That is a digital CV, not a client-generation tool. The difference is in what you publish, not what you list.

I started posting technical notes about specific problems I had solved: how to configure the STM32U5 low-power modes with FreeRTOS, how I debugged a persistent I2C bus lock, how to handle CAN bus timing on Cortex-M4. Nothing polished — just short, specific, useful.

The effect was subtle at first. A former colleague reached out because he remembered my post about SPI register configuration. A technical lead at a consultancy I had never worked with sent me a message asking if I was available. Six months in, I had a steady trickle of inbound leads from people who had seen my posts and thought "this person actually knows embedded."

The key insight: on LinkedIn, being a good engineer is not enough. You need to be visibly competent. Publishing is the cheapest, most scalable way to demonstrate that.

Step 2: Build a Referral Engine, Not a Network

Cold outreach has a low hit rate in embedded contracting. Most firmware projects are not advertised publicly — they are filled through personal recommendations and word-of-mouth within a small technical community.

Instead of trying to expand my network indiscriminately, I focused on building a referral engine with five to ten key contacts: former managers, senior engineers at consultancies, and sales engineers at semiconductor distributors. These are people who hear about projects before they are posted anywhere.

The rule I follow: at least once every two months, I check in with each contact with something useful. Not "are there any jobs" — that makes you look desperate. A recent technical insight, a tool recommendation, a link to a relevant application note. Something that reminds them I exist and that I am active in the field.

After three years of this pattern, I now get referrals without asking. A project comes up at a medical device company in Bologna, and someone I worked with four years ago thinks of me. That is how the best contracts come through.

Step 3: Qualify Leads Before You Write a Line of Code

The biggest mistake I made early on was saying yes to every project. The result was a string of underpaid, over-scoped engagements with clients who did not understand what firmware development actually costs.

Now I have a pre-qualification checklist I run on every inbound lead:

• Is there a hardware platform? If the client has not chosen an MCU or built a prototype PCB, the project is still in R&D. I quote a discovery phase, not a firmware delivery.
• Who wrote the requirements? If the requirements come from a non-technical founder or a sales person who promised a feature set to a customer, there is a high risk of scope creep. I push for a joint requirements workshop before quoting.
• What is the timeline? Any embedded project that needs to ship firmware in under three months is either a trivial project or an unrealistic one. I have learned to trust my estimate more than the client's deadline.
• What is the budget range? I state my day rate early. If the budget is less than 70% of my rate, the fit is wrong and it is better to decline immediately than to negotiate down and resent the project.

Qualifying leads early turned my worst contracts into rejected opportunities, which freed up time for better ones. The income impact was neutral in the first year and strongly positive afterwards.

Step 4: Create a Simple CRM in a Spreadsheet

I do not use a CRM tool. I use a Google Sheet with three tabs:

• Active leads — companies I am in conversation with, with dates of last contact, stage (initial chat, technical interview, proposal sent, contract signed), and estimated value
• Past clients — every client I have worked for, with project scope, rate, what went well, what I would do differently, and a "re-engage date" (when to check in next)
• Contacts — the referral engine people, with notes on what they care about and when I last reached out

I spend fifteen minutes every Friday updating it. That is enough to keep the pipeline visible without turning contracting into a sales job.

Step 5: The Exit Conversation Plants the Next Seed

The most valuable client acquisition moment is the last week of a project. When deliverables are handed over and the codebase is stable, I schedule a handover call and end with three questions:

• "Are there other teams in your organisation that could use firmware support?"
• "Who else in your network works on similar hardware problems?"
• "If you had one piece of advice for how I could be more useful on the next project, what would it be?"

The third question is the most important. It signals that I care about improving, and it often turns into a follow-up conversation six months later when they have a new project and remember: "Davide was the contractor who actually asked how to get better."

Practical checklist

• Publish at least one technical post or article per week on LinkedIn — visible competence beats a polished CV
• Identify five to ten key referral contacts and schedule a check-in every two months
• Qualify every inbound lead against hardware readiness, requirement source, timeline, and budget
• Maintain a simple three-tab spreadsheet as a CRM — fifteen minutes per week is enough
• During every project handover, ask for referrals and feedback
• Say no early to under-budget or unclear projects — the opportunity cost is real

What has worked for me

The single biggest change was shifting from reactive job-hunting to proactive pipeline building. It took about eighteen months to feel the effect. In the first year, I invested maybe fifty hours total — writing posts, checking in with contacts, maintaining the spreadsheet — with zero measurable return. The return showed up in year two and has compounded since.

Embedded contracting is a small world. The same names come up across different companies, different cities, different industries. Building a pipeline is not about knowing everyone — it is about being known by the right few. The people who decide where firmware projects go usually remember the contractor who took the time to share something useful without asking for anything in return.

That is the paradox: you build a pipeline most effectively when you stop trying to sell yourself.