Launching a wearable line looks like a sourcing decision and behaves like an engineering programme. The device you choose determines the sensor path, the battery envelope, the app scope, the onboarding flow and — most consequentially — the claims you are permitted to make. Brands that treat the device as a shopping decision and the claims as a marketing decision almost always have to renegotiate one of them late, and late is expensive.

This guide is written for the people who have to sign off that claim set: brand owners, product managers and project buyers adding a health wearable to a portfolio under their own brand. It sets out the sequence in which these decisions should actually be made, and it separates the two questions that quietly sink programmes — who carries the market-facing authorization duty, and who owns the app.

LUROGEF wearable device production and assembly workshop line
Production and assembly line, Shenzhen. Programme scope maps onto the stages visible here.

1. Write the Intended Use and the Claim Set First

The first deliverable of a private-label wearable programme is not a bill of materials. It is one page containing two things: a sentence describing the intended use, and the set of claims the brand intends to publish. Everything downstream — platform, sensors, app scope, packaging, onboarding — is derived from that page.

Write it in bounded language. "Reports resting pulse trends, daily movement and a relative skin-temperature trend" is a promise a wellness wearable can support. "Detects irregular heart rhythm" or "screens for sleep apnea" are not, because they imply sensing paths that these devices do not contain. The discipline of writing the sentence first is what stops a programme from discovering its own limits in a regulatory review — or, worse, in a customer complaint.

Two device-family facts belong on that page from the outset, because they constrain the promise more than anything else. A wrist blood-pressure device measures through a pump and a dedicated airbag in the strap, and its water resistance is short-term shallow immersion only — no swimming and no hot water. A smart ring is for daily use only, excluding swimming, hot springs and prolonged submersion. If your intended use depends on either limit being different, that is a claim problem to solve now, not a spec problem to solve later.

2. Platform Selection: Routing the Promise to a Family

Rather than comparing devices feature by feature, route your programme by the promise written in step one. Three families are available as starting platforms, and each carries a different architecture — which is why the choice is consequential rather than cosmetic.

  • A wrist measurement ritual. If the promise centres on a familiar, wrist-based measurement performed deliberately by the user, the blood-pressure watch family — VC60, VC61, VP20 and VP21 — is the natural platform. The strap carries a dedicated airbag and the device performs a cuff-style measurement rather than inferring one from an optical signal. The format is familiar, which makes the user-education burden lighter.
  • A discreet all-day wearable. If the promise is continuous, screen-free wear across day and night, the smart ring platform — CARE2 — fits that position. Its documented sensor set is PPG optical sensing, a 3-axis accelerometer and an independent temperature module, and its battery is correspondingly small. A ring has no display to explain itself, so the app carries the entire explanation burden.
  • A connected monitoring programme. If the promise involves monitored data viewed by someone other than the wearer, the CGM and connected monitoring family is a fundamentally different proposition: it is a sensor-plus-display system, not a watch feature. The S10 is a separate single-use adhesive sensor applied to the arm. A compatible watch and the companion app receive and display synchronized data. The watch does not measure glucose, and no non-invasive sensing claim is supported.
  • Anything the platform cannot support. Route away. If the promise requires an ECG electrode path, blood-pressure measurement on a ring, or glucose sensing from a watch alone, the right response is to change the device family — or the promise. Negotiating a claim down to something a chosen device can approximate is how programmes acquire claims they cannot defend.

The programme-fit differences between the three families, laid out on the dimensions a brand actually decides on, are summarised on the health brands and distributors requirements path.

3. Scoping the Brand Layer — and Getting It in Writing

The brand layer is everything that makes the product recognisable as yours: industrial and structural design choices, the watch face or ring finish, the app's visual identity, packaging composition, accessory presentation and the label artwork. Customisation across watch face, app, software and hardware is a documented capability of the development partner, alongside industrial design, structural design, hardware solutions, UI design and independently developed mobile applications.

