Development Guide · Project Process
How a Private-Label Wearable Project Runs
Six stages in dependency order, the decision owner named at each one, and the artefact that has to exist before the next stage can begin. It is written for the buyer who has to plan and steer the project — if you already need the obligation side of the same relationship, that is the buyer-obligation guide; if you have not yet read the capability scope, start with the OEM & ODM overview.
You will not find a schedule in this guide. We have no project duration, MOQ, tooling or setup charge, sample term, lead time or capacity figure that we can put our name to yet, so we are not going to print one. What we can give you is the parts that number is made of — the decisions, the dependencies and the handoffs — and those are the parts that will actually transfer to your project.
Testing and development laboratory, Shenzhen.
1. The Whole Project on One Page
A custom wearable project is not a single decision. It is six decisions that have to be made in order, because each one narrows what the next one can be. Most projects that go wrong did not make a bad decision — they made a good decision in the wrong sequence, and the cost of the reordering was paid at the end rather than at the start.
The table below is the entire guide in compressed form: the stage, who owns the decision, what must exist before the next stage starts, and — the column that carries the most information — what actually happens by default when nobody owns the decision. That last column is not hypothetical; it is the ordinary behaviour of a project with an unowned gate.
| Stage | Decision Owner | What Must Exist Before the Next Stage | The Default If Nobody Decides |
|---|---|---|---|
| 1. Requirement definition | Joint — the partner writes it, LUROGEF checks it against what is buildable | A requirement record: what the product shows or measures and on whom, how it is worn, which market, and what the partner intends to say publicly about it. | Design starts against an assumed requirement. The correction arrives later as a redesign rather than as an edit to a document. |
| 2. Industrial & structural design | Partner — it is your brand’s form language. LUROGEF advises on feasibility and constraint. | An agreed design direction, and the structural constraints it imposes on the hardware that has to fit inside it. | The design direction is settled by whoever produces artwork first, and the partner sees a product they did not actually choose. |
| 3. Hardware & firmware platform | Joint — and this is the decision where ownership most often drifts | A frozen platform configuration record. Everything after this stage assumes it. | The platform is treated as a supplier detail. It surfaces later as a product that cannot do something the partner assumed, after the enclosure exists. |
| 4. App & UI customization | Joint — the partner owns brand expression and the language set; LUROGEF owns the implementation | A defined customization scope for each surface, with the extent confirmed in writing. See the boundary note below. | The partner plans a product experience the app layer cannot deliver, and discovers the gap at the first build rather than at the scope conversation. |
| 5. Verification & documentation | Joint — and the scoping rule is the partner’s to enforce | A documentation set that describes the configuration actually being built, with the applicable scope for each named model. | The document set is assembled at the end. The partner learns what is missing only when a market asks for it. |
| 6. Production ramp & handover | Joint — the manufacturing flow is ours; the market obligation is yours | A handover package a brand owner can act on, including what happens on the partner side after handover. | Nobody owns the outsourced steps explicitly, so accountability for a ramp problem is unclear exactly when it matters most. |
Two structural notes before the stages themselves. First, the platform decision: it is the one stage where a wrong sequence is nearly always unrecoverable, so it gets its own comparison table in section 3. Second, the manufacturing split: we build complete devices and most of that production is our own, but PCBA assembly is outsourced. That split is why the ramp stage below treats the outsourced-step question as something with a named owner rather than as a detail.
2. Stage 1 — Requirement Definition, Before Any Design Exists
This stage produces one page and removes most of the project’s risk. It is also the stage most often skipped, because it feels like writing down what everyone already knows. It is not: in practice, the people commissioning the product and the people who will build it rarely hold the same version of this page in their heads, and the difference does not show up until a prototype exists.
| Field | Why It Changes Everything Downstream |
|---|---|
| What is shown or measured, and on whom | The single field that eliminates the most candidates. It decides which sensor architecture is even relevant, and it decides which claims are available to you later. |
| How it is worn | Wrist or finger; round, rectangular or ring form; loose or snug. This creates structural requirements immediately — a pump-and-airbag architecture and a ring-form sensor shell have almost nothing in common structurally. |
| Which market it is for | Not a sales plan — a constraint. It decides which labelling, language and authorization questions arrive with the product, and those have to be anticipated in the design rather than attached afterwards. |
| What you intend to say publicly about it | The claim set, written before artwork exists. A claim that cannot be supported is not fixed by better copywriting; it is fixed by not designing the product that way. |
| Which configuration family it starts from | Starting from an existing family and starting from a blank page produce materially different projects. Deciding this early prevents a from-scratch budget being prepared for a programme that would have started from an existing platform. |
| Who on your side is authorized to decide | Named, in writing. Custom development stalls in the same place every time: a design or platform decision nobody on the partner side can make. |
The last field is the one buyers most often leave out, and it is the one that stalls projects. A development relationship needs a named decision owner on the partner side from the first week — someone authorized to settle form direction and platform trade-offs without escalating to a committee. Projects without one do not move more slowly; they move in the wrong direction more slowly, which is worse.
3. Stage 2 — Industrial and Structural Design
Industrial design and structural design are documented capability areas here, and they are also the stages where the partner’s ownership is most clear: the form language is your brand’s, not your supplier’s. What LUROGEF contributes at this stage is not a style, it is constraint — what the hardware, the sensor contact geometry, the strap or airbag arrangement and the enclosure can actually accommodate once the direction is chosen.
The practical consequence is that design direction and the platform decision are entangled, and the order matters. A form decided without knowing the platform produces a beautiful enclosure that cannot hold the architecture the product needs. A platform chosen without knowing the form produces an architecture that cannot fit the product the brand intended to make. The gate in section 5 exists precisely to force those two decisions into the right sequence.
4. Stage 3 — The Hardware and Firmware Platform Choice
This is the single most consequential decision in the project, and it is the one most often delegated or deferred. It should be neither. The platform decision is joint by necessity: the partner owns the requirement the platform has to satisfy, and LUROGEF owns the engineering trade-offs the platform imposes. Either party deciding alone is guessing at the other’s half.
| Aspect of the Platform Decision | What It Settles | |||
|---|---|---|---|---|
| What the decision settles | Which envelope class the product lives in — how much power budget exists, and therefore what the device can run continuously versus periodically. | Which sensor set is available to the product, and therefore what data the app can present and what the product can honestly be described as doing. | What connectivity model the product uses, and therefore what has to be present, paired and charged for data to move. | How much can still change after this point, which is the real cost of getting it wrong. |
| Why it is joint | The partner owns the requirement the platform must satisfy. LUROGEF owns the engineering trade-offs the platform imposes. Neither side can decide it alone without guessing at the other. | |||
| When it should be made | After the requirement frame is written, before industrial and structural design is frozen. A platform chosen before the requirement is a guess; a platform chosen after the enclosure exists is a redesign. | |||
| What it must not be decided on | Component names and headline numbers. A platform chosen because a specification line looked better is a platform chosen for the wrong reason — and the specification line belongs to the model page, not to the programme decision. | |||
| Where the quantitative detail lives | On the product hubs and the individual model pages. This guide deliberately publishes no part number, chip name, runtime value or price. |
The comparison is deliberately written as consequences rather than as a component table. A component table invites the reader to compare numbers that belong to specific models and that are documented on the product hubs — the blood pressure watches, smart rings and connected monitoring hubs and their model pages. What belongs to the programme rather than to a model is the consequence list above, because that is what the partner has to weigh.
| Chosen Too Early | Chosen At The Gate | Chosen Too Late |
|---|---|---|
| The platform is selected before the requirement frame exists, so it is selected against an assumed requirement. | The requirement frame is written first, the platform is chosen jointly against it, and the configuration record is frozen before design is closed. | The enclosure and structure are settled first, and the platform has to fit inside decisions it should have constrained. |
| Cost: the project may be built to the wrong envelope, and the mismatch appears as a product that cannot do what was intended. | Cost: one deliberate trade-off conversation, held while both directions are still open and changing them is cheap. | Cost: the platform becomes a redesign item, at the point where a redesign is the most expensive thing in the project. |
| Recoverable as soon as it is noticed — nothing irreversible exists yet. | This is the position the gate in section 1 is designed to produce. | Recoverable only by re-opening the design, which means the design work is repeated rather than corrected. |
5. Stage 4 — App and UI Customization
Documented capability here covers UI design, watch-face direction, independently developed mobile applications, app and software customization, wireless device/app data transfer, customer-app integration, and a cloud health platform with third-party service integration. That is a real scope — and it is exactly why this stage needs the boundary stated rather than the capability repeated.
| Layer | What Is Confirmed | What We Cannot Confirm Yet |
|---|---|---|
| Watch face & on-device UI | Confirmed capability area. UI design and watch-face direction sit inside the documented design scope. | The extent per surface — how far the interface treatment can go before it hits a platform limit — is not confirmed. |
| Companion app — screens & flows | Confirmed capability area. App and software customization, and independently developed mobile applications, are documented. | The ownership question is separate from the build question: who holds the store listing and the publisher identity is not settled in the source material, so treat it as open. |
| Software behaviour | Confirmed capability area. Wireless device/app data transfer and customer-app integration are documented. | Supported languages are not confirmed; do not plan a launch language set around an assumption. |
| Cloud / platform layer | Confirmed capability area. A cloud health platform with third-party service integration is documented. | Hosting location, data residency and retention defaults are not confirmed for this platform. |
| Hardware & enclosure direction | Confirmed capability area. Industrial design, structural design and hardware development are documented. | Which production steps in a specific flow are outsourced beyond the recorded split is not confirmed. |
The procedure this stage actually requires is short, and it is what turns an extent question into a confirmable one. Write four things down: what the interface must show, what the app must do, which languages must be supported, and who must own the listing. Then ask for each of the four in writing against the specific platform. A partner who receives that list will either confirm it item by item or produce the boundary — and either answer is more useful than a general assurance that everything can be customized, which no development scope can honestly support. The ownership question specifically is not confirmed, and it belongs on your side of the table even when we build the app — see the buyer-obligation guide for why.
6. Stage 5 — Verification and Documentation
This stage is where a project either produces something usable or produces a product with a paperwork problem attached. The failure pattern in this category is almost never a missing document. It is a genuine document read out of scope — a real record, correctly issued, treated as covering more than it does. Two rules prevent it: read the scope line, and read the holder, before repeating a document’s existence as reassurance.
| Document Category | The Question It Answers | The Question It Does Not Answer |
|---|---|---|
| Requirement record | What the product was required to be and do. It is the document every later stage is checked against. | It does not prove the product was built to it. That is what the verification records are for. |
| Design & drawing set | What the product physically is — form, structure, materials direction and the interfaces between parts. | It does not tell you which production steps are outsourced, or who is accountable at each. |
| Platform configuration record | Which hardware and firmware configuration was actually frozen and built. | It does not establish that the configuration is available for a future order indefinitely. |
| App build & release record | What software version shipped, and what it was able to present. | It does not establish who owns the store listing, the publisher identity or the update path. |
| Verification records applicable to the named model | Which declarations or verification records apply to which named model and which directive each one actually covers. | It does not establish authorization to place a product on any market, and it does not extend to a differently configured variant. |
| Packing & kit definition | What ships in the box, and which configuration that kit corresponds to. | It does not resolve the labelling and import obligations of the market the goods ship into — those are yours. |
The scope rule that matters most read this twice
A factory or process document is not a product authorization. A production licence and a quality-management certificate describe the environment a product comes out of, within a bounded scope — they are not authorization for a product to be placed on a market, and a bounded scope is a limitation rather than a formality. Red and RoHS declarations relate to named models and named directives only. None of these establishes medical-device approval anywhere, and no product on this site is claimed certified or registered in any market.
Certificate titles with the original documents unchanged are shown on the certifications page. What you must be able to produce after handover, and which duty each document discharges, is the subject of the buyer-obligation guide.
7. Stage 6 — Production Ramp and Handover
The ramp is where the design becomes shipped product and where the project boundary has to be drawn most carefully, because the boundary is not a single line. Ours falls like this: we assemble complete devices and most of that production is our own, but PCBA assembly is outsourced. That is the flow as it actually is, and it produces the single most useful question a buyer can ask any supplier in this category, us included:
“Which steps in this specific flow are outsourced, and who is accountable for each?”
The reason to ask it is not suspicion of outsourcing — it is that accountability has to be attached to a step rather than to a project. When a ramp problem appears at a step that nobody realized was outside the flow they thought they were buying, the conversation that follows is about who was responsible, and that conversation is much shorter if the answer was written down before the first run.
Production and assembly workshop. Facility and process scope is documented on the factory tour.
8. Six Ways This Project Fails, and Where It Is Still Cheap to Fix
These are not device failures. They are sequencing failures, which is why each one has a point before which the fix costs a conversation and after which it costs a programme.
| Failure Mode | What You Would Actually Observe | The Cheapest Recoverable Point |
|---|---|---|
| The requirement is written after design starts | The design review is filling in the fields the requirement record was supposed to contain. | Still cheap. Stop and write the frame. Nothing irreversible exists yet. |
| The platform is chosen before the requirement | The platform decision was justified by a specification line rather than by the field it has to satisfy. | Cheap before the enclosure design is frozen, expensive after. Re-open the platform question while the shape is still fluid. |
| The customization extent is assumed rather than confirmed | The product plan depends on an app behaviour or an interface treatment that no written scope covers. | Recoverable until the app build starts. Ask for the extent in writing against the specific platform while the surfaces are still open. |
| The document set is assembled at the end | The project has a product and is now looking for the paperwork that should have been produced alongside it. | Recoverable at any point, but the cost is that the partner discovers what is missing only when a market asks — which is the most expensive moment to find out. |
| Outsourced steps are discovered late | A ramp problem has appeared at a step nobody realized was outside the flow they thought they were buying. | Recoverable until the first production run. Ask which steps in *this specific* flow are outsourced, and who is accountable at each. |
| The schedule is taken from a verbal estimate | A date has been given to a customer, a distributor or an investor, and it was never written into the project. | Recoverable at any point, and this guide will not help you predict it: no schedule is published here because none exists to publish. Ask what the schedule is composed of — requirement closure, design freeze, platform freeze, app scope, verification, ramp — and get each dated in writing. |
9. The Number We Will Not Give You
At some point every reader of this page wants the same figure: how long does it take. We are not giving it to you, and the reason is not caution — we simply do not have a verified schedule to give. A timeline would be the easiest thing on this page to write and the most damaging thing to get wrong, because a date you pass to a distributor or an investor is a commitment. A commitment resting on our guess is worse for you than no date at all.
What is useful instead is the list of components your schedule is actually made of, and each one has an owner and a gate in the tables above: requirement closure (yours to drive), design direction agreed (yours), platform frozen (joint), customization scope confirmed in writing (joint), verification records produced (joint), and ramp and handover (joint, with the outsourced-step question answered). Ask for each of those to be dated in writing. The sum of those dates is your schedule — and it will be a schedule someone has actually committed to, which is a different object from a number on a marketing page.
The same holds for MOQ, tooling or setup charges, sample terms and price. Those are scoped against your configuration through the inquiry route, and the OEM & ODM overview lists them, along with everything else that is not confirmed, in one place.
10. What We Leave to You
Three boundaries belong to your side of the table, and they are not optional because we did not raise them.
- Your market obligations. Which markets you place the product on, and the authorization, labelling and import duties that apply in each, are yours. This guide describes the development process; it does not tell you what your product needs in order to be sold somewhere.
- Your claim set. No diagnosis, no guaranteed accuracy and no treatment outcome — and the product limits are absolute: the watch’s IP67 rating covers short-term shallow immersion only, with no swimming and no hot water; the ring is daily use only, excluding swimming, hot springs and prolonged submersion. In the connected glucose monitoring family, the S10 is a separate single-use adhesive upper-arm sensor, and a compatible watch and the app only display synchronized data — the watch itself does not measure glucose.
- Your end-customer relationship. The support obligation, the spares plan and the continuity arrangements that survive the project sit with the brand the customer bought from. The buyer-obligation guide sets out how to plan them before design freeze rather than after launch.
Where to go next
Return to the OEM & ODM overview for the capability scope, the responsibility split and the full list of what is not offered or not yet confirmed. Read the buyer-obligation guide for what stays yours once the product ships. Model and platform detail lives on the blood pressure watches, smart rings and connected monitoring hubs.
Frequently Asked Questions
Questions buyers usually need answered first
Practical answers about product selection, everyday use and planning your project.
Visit the FAQ pageWhat has to be written down before design starts?
One page, and it is not a specification. It answers: what the product shows or measures and on whom; how it is worn; which market it is intended for; what the brand owner intends to say about it publicly; and which configuration family it starts from. Every one of those fields either creates a design requirement or eliminates a candidate direction. The failure this prevents is specific: a design that starts before the requirement is written does not get corrected by editing a document later — it gets corrected by a redesign, and the redesign lands in the most expensive phase of the project.
Why does the hardware and firmware platform decision matter so much?
Because it is the cheapest decision to change and the most expensive one to have made wrongly. The platform bounds the power envelope class, the sensor set available, the display class, the connectivity model, what the app is able to present, and how much can still be changed later. Once an enclosure, a strap or airbag geometry, a sensor-contact geometry and a verification file exist, changing the platform is no longer a decision — it is a new project. That is why the choice is presented here as a comparison of consequences rather than of component names, and why every quantitative cell in that comparison is either owned by the model page or marked as unconfirmed.
How far can the app and interface actually be customized?
The documented reach is real: watch-face and UI design, app and software customization, and hardware customization are all confirmed capability areas. The extent is not confirmed — customization boundaries, supported languages and app publishing ownership are recorded open items. So the honest answer is a procedure rather than a promise: write down what the interface must show, what the app must do, which languages must be supported and who must own the listing, then ask for each of those four in writing against the specific platform. A partner who receives that list will either confirm it item by item or produce the boundary — and either answer is more useful than an assurance that everything can be customized, which no development scope can honestly support.
Where does the project end, and is everything in-house?
Not everything is in-house, and we would rather tell you that now than have you find out later. We build complete devices, and most of that production is our own — but PCBA assembly is outsourced. That means the boundary has to be drawn step by step rather than project by project: which steps happen under our roof, who is accountable if a ramp problem shows up at an outsourced step, and what you need in writing at handover. It is also why the ramp stage below treats the outsourced-step question as something with a named owner — “we will sort it out” is not an accountability model.
What happens if our requirements change after sample approval?
Record the requested change and assess its effects on hardware, firmware, tooling, testing and packaging. Update the specification and acceptance criteria, then approve a revised sample before applying the change to production.