On small screens, scroll tables sideways to read every column. With a keyboard, focus the table and use the arrow keys.
Start with the user task
Write the job in terms of an action and a result: a worker captures an inspection image, a wearer reads a short prompt, or a user makes a call in a defined environment. Then identify the information the application needs and the conditions in which the task must succeed. “AI glasses” is a product category, not an acceptance specification.
Separate inputs, outputs and processing. A camera task may need a still image, a stored recording or a live stream; those are different integration requests. A display task may need text and icons rather than a spatial interface. Identify what runs on the glasses, in a phone application and in a connected service before choosing a platform.
Use the solution selection guide to prepare this first decision. A promising demonstration is a reason to investigate the configuration, not evidence that every required interface or operating condition is covered.
Choose the engagement scope
A standard-platform purchase or branding project starts from an existing configuration. Confirm which logo, colour, packaging or accessory changes are included and which changes trigger engineering work. Standard OEM purchasing does not automatically require a new hardware development programme, source-code licence or paid software modification.
Custom ODM starts with changes that need feasibility, engineering and configuration-specific validation. JDM or a technology-transfer engagement adds separately agreed work-sharing or handover obligations. A label alone does not allocate design ownership, implementation responsibility, intellectual-property rights or support.
| Cost or workstream | Ask what is included | Confirm separately |
|---|---|---|
| Evaluation hardware | Model, build, accessories, evaluation purpose and any agreed support. | Ownership, return conditions, sample quantity, shipment, taxes and a route to report failures. |
| NRE / engineering | Requirements, design changes, firmware or SDK modifications, integration and validation tasks. | Deliverables, excluded features, change requests, acceptance and payment milestones. |
| Tooling and fixtures | Which moulds, assembly fixtures and test fixtures are needed for the agreed design. | Ownership, maintenance, storage, replacement, transfer and configuration changes. |
| Production | Released configuration, included accessories, assembly, inspection and packaging. | Quantity assumptions, component changes, inspection records, logistics and taxes. |
| Certification and licences | Named model, market, test scope and third-party software or service rights. | Applicant, test owner, fees, exclusions and whether a changed build needs new evidence. |
| Maintenance and support | Firmware, application and cloud owners; supported builds; defect handling. | Update period, compatibility work, service charges, spare parts and end-of-support arrangements. |
These are quotation questions, not a universal fee schedule. Hardware unit price, development services and recurring application or cloud costs should remain separate. The C100 software policy, for example, distinguishes the free unchanged standard Android SDK / Demo from paid modifications; its development-service fee is not a hardware sample price.
Separate product stage from customization scope
A production platform can still require project-specific integration and validation. Conversely, a functional engineering prototype can prove an important task without proving the final industrial design, production process or delivery configuration. Record both the platform stage and the changes your project introduces.
SmartXY currently presents K900, AR99 and AR99 MY as production platforms. AR99 Pro and C100 are EVT3 functional prototypes. Those labels do not transfer specifications, software interfaces or release evidence between products. Historical project references and ODM directions are separate from standard products.
Commercial availability and delivery terms depend on the agreed configuration and project scope. Ask which reference build your sample represents, what differs from the intended delivery build, and which open issues must close before the next decision.
Define software and service ownership
Identify the owner of each layer: device firmware, SDK, phone application, Android application where applicable, AI endpoint, account system, data storage and updates. Name the party that will diagnose a failure crossing two layers. “SDK included” is incomplete unless the package version, supported build, licence and support boundary are identified.
For a phone-assisted workflow, confirm phone OS compatibility, connection management and who operates the application. For a direct-network workflow, confirm network authentication, recovery and service access. An application running on glasses does not establish that model inference also runs there. Review the SDK integration checklist before committing to unsupported interface assumptions.
Agree the information that can be collected, who can access it, and where it will be processed. Business, technical and data-permission owners may be different people. Record their responsibilities in the project scope rather than leaving them implicit in a hardware quotation.
Agree evidence at each gate
Use development stages as decisions supported by records. For an existing standard product, select the gates that apply to your configuration; do not impose a new-platform development programme on unchanged purchasing. The table below is a cooperation framework, not a claim that every SmartXY platform has passed every gate.
| Stage | Decision | Evidence to agree |
|---|---|---|
| Requirements | What exactly are we building? | User task, configuration, owners and acceptance targets. |
| Engineering validation | Does the chosen architecture perform the key task? | Identified prototype, interface results and unresolved risks. |
| Design validation | Does the intended design meet the agreed conditions? | Configuration-specific test and reliability evidence. |
| Production validation | Can the process repeat the accepted result? | Pilot-build records, inspection methods and traceability. |
| Production release | Is this configuration ready for agreed delivery? | Release criteria, change control and support arrangements. |
Keep receipt of a design file, implementation of a change, completion of a test and customer acceptance as separate statuses. A useful release record identifies the approved version, change history, test summary, unresolved limitations and sign-off owner. See the ODM delivery checklist for a blank planning template.
Prepare the project brief
The following ten items give a supplier enough context to assess platform fit and identify the questions that affect architecture, cost and timing. Unknowns can be marked for evaluation; do not replace them with assumed support.
- User and task: who wears the product, what they do, and the result that matters.
- Environment: location, lighting, noise, motion, weather exposure and relevant work restrictions.
- Platform and stage: preferred model or reference configuration, and whether a prototype is acceptable.
- Inputs and outputs: camera, microphone, audio, display, controls and prescription or accessory needs.
- Interfaces: required data, commands, events, timing and evidence needed from the selected build.
- System responsibilities: your application, phone, cloud, identity, storage and device-management owners.
- Markets and permissions: intended countries, deployment rules, certification questions and data access.
- Volume and route to market: evaluation quantity, expected production demand and channel or deployment plan.
- Commercial scope: standard purchasing versus development, budget readiness and included workstreams.
- Acceptance and timing: measurable task criteria, open risks, review owner and target milestones.
Request a written scope that answers those points and identifies exclusions. Compare proposals against the same brief. A lower sample price does not resolve an undefined SDK dependency, an unowned cloud service or a missing acceptance condition.
Questions buyers ask
Does a production platform make my custom version production-ready?
No. It provides an existing platform baseline. Changes to hardware, firmware, accessories, markets or use conditions need the evidence and release decision agreed for your configuration.
Is NRE included in the hardware unit price?
Only the quotation can establish that. Ask for hardware, engineering, tooling, third-party licences, certification and recurring support to be identified separately, including exclusions.
Do standard OEM buyers need a new development programme?
Not automatically. An unchanged platform purchase or agreed branding scope can follow the applicable purchasing and configuration review. Additional development is scoped only where needed.
Can the project start from a historical product reference?
A historical reference can help describe the intended workflow. It is not evidence that the original system is available as a standard export product or for immediate sample dispatch. Define a new development scope.
Sources and scope
This is SmartXY's buyer-planning guidance. Platform statements refer to the linked public pages and their stated conditions; they are not independent test certification. Requirements, proposed tests and blank templates are not completed project evidence. Configuration-specific facts and current package availability must be confirmed for the project.
Define your next evaluation
Share the intended task, preferred platform and the decisions your team needs evidence to make. Product access, engineering work, pricing and delivery remain subject to the agreed configuration and commercial scope.