The discipline that matters here is transferable to any supplier: agree the scope item by item, in writing, rather than in general terms. "We can customise the packaging" is not a scope. "The outer box, the insert, the quick-start card and the accessory pouch are all produced to artwork we control; the finish is available in these options; the watch face is built from these elements" is a scope. The difference between the two sentences is the difference between a sample review that goes smoothly and one that reopens every decision.

Several items legitimately remain open at this stage and should be named as open rather than assumed: the exact boundary of what can be changed, software interface documentation, supported languages, order quantity and the programme schedule. Naming them as open is not a weakness in the plan — it is what allows the rest of the plan to be trusted.

4. Certification and Market Authorization: Who Actually Carries It

This is the section that decides whether a programme can be listed at all, and it is routinely left vague because it sounds like a legal question rather than a project question. It is both. The answer starts with one identification: which entity is placing the product on which market? That entity — normally you, the brand — carries the registration or listing duty, the label identity and responsibility for the claims actually published in that market.

Against that sit the documents the manufacturing partner provides. These fall into two families, and conflating them is the most common source of false comfort in this category.

  • Factory and process documents. A medical-device production licence or a quality-management-system certificate (for example ISO 13485) describes the manufacturing and quality environment in which devices are made. It is real, it is relevant to supplier due diligence, and it carries a bounded scope — specific product categories and a defined range. It is not an approval of your product and not a market authorization.
  • Device-level declaration and conformity documents. These relate to a named model and to specific directives — for example an EMC or radio-equipment assessment or a hazardous-substance declaration. They are evidence about that model and those directives. They are not a medical certification, and they do not authorize a medical claim for any market.

The practical consequence is a short list of questions to settle in writing before artwork is frozen:

  • For each market you intend to sell into: is the device placed on that market as a general consumer electronic product, a wellness device or a regulated medical device? That classification decides the route.
  • Which party holds the market-facing registration or listing for that market, and under whose name?
  • Which documents will the supplier provide for that submission, and are they current for the specific model?
  • What exactly does each document cover? Read the scope line, not the title.

No product described on this site is claimed to be certified, registered or authorized in any market, and the answer to each question above depends on your territory and intended use. Territory-specific requirements must be confirmed with your own regulatory advisor, and the supplier's answers must be obtained in writing rather than inferred from a capability list. A distributor working the same question from the other side of the table has a matching checklist in what a distributor should verify before listing, and the underlying custom-development process is described on our OEM & ODM page.

5. Packaging, Labels and Artwork Control

Packaging is where the claim set becomes physical, which is why it belongs after step four rather than before it. Label identity belongs to the brand as the market-facing entity; the label's content has to stay aligned with the approved claim set, and market-specific label requirements vary by territory.

Three practices keep this stage from becoming a reprint. First, freeze artwork only after the claim set is validated — the reverse order guarantees a revision. Second, keep a single controlled version of each artwork file with a named owner, so that the printed content can be traced to the approved claim. Third, if the brand publishes certificate documents anywhere in its materials, show the document title and the unchanged original rather than a re-narrated summary; altering a certificate or implying a broader scope than it carries is a compliance problem, not a design choice.

Packaging composition and accessory presentation are produced as a joint deliverable against artwork you control, and the accessory set — cable, dock, quick-start material, pouch — should be part of the scope agreed in step three rather than added at the sample stage.

6. The App: Whose Listing Is It, and Who Owns It After Launch?

Every wearable programme needs an app, and most programmes never explicitly decide who owns it. That omission is invisible during development and acute after launch — when a store policy changes, a certificate expires, a review arrives, or the partnership ends.

Settle four decisions in writing:

  • Whose developer account publishes the app. This determines who controls the listing, who can respond to a store issue, and whose name appears next to the product.
  • Which name appears as the publisher. A storefront listing under a supplier's name is a weaker brand asset than one under yours, but it is also a lighter operational burden. Either is workable; leaving it undecided is not.
  • Who carries store-policy compliance and update duty. App ecosystems impose requirements that change over time. Someone has to own them continuously, not just at launch.
  • What happens to existing installs if the relationship changes. This is the question to ask before signing, because it is nearly impossible to negotiate afterwards.

