Notes for owners · Industry playbooks
What an embedded systems client wants to see before hiring a design partner
What an OEM or product founder checks before hiring an embedded design house: products actually shipped, a test process they can see, and written terms on who owns the code at handover.
The GullySales team · Updated 17 Oct 2026 · 5 min read
On this page
An embedded client has often been let down once already. A freelancer left with the source code. A firm showed a demo board that never survived the field. So before hiring you, the engineering head or founder wants three things in plain view. First, products you have actually shipped, not boards that worked on a bench. Then a test process they can see. Last, a written answer on who owns the code, schematics and layout when the project ends. The deck of logos and technologies can wait.
The fear is specific. Can my engineer build the firmware if you shut down tomorrow? Will this pass the field trial, or only your bench? Am I paying you to learn my trade? A design partner who answers those before they are asked looks like a firm that has done this before.
Your buyer is the engineering head or the founder, not purchase, at least not yet. That means a product founder, an R&D head at an OEM, or an engineering manager replacing a controller that a foreign supplier stopped making. They will forward your material to someone senior, and that person will read one page. Make sure it is the right page.
Past products: shipped, not demoed
A board photograph proves you can make a board. A client wants to know that a product you designed is in use, in numbers, somewhere hot, wet or dusty. Write one project sheet per product, a page each:
- What the client needed, in one sentence, without the client's name unless they have agreed in writing.
- The microcontroller family, the interfaces and protocols, the power source and any real-time limits.
- Your share of the work: hardware, firmware, enclosure, test jig, production support.
- Units shipped, and years in the field.
- What went wrong after launch, and what you changed.
Write that last line even when it is uncomfortable. A partner who can describe a field failure and its cure is more believable than one whose every project went perfectly.
If you have shipped very little, say so. Offer a paid prototype phase instead of a full design contract, and let the work speak.
The test process, shown as it is
"Rigorous testing" means nothing on a slide. Show the actual artefacts. A test plan template and a photograph of the bench with its instruments. A sample report with real readings from a past project. The way firmware versions and bugs are tracked. Show the test jig you built for a production run, if you built one.
Be honest about the gaps. If you have no environmental chamber or compliance lab, name the outside labs you use. Certification for the client's product, and which tests apply to it, is for the client and the test lab to settle; rules differ by product and market and change. Say that plainly rather than implying you can sign it off.
Who owns the code, in writing
This question often gets a vague answer, and a vague answer costs projects. Put a one-page handover list in the proposal. It says what the client receives at the end: firmware source, build instructions and toolchain versions, schematics, layout files, BOM, test jig design and test procedures. It also says what you keep, such as general libraries you reuse across clients, and what licence the client gets to them. Third-party and open-source components go on the list with their licences.
The exact contract wording is a matter for both sides' lawyers. The list is what lets the engineering head say yes before the lawyers start.
The capability pack, in order
- A one-page summary: the kinds of product you design and the families and protocols you know well.
- Three to five project sheets, as above.
- The test process page, with a sample report attached.
- The handover list.
- How a project runs: phases, what the client approves at each, and who on your team they will speak to.
- Two reference contacts, if past clients allow it.
Leave out the long list of every tool and chip you have touched. It pushes the pages that matter further down.
Imagine: a Kochi design house and a Nashik sprayer maker
Imagine an embedded design firm in Kakkanad, Kochi. A maker of battery-powered agricultural sprayers in Nashik wants a motor controller with a charge indicator, to replace an imported board. The details are illustrative.
The firm pitched with a long deck: technologies, logos, a demo board on the table. When the Nashik owner asked who would own the source code, the answer was "as per discussion". The last vendor had kept the code, and the owner had paid twice to get a firmware change made. The Nashik owner thanked them and went quiet.
The firm's founder asked for one more meeting. She brought three project sheets, one describing a field failure in a dusty site and the redesign that followed. She also brought a sample test report from a past product, shared with that client's permission, and a one-page handover list. The client would own the source, schematics and layout. The firm's driver library, which it reuses across clients, would be licensed to the client without a time limit. That concession cost the firm something real: it could no longer sell that library as a separate item to anyone the client named as a competitor. The Nashik owner sent the handover page to an in-house engineer, who asked for two changes to the build instructions. A week later the owner signed for a paid first phase: a prototype controller and a field trial on the sprayers, with the full design contract left open until the trial ended.
When the pack is not enough
A pack wins attention; it does not win every project. Nor is it written for a purchase manager. Send it to the engineering head or founder, and let them forward it. If the client wants a fixed price for a specification that does not exist yet, propose a paid definition phase and quote the rest after it. If they are comparing firmware hours on price alone, you are not the partner they are looking for. Say so politely.
Write the handover list first
Draft it this week, before any deck, because it is the page most likely to decide the project. Start with the product you shipped most recently, list what the client would have received at the end, and mark every item you would hesitate to hand over. Those hesitations are the terms to settle with your own lawyer before the next proposal goes out. The pack that follows can be built around capability presentations, and how electronics buyers choose more widely is on the electronics and embedded systems page. If you want it written around projects you have really shipped, tell us what you need.
