From Development to Production: Building a Watch
A product does not go from a requirement to a shipped unit in one step. It goes through five, and each one produces something the next one depends on. When a project runs late, the cause is almost always a gate that was passed before its artefact existed.
This page follows the route at the level the evidence supports. Every stage below carries what is still open at that stage — at the same weight as the work — because a sequence that implies every input is already known is not a plan, it is a diagram. Where a figure does not exist, it is named as missing rather than estimated. Where a limit cannot be changed later, it is stated at the stage that fixed it.
Read the third column before the first. Most process descriptions list the work and leave you to discover the unknowns yourself. The open points here are published in position, stage by stage, so you can see which decisions your project has to close before the next stage is meaningful.
The five stages
Design intent
What the product is for, how it is worn, which market it is for, and what will be said about it publicly. This is where the claim set is fixed, because the claim set is what the hardware has to be able to support.
Artefact the stage produces
A requirement record: intended use, wear position, target market, and the statements the product is expected to support.
Document class: Design and requirement records
Still open at this stage
- The intended use and the claim set, in writing — this is the input every later stage assumes.
- The target market, because the market determines which authorization applies and who carries the duty.
- Whether the product is a variant of an existing platform or a new development.
Why this gate matters: The limits that will constrain the product for its whole life are set here. Water resistance, wear duration and sensor architecture are chosen at this stage, and production cannot recover them later.
Engineering integration
Turning intent into a buildable configuration: the platform, the enclosure and structural direction, the hardware around the chosen platform, and the app surfaces the product will rely on.
Artefact the stage produces
A frozen configuration record — platform, structure and interface decisions, each in a version that later stages can be measured against.
Document class: Configuration and interface records
Still open at this stage
- The platform configuration, and which app and software surfaces can be customized — stated per surface rather than in general terms.
- Who owns the companion-app store listing and the publisher identity.
- Which integration patterns are supported for your data flow, and which are enabled case by case.
Why this gate matters: This is the cheapest stage to change a decision and the most expensive one to have changed for you. A platform assumed rather than agreed surfaces later as a product that cannot do something, after the enclosure exists.
Verification & documentation
Testing the configured product against what it was specified to do, and producing the records that show it. This is where a product accumulates the evidence that travels with it.
Artefact the stage produces
Verification records for the configuration, and the document set that will accompany the product.
Document class: Verification and conformity records
Still open at this stage
- Which conformity records exist per model, per directive, and for which territory.
- Whether any accuracy or clinical record exists for the specific device — a separate category of evidence.
- Which documents must exist before a specific market will accept the product, and who produces each.
Why this gate matters: Verification is not the same as authorization, and a facility-level certificate does not cover an individual product. The records produced here are the product layer; the certificates the company holds are the factory layer.
Pilot build & evaluation
Building physical units against the agreed configuration so the product can be judged in the hand rather than in a rendering, and evaluating them against criteria agreed before the build.
Artefact the stage produces
Pilot units, plus a written evaluation against the acceptance criteria, and a sign-off or a change list.
Document class: Build and evaluation records
Still open at this stage
- Pilot scale, duration and the acceptance criteria — agreed in writing before the build, not after it.
- Who evaluates, and what counts as a pass.
- What happens to findings: which ones become changes and which become documented limitations.
Why this gate matters: A pilot without pre-agreed acceptance criteria is a demonstration, not a test. The value of the stage is entirely in the criteria being fixed before the units exist.
Production & handover
Ramping the agreed configuration into production and transferring the artefacts the partner needs to run the product commercially.
Artefact the stage produces
Production records, and the handover set — artwork, the document package, and the operational arrangements for support and spares.
Document class: Production records
Still open at this stage
- MOQ, lead time and the production slots that would apply to your volumes.
- The after-sales model: who supports the product, the escalation route, and the replacement trigger.
- What you are holding at the end of the project — named item by item, rather than assumed.
Why this gate matters: Handover is where projects most often discover that an item nobody owned was never produced — an app listing, an artwork freeze, a record a market requires. Naming the set at the start is what prevents that.
The factory layer and the product layer — and why a certificate does not cover your product
The single most common misunderstanding in a wearable project is the assumption that the certificate the supplier holds covers the product you are buying. It does not, and the reason is structural rather than legalistic: the documents sit at different layers of the same operation.
| Factory & process layer | Product layer | |
|---|---|---|
| What it describes | The facility and the process that governs how work is done | The specific device this project is producing |
| Who produces it | The company’s management system, maintained continuously | The project, stage by stage, as it moves through the route |
| Scope | Bounded, and stated on the document itself | Device-specific and market-specific |
| Documents we hold at this layer | Medical-device Production Licence (Class II category 07 scope); Medical Device Quality Management System Certification, ISO 13485:2016, scope bounded by the qualification licence | Produced per project: design and requirement records, configuration and interface records, verification and conformity records, build and evaluation records, production records |
| What it does not do | Does not authorize a product in any market, and does not establish accuracy | Does not exist until the project produces it — a facility certificate does not stand in for it |
The practical consequence: when you review a supplier’s documents, ask separately about each layer. The factory layer tells you whether the process is governed and whether the facility may manufacture the category. The product layer tells you what exists for your device, in your market. A supplier that answers only the first question has answered a different one — and the document classes behind each layer are set out in How to Read a Health-Wearable Manufacturer’s Quality Documents.
Limits that production cannot recover
Three limits on our products are worth stating at the stage that fixes them, because a distributor that plans around a capability the product does not have will discover the gap after the listing is committed.
Wrist watches — IP67
Fixed at design intent, by the enclosure and the sealing
IP67 is short-term shallow immersion only. It is not a swimming permission, and it is not a rating for hot water.
Smart ring — daily use
Fixed at design intent, by the ring structure and sealing
Daily use only. No swimming, no hot springs and no prolonged submersion.
CGM — S10 is a separate sensor
Fixed at design intent, by the sensing architecture
S10 is a separate adhesive sensor applied to the body. The watch and the app only display synchronized data — the watch does not measure glucose. No software change turns it into a glucose-measuring watch; that would be a different product.
These are also the reason a claim set is fixed at design intent rather than written by marketing at the end. A product’s limits are decided where the enclosure, the sealing and the sensing architecture are chosen — and the portfolio’s full set of limits is stated on the company page.
What is in-house, and what is not
We draw a clear line rather than claiming everything sits under one roof: PCBA assembly is outsourced, while complete-device production is primarily self-produced with outsourced processing support. That is the documented position, stated here as it is recorded — not smoothed into a vertical-integration claim.
Which is why the useful question at the production stage is not “what do you make?” but “which steps in this flow are outsourced, and who is accountable at each?” That question is worth asking of every supplier, including this one, and the answer belongs in your project file in writing — before the pilot builds are ordered, not after.
The facility and process scope behind that split is the subject of the factory tour route; the development relationship — what can be customized, in what order, and who decides what — is documented on the OEM & ODM page.
Why there is no schedule on this page
A route without a duration is uncomfortable to publish, and it is the honest version. No verified duration exists for any stage, so none is given — an invented one would be worse than none, because you would plan against it. What the route does give you is the list of inputs that would have to be closed before a schedule could be written:
- The intended use and the claim set, in writing
- The platform configuration and the extent of app and software customization
- Who owns the companion-app store listing and the publisher identity
- The pilot scale, duration and acceptance criteria
- The target market, and who carries the market-facing duty there
- The commercial terms — MOQ, lead time, tooling and sample arrangements
- Which steps in the specific flow are outsourced, and who is accountable at each
Close those in writing and the route above becomes a plan you can hold a date against. Until then, any date offered is an estimate with nothing behind it — and the same is true of any supplier, which is why the question is worth asking in a form that produces a written answer.
Key takeaways
- Five stages — design intent, engineering integration, verification and documentation, pilot build and evaluation, production and handover — each gated by the artefact the previous one produces.
- The claim set and the product’s limits are fixed at design intent. Water resistance, wear duration and sensor architecture are not recovered by production.
- The factory layer (production licence, ISO 13485 certificate) and the product layer (per-project records) are different documents produced by different things. A facility certificate never covers an individual product.
- PCBA assembly is outsourced; complete-device production is primarily self-produced with outsourced processing support. Ask which steps in your specific flow are outsourced, and who is accountable at each.
- No duration is published, because none is verified. The page names the inputs that would make the route schedulable instead of inventing a timeline.
- Pilot acceptance criteria and the handover set must be agreed before the stage that depends on them.
Frequently Asked Questions
Questions buyers usually need answered first
Practical answers about product selection, everyday use and planning your project.
Visit the FAQ pageWhat actually happens between “we want this product” and a shipped unit?
Five stages, each of which produces something the next one depends on. Design intent fixes what the product is for, how it is worn, which market it is for, and what will be said about it publicly. Engineering integration turns that into a buildable configuration — the platform, the enclosure, the hardware and the app surfaces. Verification and documentation produces the records that show the configuration was tested and the documents that travel with the product. Pilot build and evaluation puts physical units in front of the people who will judge them, against agreed criteria. Production and handover is the ramp and the transfer of the artefacts your business needs. Each stage has a gate: the artefact from the previous stage has to exist before the next one is meaningful.
Why can’t water resistance, wear duration or a different sensor be added later in the project?
Because these are design-intent decisions, and production cannot recover them. Watch IP67 is short-term shallow immersion only — it is not a swimming permission and it is not hot water; a product designed to that rating cannot be marketed as a swim device later, whatever the enclosure marketing says. The smart ring is for daily use — no swimming, no hot springs, no prolonged submersion. And in the CGM system, S10 is a separate adhesive sensor while the watch and app only display synchronized data — the watch does not measure glucose, so no amount of software work turns it into a glucose-measuring watch. These limits are set where the enclosure, the sensor architecture and the sealing are chosen. Changing them afterwards is a different product, not a configuration change.
Where does the factory’s ISO certificate fit in my project — is my product covered by it?
They are different layers, and conflating them is where projects get into trouble. The company’s production licence and ISO 13485:2016 certificate sit at the factory and process layer — they are produced by the management system that governs how the route runs, and the ISO certificate’s scope is wrist electronic blood pressure monitor design and production within the licence scope. They are not produced by any individual product passing through the route. Your product’s own artefacts — the design and requirement records, the configuration and interface records, the verification and conformity records, the build and evaluation records, and the production records — are produced stage by stage, by the project. A facility certificate tells you the process is governed; it does not tell you that a product is authorized in your market. That second question has its own document class, explained in How to Read a Health-Wearable Manufacturer’s Quality Documents.
Which steps are actually done in-house, and which are outsourced?
We draw a clear line rather than claiming everything sits under one roof: we build complete devices ourselves, and PCBA assembly is outsourced. We would rather say so plainly than describe ourselves as fully vertically integrated. For a specific project, the useful question is not “what do you make?” but “which steps in this flow are outsourced, and who is accountable at each?” — and it is worth asking every supplier, including this one. The answer belongs in your project file in writing, at the production stage, before the pilot builds are ordered.
What should be approved before bulk production starts?
Approve a production sample, the final specification, packaging artwork and inspection criteria. Freeze the hardware and software versions, identify the required market documents and record how later changes will be reviewed.