ODM Design and Development for LED Masks: Who Owns Each Decision?

Table of Contents

• 1. ODM Does Not Remove Ownership
• 2. A Responsibility Matrix Built on Four Verbs
• 3. The Platform Boundary
• 4. IP and Data Access
• 5. Changes Belong to Gates, Not to Samples
• 6. Platform Versus Project Engineering — Including Ours
• 7. How We Fill In the Matrix
• 8. References & External Links

---

1. ODM Does Not Remove Ownership

“ODM” is often read as “they design it, I brand it”. That reading is comfortable and slightly wrong. The partner can bring a platform, engineering capacity and manufacturing knowledge; what it cannot bring is your intended use, your market obligations or your decision about what the product is.

In practice the split is not between “their part” and “my part”. It is between four different verbs that get collapsed into the single word “responsible”: who proposes, who executes, who reviews, and who approves. An ODM partner will usually propose and execute a great deal. Review can be shared. Approval of the product, its claims and its market entry stays with the brand, because the consequences of those decisions attach to the brand.

The cost of leaving this ambiguous is not paid at the kick-off meeting. It is paid at the first proposed substitution, the first label revision, or the first test report that describes a configuration slightly different from the one you thought you approved.

---

2. A Responsibility Matrix Built on Four Verbs

Eight activities decide most ODM projects. For each one, name who proposes, who executes, who reviews and who approves — and put it in the development order rather than in a slide. Where an external laboratory or consultant is involved, add the question nobody asks until later: who contracts them, and who controls the reports?

Activity	Who Usually Proposes	Who Must Approve, and Why It Cannot Move
Product requirements and intended use	Brand, informed by what the platform can do	Brand. Intended use determines the market route, the evidence and the claims — delegating it delegates the product.
Industrial design and fit	ODM, within its platform constraints	Brand. Where the platform fixes the geometry, “design” means choosing among existing options — which is worth knowing before you brief it.
Optical and electronic design	ODM	Brand accepts the verification evidence. You are not approving a circuit; you are accepting proof that it performs as claimed.
Component selection and substitution	ODM	Brand, for critical components. This is where change control actually lives, whatever the procedure says.
Risk analysis	ODM drafts, with brand input	Brand reviews and accepts. The risk file is the argument behind every warning; it cannot be an unread attachment.
Verification and test reports	ODM commissions the work	Brand confirms the scope matches the configuration. A report for another revision is not verification of this one.
Labelling, packaging and market documents	Brand, with ODM input on the device’s limits	Brand. Whoever is named on the label owns the obligation, and that name is yours.
Production release	ODM	Brand accepts the release criteria before the first lot. Release authority granted after the fact is not authority.

---

3. The Platform Boundary

An ODM platform is a set of decisions already made. Most of the cost and schedule in a customisation project comes from discovering which decisions those were, one at a time, after committing.

Ask for two lists before design work starts: what is fixed in the existing design, and what can change across appearance, materials, control logic, optical configuration, firmware, accessories and packaging. Then, for each proposed change, record four effects — on testing, on tooling, on production and on documentation.

One distinction saves a great deal of confusion: a cosmetic customisation and a change that affects performance are not equivalent, even when they cost similarly. A new colour may need packaging artwork revised. A new diffuser may need optical re-measurement, thermal re-testing, a revised instruction and a revised technical file. Treating both as “a customisation” is how a project discovers halfway through that it has re-entered development.

---

4. IP and Data Access

Ownership questions are cheapest to settle before the first drawing exists. Seven topics belong in the conversation, and none of them is settled by a friendly verbal understanding.

• Background IP. What the partner already owned before your project, and what rights you have to use it while the relationship lasts and after it ends.
• Project-specific design work. Who owns the drawings, firmware and tooling created for you, as distinct from the platform they extend.
• Tooling ownership. Who holds the moulds, who may move them, and what happens to them if the relationship ends.
• Rights to use files. Whether you may take the CAD and artwork to a second source, and under what conditions.
• Access to technical records. Your ability to obtain the documents you need for regulatory purposes, including after a supplier change.
• Confidentiality. Both directions. Your specifications are commercially sensitive; so is the partner’s platform, and a serious agreement protects both.
• Improvements. If the partner improves the platform using lessons from your project, who benefits, and does your product still work as approved.

A necessary disclaimer: this is a negotiation checklist, not legal advice. The appropriate terms depend on your contract and the governing law, and the moment to involve a lawyer is before the development order rather than after the first dispute. What this page can do is make sure the right seven questions reach that conversation^[1].

---

5. Changes Belong to Gates, Not to Samples

Require a controlled design baseline and a change process that refers to it. Two rules make the difference between a process and a form.

First, when a supplier proposes an alternative part or a revised design, ask for three things before approving anything: the rationale, the risk assessment and the verification plan. A proposal without a verification plan is a suggestion, and approving it transfers the consequence to you without transferring the evidence.

Second, be precise about what a sample approval covers: a sample approval does not automatically approve every future production variant. It approves the configuration you examined. Anything that departs from that configuration is a new question, and the answer to a new question is a new decision rather than an inference from an old one.

---

6. Platform Versus Project Engineering — Including Ours

Rainbowdo states a starting MOQ of 500 units and a stated monthly production capacity of 100,000 units. In an ODM proposal, those figures describe a commercial baseline — they do not tell you how much of your product already exists.

So ask the question that separates the two kinds of work: which elements of this proposal come from a previously developed platform, and which would require new design, new tooling or new validation? Then confirm how each answer affects five things — the MOQ, the unit cost, the documentation scope, the change-control position and the production window.

A starting MOQ should not be read as a guarantee that every custom configuration is available at that threshold. A configuration built on the platform and a configuration that requires a new tool are two different commercial proposals, and treating them as one is the most common way an ODM project’s budget slips before the first sample.

Planning an ODM project and want the responsibility matrix filled in? Visit our
Custom Light Therapy Manufacturing Page.

---

7. How We Fill In the Matrix

Rainbow Technology runs ODM and OEM programmes from our Shenzhen facility. We would rather agree the four verbs with you at the start than discover the disagreement at the first substitution:

• A completed responsibility matrix for the eight activities above, naming who proposes, executes, reviews and approves each — before design work begins.
• The platform boundary in writing, distinguishing what is fixed in the existing design from what requires new design, tooling or validation.
• An IP schedule covering background IP, project work, tooling and file access, so ownership is a document rather than an assumption.
• A change request format that asks for rationale, risk assessment and verification plan, which is what makes a change process operational rather than ceremonial.
• Sample and small-batch production from 500 units, with a stated capacity of 100,000 units per month; both figures depend on model, configuration, packaging and schedule, and are confirmed in a formal quotation.
• Compliance documentation matched to the exact model for your target market. Where a model holds a 510(k) record we provide the K-number so you can check its scope in the FDA’s public database; clearance is not the same as FDA approval, and the scope differs from model to model.

---

8. References & External Links