Before commissioning an electronic design house, agree both who owns the intellectual property and what your business is allowed to do with the finished design. Those are not the same question. Owning project-specific firmware has limited value if you cannot rebuild it, while receiving PCB manufacturing files does not necessarily give you the right to modify the circuit.
A workable agreement separates new project IP, pre-existing engineering assets and third-party technology. It also specifies editable deliverables, manufacturing rights, access to test evidence and what happens if development stops before completion.
For a CTO or engineering manager, the objective is practical control: the ability to manufacture, maintain and develop the product without an avoidable dependency. The points below are commercial and engineering considerations, not legal advice. Have the final terms reviewed under the contract’s governing law.
What should you agree with an electronic design house?
Record the ownership model, permitted uses, deliverables and transfer conditions in the signed agreement before detailed engineering begins. An NDA protects confidential information, but it does not itself assign ownership or grant manufacturing rights.
Under UK copyright ownership guidance, commissioning and paying for work does not automatically make the customer the copyright owner. The initial owner is generally the author or, for work created in the course of employment, their employer. A UK copyright assignment must be in writing and signed by or on behalf of the assignor.
Other rights, including patents and registered designs, have their own rules. Cross-border projects need particular care because the supplier’s location, the product’s end markets and the contract’s governing law may differ.
Decide whether the commercial model is customer ownership of new product-specific work, licensed use or a defined combination. Avoid relying on phrases such as “all IP included” without identifying the assets and rights covered. Joint ownership also needs detailed rules on exploitation, licensing and enforcement; it is not automatically a simpler compromise.
Separate product-specific IP from reusable engineering assets
Ask the electronic design house to distinguish three categories of intellectual property in an asset schedule, rather than treating the design as one indivisible package.
Background IP is technology that existed before the project or was developed independently of it. Examples include a reusable bootloader, an analogue simulation model or a motor-control library. Record which background assets will be incorporated and the rights needed to use them.
Foreground IP is created through the project. It may include product-specific schematics, PCB layouts, firmware, mechanical interfaces and test software. Define the boundary carefully: a modified background library may contain both existing technology and newly developed functionality.
Third-party IP belongs to another rights holder. Semiconductor SDKs, commercial communications stacks, CAD libraries and open-source components can carry conditions that neither contracting party can simply override.
Choose assignment or licensing deliberately
Assignment transfers ownership of specified rights. A licence permits specified activities while ownership remains elsewhere. A mixed model can work well: the customer owns bespoke product assets and receives sufficient rights to embedded background technology.
For retained technology, define duration, territories, permitted products and access by manufacturers or replacement engineering partners. Address improvements explicitly. A right to reuse generic engineering methods should not become permission to reuse confidential product architecture or commercially differentiating algorithms.
Specify ownership and technical handover separately
Your agreement with an electronic design house should contain a deliverables schedule alongside its IP clauses. Legal ownership does not guarantee that a future engineer can open, understand or rebuild the design.
Use a schedule that distinguishes editable engineering assets from released manufacturing outputs:
| Asset | What to specify in the handover |
|---|---|
| Schematics and PCB layout | Native CAD projects, relevant libraries, tool versions, stack-up and design constraints |
| Manufacturing package | Released fabrication and assembly data, bill of materials, programming instructions and revision identifiers |
| Embedded firmware | Source code, build scripts, dependency versions, configuration files and toolchain details |
| Mechanical integration | Agreed enclosure and interface CAD files, drawings and relevant tolerances |
| Verification and production test | Test specifications, available results, fixture documentation, scripts and calibration procedures |
| Engineering rationale | Agreed calculations, simulations, derating assumptions and unresolved technical risks |
Gerber files can support PCB fabrication, but they are not a substitute for the native PCB project when redesign is required. Similarly, a firmware binary is not source code, and source code without its dependencies may not produce a reproducible build.
Specify the required formats, release baseline and delivery dates. Proprietary CAD or compiler licences may still need to be purchased separately by the receiving organisation. Make those dependencies visible before accepting the handover.
Make firmware and third-party licence obligations explicit
Firmware often combines bespoke application code with device drivers, middleware, libraries and vendor tools. Request an inventory of these dependencies and their licences, including restrictions on redistribution, modification and use with particular hardware.
Do not assume all open-source software has the same obligations. Requirements depend on the specific licence, version and way the software is incorporated or distributed. Commercial libraries may introduce royalties, product limits or additional licences for a replacement developer.
Agree who checks licence compatibility, who approves new dependencies and who maintains the inventory. A software bill of materials can support this process, but it does not replace reviewing the actual licence conditions.
An electronic design house should also make clear which development tools and vendor accounts the customer needs to maintain the product independently. This includes compilers, configuration utilities and any externally hosted services required by the agreed design.
For secure products, address custody and controlled access to signing keys, provisioning credentials and device identities. Simply placing private keys in a source archive is not a sound handover process. The contract and security procedures should identify who controls these assets and how authorised production or maintenance continues after the engagement ends.
Verify the ownership chain and protect disclosures
An assignment is only useful if the supplier has the rights it promises to transfer. Ask how employee contributions, freelance development and subcontracted work are covered. The agreement should require the necessary rights to flow through the supply chain.
This matters when different contributors create firmware, PCB layouts, test fixtures or mechanical elements. Do not assume that a subcontractor’s invoice establishes ownership or permits onward licensing.
When an electronic design house uses external contributors, define the confidentiality requirements and any approval process for subcontracting. For defence or other sensitive applications, separately assess applicable access restrictions, export controls and information-handling obligations.
Confidentiality terms should cover customer-provided designs, unpublished inventions, source code and technical findings. Also agree whether project details, photographs or performance results may appear in marketing material. Uncontrolled disclosure can compromise trade secrets and may affect patent protection.
Ownership is not the same as freedom to operate. Possessing the rights to your own design does not establish that the product avoids another party’s patents. Where commercially justified, commission a separate, appropriately scoped freedom-to-operate assessment. Discuss proportionate warranties, remedies and liability allocation with legal counsel rather than treating a broad “non-infringement” statement as a technical investigation.
Connect payment, acceptance and termination to usable rights
State when ownership transfers or licences take effect. Possible triggers include creation, payment for a defined milestone or final payment. These choices have different consequences if the project pauses, a payment is disputed or either party becomes insolvent.
Avoid an arrangement in which substantial completed work has been paid for but remains unusable because one later milestone is unfinished. Equally, a supplier may reasonably protect unpaid work. The agreement should resolve that balance explicitly.
With an electronic design house, milestone acceptance should cover both engineering evidence and the associated handover package. Depending on the project, checks might include opening the native CAD project, building firmware in a documented environment and reconciling manufacturing files with the released bill of materials.
Define what happens on early termination: which completed and partially completed assets are delivered, what payments are due and which rights survive. Identify known defects, unverified functions and incomplete documentation so another team does not mistake work in progress for a production release.
For critical retained technology, source-code escrow may be worth considering. Its value depends on the deposited material being complete and current, with workable release triggers and sufficient usage rights. Escrow is not a substitute for routine delivery of assets the customer is already entitled to receive.
Preserve manufacturing freedom and lifecycle control
The agreement should support the product’s expected operating life, not just its first prototype. Consider whether your organisation can appoint an alternative assembler, change a component, update firmware or commission a redesign without renegotiating fundamental rights.
Licences may need to permit use by named affiliates, contract manufacturers and future development partners acting on your behalf. Define this scope precisely, including relevant territories and any applicable legal restrictions. “Internal use only” may be insufficient for a product that will be manufactured and sold.
Ask the electronic design house how retained technology affects future manufacturing transfers and product variants. Necessary permissions should be agreed before a component becomes obsolete or a production supplier needs replacing.
Technical control also requires a coherent release baseline. The principles of managing design changes during PCB contract manufacturing remain relevant after handover: hardware, firmware, test instructions and manufacturing data must identify compatible revisions.
Specify which qualification reports and compliance evidence are included, together with their scope and limitations. Access to EMC results or safety calculations does not establish compliance for every later modification. Ownership and document access also do not, by themselves, transfer statutory manufacturer obligations.
Finally, separate ownership from ongoing support. Response arrangements, maintenance responsibilities, component monitoring and future engineering capacity require their own agreement; they do not arise automatically from an IP assignment.
Review the IP schedule against practical scenarios
Before signing, test whether the proposed agreement supports the decisions your business may realistically need to make. Start with the product scope, operating environment and production assumptions described in your custom electronics design requirements.
A review with the electronic design house should answer these questions in writing:
- Can another engineering team modify the schematic, PCB and firmware using the delivered assets and granted rights?
- Can an alternative manufacturer build, program and test the product without an additional IP negotiation?
- Are incorporated background assets and third-party dependencies identified with usable licence terms?
- Can the business maintain existing products and develop the agreed variants after the engagement ends?
- What usable files and rights remain available if development stops halfway through?
- Who controls confidential information, production credentials and any patent-filing decisions?
For example, replacing an obsolete microcontroller may require changes to the PCB, bootloader, application firmware and production programmer. If the agreement only covers the original manufacturing outputs, that routine lifecycle event could expose several separate dependencies.
Resolve those dependencies while the contract is being negotiated, rather than after the original engineering team has moved on.
Frequently asked questions
Does paying an electronic design house mean we own the design? Not automatically. Payment and IP ownership are separate matters. The result depends on the relevant rights, governing law and contract. Specify any assignment or licence, its scope and when it becomes effective.
Do we need to own every part of the design? No. Ownership of bespoke product assets combined with adequate licences to reusable technology can provide effective control. The essential test is whether you can manufacture, sell, maintain and modify the product as required, including through authorised third parties.
Are PCB manufacturing files enough for a complete handover? Usually not if you expect to maintain or redesign the product. Manufacturing outputs support production, while native CAD projects, firmware source, build instructions and test documentation support engineering changes. Define the package against your intended future activities.
Does an NDA protect our ownership? An NDA creates confidentiality obligations within its terms. It does not normally transfer IP ownership or establish rights to manufacture, modify or sublicense a design. Those provisions belong in the development agreement.
What if the supplier will not transfer its background IP? Establish which assets are retained and negotiate sufficient licence rights, technical access and continuity arrangements. A supplier can retain reusable technology without leaving the customer unable to support its product, provided the terms and deliverables are adequate.
If you are planning development or reviewing an existing handover, discuss your project with ProMicro’s engineers. Bring your proposed deliverables, product roadmap and manufacturing expectations to a technical conversation about the assets and access needed to support embedded firmware, power electronics and analogue design throughout the product lifecycle.