Around the app sits the data layer. Wireless device-to-app data transfer, customer-app integration and a cloud health platform with third-party service integration are documented capabilities, and app, software and hardware customisation is confirmed. What is not yet confirmed — and must be settled rather than assumed — includes software interface documentation, supported languages and app publishing ownership. Programmes whose value depends on integrating the wearable's data into an existing clinical or care workflow should treat that integration as its own workstream rather than a feature toggle.

7. Realistic Programme Staging — Sequence, Not a Number

This guide deliberately does not give you a duration. No verified programme duration exists in our evidence base, order quantities, tooling terms, sample terms and lead time are all still to be confirmed, and a number invented here would be a number your plan would be built on. What can be given honestly is sequence and dependency — and in practice that is what a programme plan needs first.

  1. Requirement definition. Intended use, target market and claim set written and agreed. Nothing else can be fixed until this is.
  2. Platform and customisation scope. Family selected; customisation boundary agreed item by item. Depends on step one, because the claim set constrains which family is viable.
  3. Sample build and evaluation. A physical sample built to the agreed scope, judged in the hand rather than in a rendering. Depends on the agreed scope, not on a general intent to customise.
  4. Claim validation and artwork freeze. The claim set is validated against the platform's real capabilities, then packaging and label artwork are frozen against it. Artwork cannot be frozen before the claims are, or it will be reprinted.
  5. Documentation package. The device-level documents applicable to the chosen model and its directives are identified and assembled. Depends on the model being final — which it is only after step two.
  6. Market-entry preparation. The market-facing entity confirms what its territory requires and which documents it will submit. Depends on the documentation package and on the target market being decided.
  7. Production. Units built to the frozen specification, artwork and claim set. Every stage above is a precondition, which is why compressing them is not a shortcut.

Ask any supplier for a written schedule against this sequence, with the assumptions it rests on stated. A schedule without assumptions is a date; a schedule with assumptions is a plan you can manage.

8. Four Ways These Programmes Go Wrong

Symptom Underlying Cause Prevention
A claim turns out to be unpublishable after marketing material exists The claim set was written after the hardware was chosen, so it was never checked against the platform's real sensing paths and use limits. Write the intended use and claim set first (step one), and validate it explicitly at step four before any artwork is frozen.
The sample review reopens settled decisions Customisation was agreed in general terms rather than item by item, so each party arrived at the review with a different expectation. Agree the customisation scope item by item in writing, and name the items that are still open rather than leaving them ambiguous.
An app store issue becomes a crisis after launch Nobody owned the publishing account, the policy compliance duty or the update path. The decision was assumed rather than made. Settle the four app decisions in writing: publishing account, publisher name, compliance and update owner, and what happens to existing installs.
A market listing is blocked late in the programme Both parties assumed the other had accepted the market-facing registration duty, and neither had identified the classification route for that market. Allocate the duty in writing per market at step one, and establish the classification route and required documents before artwork is frozen.

9. What to Have in Writing Before You Commit

  • The intended-use statement and the claim set, agreed internally and shared with the supplier.
  • The customisation scope, item by item, with the still-open items named as open.
  • The device-level documentation for the chosen model, with each document's scope line readable, and a statement of which documents the supplier will provide for your market submission.
  • The label artwork control arrangement, with a single controlled version and a named owner.
  • The app publishing and ownership decision, covering the publishing account, publisher name, compliance and update duty, and the contingency for installs.
  • The commercial terms — order quantity, price, tooling and setup, sample terms and lead time — obtained as confirmed figures rather than estimates.
  • The schedule, with its assumptions stated.

Any item on this list that is not supplied in writing remains unconfirmed and should be treated as such. That rule is unglamorous and it is the single most reliable predictor of whether a private-label wearable programme reaches production without a late, expensive reversal.

If your organisation sits on the distribution side of this decision instead, the matching instrument is how to evaluate a health wearable supplier. If you are ready to discuss scope, the full requirements path for brand owners and distributors sets out what a first conversation needs.