Frequently
asked questions.

We offer three levels of customization:

Process: Requirement consultation → Proposal & quotation → R&D → Client confirmation → Mass production delivery.

• Light customization: Minor adjustments based on existing models, such as packaging print, Bluetooth name, app theme, watch faces/languages, case/strap laser print/silkscreen, and metal/plastic finishes and colors. Suitable for newcomers who need fast time-to-market.
• Mid-level customization: After NDA, clients propose specific features. We assess feasibility and provide corresponding hardware and ID solutions. Suitable for clients with some experience looking to upgrade based on market feedback.
• Full customization: End-to-end development from ID design, hardware, firmware, app, to cloud deployment. Suitable for established brands with sufficient budget and market research; longer development cycle.

Our quotation can include the following (items vary per project):
1. Unit price and BOM cost.
2. R&D fees: hardware design, firmware/software, ID design, etc.
3. Production fixtures and mold costs.
4. Sample and reliability testing fees.
5. Certification costs for target markets.
6. Logistics and packaging costs (terms vary, e.g., FOB).
7. After-sales service and warranty.
Larger orders get lower unit pricing and more complete OEM/ODM services; smaller batches can lower order quantity by negotiation but at higher unit prices.

Start with the target market and selected product. We can discuss the engineering documents, testing work and application responsibilities needed for that scope.

Confirm the applicable reports, labels and documents against the named model, configuration and responsible applicant. Available evidence is reviewed for the specific project.

Quality planning starts with agreed product requirements and sample acceptance criteria.

The plan can cover design verification, production checks, test records and issue feedback for the selected product. Required processes and documentation are identified in the project scope.

Review the applicable evidence and responsibilities before confirming production acceptance.

After-sales scope can include issue triage, repair or replacement arrangements, spare parts and technical support, as agreed for the selected product.

Response targets, warranty coverage, remedies and service limits are recorded in the commercial agreement and reviewed for the target market.

Firmware and app update work can be evaluated within the project scope. Agree supported versions, release responsibilities, defect prioritization, response targets and acceptance criteria rather than assuming one update schedule for every product.

Use the inquiry form or email to share the product direction, budget assumptions and desired timing. Confidentiality arrangements, points of contact and project responsibilities can then be agreed for the proposed work.

The delivery plan should identify requirements, sample availability, component dependencies, design and test milestones, acceptance criteria and production responsibilities. Indicative timing is confirmed after scope review and updated when assumptions change.

Ownership, licences, confidentiality and handover materials are defined in the project agreement. Newly commissioned work, reused platforms and third-party components may have different rights; specify what is included instead of assuming unrestricted ownership.

Lifecycle support can be planned for the selected hardware and software configuration.

Update responsibilities, supported versions, maintenance work and improvement requests should be recorded in the agreed scope.

Discuss target-market material requirements and the available documentation for the selected product and packaging. Recyclable or biodegradable options depend on the specific material and design; confirm the proposed option in the quotation.

Yes. We provide end-to-end solutions from Bluetooth protocol to app UI to cloud storage, with branding customization; we can also integrate with your systems via API.

Testing and documentation timing depends on the product, applicable requirements, sample readiness, laboratory scheduling and any design changes. Engineering support and responsibilities can be discussed within the agreed scope; there is no universal certificate or lead-time promise.

Capacity planning depends on the selected design, material availability, tooling, forecasts and production readiness. Share quantity scenarios so the proposed manufacturing and ramp-up plan can be reviewed before a delivery commitment is made.

Privacy and security requirements can be evaluated for the target market and project scope. The assessment should identify data flows, permissions, service responsibilities, required controls and verification work. Any implementation or compliance statement depends on that documented scope and its supporting evidence.

Bank transfer and wire are accepted; USD is typical, other currencies negotiable. Common terms: deposit + balance (deposit to start; balance after sample confirmation and mass production arrangements).

Identify the required interface, manual, firmware and app languages for the target users.

Translation, localisation review, accessibility, language support and service costs are agreed for the selected software and project scope.

Ask which reference materials may be shared for your project. Availability and permissions are checked case by case; useful comparisons describe the scope, configuration and acceptance evidence without disclosing third-party confidential information.

Extended support, warranty coverage or maintenance services can be discussed for the selected product. The agreement should specify the proposed coverage, duration, exclusions, responsibilities and market-specific requirements.

Third-party integration can be evaluated through the interfaces available for the selected product and software scope.

SDK: confirm the available package, functions, versions, licences and documentation for the required workflow.

API: define endpoints, data fields, access permissions, versioning and test environments before agreeing an integration.

Bluetooth protocol: confirm the specific device protocol, documentation rights and supported behaviour needed by the companion app.

Cloud integration: identify service ownership, accounts, data flows, operating costs and responsibilities for the proposed connection.

Health data supports general-wellness reference. Privacy and security requirements need evaluation for the target market, data flow and agreed project scope.

Yes. QX also supports independent software development projects. For an initial discussion, describe the users, target platforms, core workflows, existing systems and interfaces, and what you expect to receive. Firmware, a companion app, API integration and independent software are different work packages; the agreed scope, acceptance criteria, maintenance and rights should be recorded for your project.

Start with the intended use, product form factor, target markets, essential functions and current project stage. Say whether you want to adapt a reference platform or develop a new design, and describe the software and integration scope. Include indicative volumes, your desired launch window and any existing requirements or designs. Separate must-have items from preferences and assumptions; unknown details can remain open for evaluation. Do not send passwords, medical records or other sensitive information through the inquiry form.

Ask each supplier to separate one-time development, tooling, samples and validation from production unit costs, packaging, software or platform fees, and ongoing support. Compare the same configuration, volume assumptions, included tests and deliverables. Identify exclusions, dependencies, payment milestones and who is responsible for market-specific documentation. A low unit price alone does not describe the total project cost; order quantity, pricing and timing need a project-specific quotation.

List the device or system interfaces, supported platforms, data flows, required documentation and test environments. Define acceptance tests for the agreed workflows and how changes, releases and maintenance will be handled. Record which SDKs, source code, protocol documents, credentials and handover materials are included, together with applicable ownership and licence terms. Third-party components and existing platforms can have separate conditions; the project agreement should identify them rather than assume unrestricted access.