SmartXY supports established brands, strong channel partners and funded enterprise teams. Select a current standard model for OEM branding and packaging, or scope an ODM customization project. Align the purchasing or development budget, order plan and responsibilities with the chosen route.
GLOBAL AI EYEWEAR DEVELOPMENT PARTNER
Explore three eyewear platforms, the engineering and reliability workflow, four SDK integration layers and the Premium ODM Development Program for highly customized products.
Explore Custom AI Eyewear DevelopmentStandard-platform OEM purchasing and existing SDK policies retain their own project scope.
Choose standard-model OEM for an agreed product with your branding, or ODM for a defined customization project. JDM and technology transfer add deeper engineering or capability handover when the business requires it.
Select a current SmartXY model and agree your logo, packaging, product configuration and purchase plan. Any requested software or hardware changes are reviewed separately.
Start from an agreed SmartXY platform, then scope POC, PRD, ID/CMF, CNC Function Prototype, UI, firmware protocol/app, regional certification, and packaging.
Co-engineer a differentiated product on a SmartXY base platform — hardware options, chips, optics, firmware/app scope and regional compliance defined per project.
For qualified partners investing in an engineering team or local manufacturing. Scope authorized source, design, process and test documentation with training and staged acceptance.
When the customer controls the design, begin with authorized drawings, BOM, revision history, manufacturing rights and acceptance requirements. Review manufacturability, supply responsibility, test fixtures and change control before agreeing a build-to-print scope. A standard-platform branding request does not automatically include customer-design manufacturing, engineering changes or source rights.
A sample evaluates a named hardware, firmware and software configuration against your workflow. It does not establish production readiness or include every interface, source right or customization.
Choose the platform and required task. Confirm sample availability, build versions, included SDK/App, accessories and known limitations. For a current standard configuration, a business owner can lead the request; engineering ownership is needed for changes.
Record the sample quantity, separate hardware and software charges, delivery contents, support scope and test plan before ordering. Confirm any loan, return or replacement terms in the quotation; no common policy is assumed.
Record test conditions, results and open issues. Both teams decide whether to use the standard configuration, commission defined engineering work or stop the evaluation. Pilot and production commitments require their own agreement.
| Cost category | Confirm in the proposal | Responsibility to agree |
|---|---|---|
| Hardware samples | Build, quantity, accessories, included tests and sample terms | Buyer approves the evaluation configuration; supplier identifies what ships. |
| Engineering / NRE | Specific hardware, firmware, SDK or App changes, milestones and acceptance | Named technical owners approve the statement of work and change requests. |
| Molds, tooling and fixtures | Design, ownership, maintenance, validation and any reuse limits | Agree funding, custody and release conditions by item. |
| Certification and testing | Model, version, market, test scope and retest assumptions | Confirm applicant, laboratory coordination and who funds changes. |
| Third-party licenses | Component, SDK, codec or service rights and recurring charges | Identify license holder, permitted use and renewal owner. |
| App and cloud services | App delivery, accounts, model/API usage, hosting, updates and support | Customer-operated services and separately commissioned supplier work are listed distinctly. |
| Production units | Approved configuration, order volume, packaging, inspection and spare parts | Agree order acceptance, quality release and after-sales responsibilities. |
| Logistics and taxes | Shipping basis, insurance, import duties, taxes and local handling | Confirm importer, carrier arrangement and payer in the commercial terms. |
The C100 standard Android SDK policy remains separate from sample hardware and paid SDK modifications. Any published minimum development fee applies only to its named service and scope, not every SDK request or hardware purchase. A previous customer budget is not a universal fee schedule.
Request C100 standard SDK · Evaluate a K900 sample · Discuss AR99 branding · Scope custom development
SmartXY has undertaken customer ODM projects using K900 and EG01 as starting platforms. This experience can help your team reduce repeated exploration, trial and error, and the hidden costs of bringing a new smart-glasses product to life.
K900-based brain–computer interface (BCI) integration for a customer ODM project.
EG01-based audio glasses developed through ODM for people with hearing loss.
K900-based ODM work adding a temperature sensor alongside blood-oxygen and heart-rate monitoring.
Build on prior integration experience to identify requirements earlier and focus engineering effort on what is specific to your product. The aim is less repeated work and a clearer development plan.
Customer project features are scoped separately from standard platform specifications. Reuse, software rights, validation, NRE and timelines are agreed for each new project.
Find the project-fit notes and RFQ requirements for your product category, branding model or target channel.
To compare practical changes, responsibilities and delivery boundaries, read Vanda’s personal OEM, ODM and JDM guide.
Apply the development stages below to the agreed customization scope. Standard-model OEM follows its branding, configuration, validation and order plan without requiring a new product-development project.
Market scope, specs, ID/CMF, certification, budget and launch schedule.
Chipset, OS, power, camera/audio, optics, SDK/API and OTA plan.
ID, mechanics, electronics, firmware, app and algorithm interfaces.
CNC, 3D print, PCB/FPC samples, dev boards and interaction validation.
Functional, DFM, optical, electronic, acoustic, thermal and reliability validation.
Trial build, process validation, yield metrics, reliability reports and certification.
Yield ramp, agreed traceability records, QC plan, packaging, logistics and lifecycle responsibilities.
The development activities above need explicit decisions, identified builds and an acceptance owner. This is a planning framework, not a statement that a platform has passed every gate. Standard-platform procurement follows the agreed configuration and order plan; it does not require a new development programme from the beginning.
| Stage | Decision | Evidence to agree | Condition for the next stage |
|---|---|---|---|
| Requirements | What exactly are we building? | User task, configuration, owners and acceptance targets | Both teams agree scope, responsibilities and the evaluation plan. |
| Engineering validation (EVT) | Does the chosen architecture perform the key task? | Identified prototype, interface results and unresolved risks | The key task is demonstrated on the named build; open risks have owners and an agreed disposition. |
| Design validation (DVT) | Does the intended design meet the agreed conditions? | Configuration-specific test and reliability evidence | The intended design meets the agreed criteria or documented exceptions are accepted by the responsible authority. |
| Production validation (PVT) | Can the process repeat the accepted result? | Pilot-build records, inspection methods and traceability | The agreed production process and inspection evidence support the planned build. |
| Production release | Is this configuration ready for agreed delivery? | Release criteria, change control and support arrangements | The designated acceptance owners authorize the identified configuration and delivery scope. |
Record the result, open issues, evidence location and acceptance owner in the blank delivery checklist. Timing, test limits and commercial commitments are agreed per project. Use the ODM manufacturing guide to prepare your brief.
Copy this blank checklist for the agreed phase. Every item starts unfilled; it is not a completed quality record, a certification or evidence of customer acceptance. Scope, owners and acceptance limits must be agreed before a gate review.
Project / platform: ______ Stage (EVT / DVT / PVT): ______ Review date: ______
Hardware / firmware / SDK / App versions: ______
Supplier owner / customer owner / acceptance authority: ______
| Deliverable | Artifact / revision | Owner / due date | Acceptance condition |
|---|---|---|---|
| Version baseline, drawings / CAD and BOM | To fill: ______ | To fill: ______ | To agree: ______ |
| Change log and implementation evidence | To fill: ______ | To fill: ______ | To agree: ______ |
| Test plan, conditions and result summary | To fill: ______ | To fill: ______ | To agree: ______ |
| Defect list, closure evidence and open exceptions | To fill: ______ | To fill: ______ | To agree: ______ |
| Gate decision and customer acceptance record | To fill: ______ | To fill: ______ | To agree: ______ |
| Packaging, labels, accessories and shipping configuration | To fill: ______ | To fill: ______ | To agree: ______ |
Record pending, complete or not applicable with evidence and an owner; record test outcomes explicitly. Receiving CAD does not show implementation; implementation does not show a passed test; a passed test does not show customer acceptance.
EVT: agree functional and interface evidence on the named prototype. DVT: agree design and reliability evidence for the intended conditions. PVT: agree process, inspection and shipment-configuration evidence on the pilot build.
For every phase, fill measurable pass criteria, open defects, approved exceptions and next-step owners. Only the authorized customer representative can complete the customer-acceptance state. This public template contains no customer files or test results.
For Embodied AI Data Capture Glasses, the XY-DC Reference Architecture defines a display-free ODM evaluation direction. Begin with the dataset workflow and engineering acceptance criteria, then agree feasibility, prototypes and validation milestones. Tooling, calibration-station design and production-line integration are scoped per project.
Evaluate rigidly mounted forward stereo cameras, sensor-level trigger alignment and the ISP/MIPI integration path. Define how frame timestamps and inertial samples relate to the capture clock. Document the sensor and host interfaces, then measure synchronization error and timestamp behavior on the agreed prototype.
Define intrinsics, extrinsics, distortion and rectification outputs, serial-number association and machine-readable delivery. Scope the calibration station, tooling and line integration as project work. Agree calibration procedures, output formats, acceptance criteria and repeatability checks before committing production delivery.
Evaluate wrist, body-worn or tool-mounted companion capture modules as separate development items. Define the relationship between head-unit and companion clocks, reconnection behavior and cumulative drift. Measure alignment and drift across the intended recording duration and wireless conditions; no synchronization accuracy is published.
Model concurrent camera capture, encoding, storage and periodic upload against the requested working-shift duty cycle. Review battery architecture, heat paths, fit and the resulting weight budget together. Validate recording duration and thermal behavior under the agreed workload and environment before confirming device specifications.
Evaluate an externally visible mechanical camera shutter and a mechanical microphone mute. Define how each control changes capture state and how the wearer and people nearby can verify that state. Review the physical controls and capture-state behavior alongside the project owner's consent, retention and intended-use requirements; hardware alone does not establish deployment compliance.
Evaluate secure-element signing at capture, key ownership, controlled provisioning and verification by the receiving system. Include relevant cryptographic and intended-use review in project definition. Agree the threat model and recording-integrity checks, then validate the signing and verification path on the selected hardware and software.
The XY-DC Reference Architecture is separate from existing camera and display products. Component selection, sample scope, quantities, commercial terms, development schedule and acceptance evidence are agreed per project. No fixed runtime, calibration accuracy or standard secure-element capability is published.
SmartXY uses an IPD-inspired lifecycle adapted for lightweight, high-speed smart-eyewear projects. Each phase has entry/exit criteria — when criteria are not met, the project does not move forward blindly.
Cross-domain co-initiation across acoustics, optics, electronics, software, hardware, structure and supply chain.
High-frequency prototype iteration with DFM embedded before design lock.
EVT, DVT and PVT gates establish KCP controls to pre-identify and mitigate risks.
Trial-production review, yield ramp-up, test-tooling finalization and MP execution.
For strategic projects, the most important deliverable is a traceable decision system that lets both teams see risks early and close issues fast.
Requirement intake, solution design, key-device selection, development and testing validation are fully visible.
Customer participation in architecture, interface definition, BOM decisions and optical/HW/SW routing.
Drawings, documentation templates, code specs, material control, version management and test standards.
A dedicated PM and technical lead per project to reduce cross-department communication overhead.
Progress visibility, risk controllability, clear accountability and traceable milestones.
Decisions, risks and versions visible end-to-end — the core of low-risk co-development.
Daily development plans, weekly project sync, technical review, monthly retrospective, code review, release review and version change logs with impact scope, timing and rollback strategy.
Requirements → proposal → design → test → MP review with full-process documentation and version control.
NDA, software copyright and IP-ownership agreements define cooperation boundaries before deep development.
Role-based access control, permission hierarchy and immediate revocation upon personnel departure.
Dedicated code repository per client project with strict isolation from other projects.
Independent development, testing and delivery/release environments.
Agree the delivery format for each component: documented API, binary, authorized source or a continuity arrangement. Third-party rights and signing-key ownership remain explicit.
Logging of code access, download, commit and artifact transfer for a complete audit trail.
Define data minimization, least-privilege access and the processing location for sensitive data according to the selected platform and application.
Define cost, order, procurement, inventory and quality records required for the agreed project.
Agree the BOM revision, material records, inspection evidence, warehousing records and reporting owners.
Define serial or lot identifiers, required process parameters and error-proofing evidence; confirm implementation on the selected line.
If system integration is required, agree the data fields, access, owner and validation. Availability and deployment status need project-specific confirmation.
Timeline depends on optical complexity, certification scope, tooling, firmware/app/cloud integration and requirement-change discipline. The earlier requirements are frozen, the lower the downstream cost and schedule risk.
| Stage | Key output |
|---|---|
| ID design | Concept, 3D, CMF and wearing experience |
| Mechanical structure | Stack-up, hinge, IP-rating strategy and ergonomics |
| HW + SW development | Schematic, drivers, app, SDK/API and OTA |
| Prototype & validation | CNC, 3D print, tooling validation and reliability tests |
| Manufacturing release | SMT, assembly, QC, PVT, yield ramp-up and MP release |
Share your channel or deployment plan, purchasing or project budget, expected volume and business owner. Choose standard-model OEM or ODM customization; technical ownership is needed for a development scope. Personal purchases, price-only one-off sourcing and development without a budget are outside this enterprise service.