"You shall abide by the laws of the People's Republic of China." You are contractually subject to Chinese law. Any dispute with Tuya — pricing changes, account termination, IP — falls under PRC jurisdiction. Standard for Chinese platforms, but relevant if Tuya ever changes pricing aggressively or terminates your account.
"Users must assume full responsibilities according to laws for any information they provide." Every item that flows through Tuya's cloud — location data, emergency contacts, SOS events, user PII — is your legal responsibility, not Tuya's. For a personal safety app, this is significant GDPR exposure at commercial scale.
"Tuya does not take any responsibility for your use of and purpose of using Tuya services." If Tuya's platform goes down during a real SOS emergency and a user is harmed, you have no recourse against Tuya. This liability gap needs addressing in Aaron's own Terms of Service to his users before launch.
Cannot use "Tuya", "Tuya Smart" or any Tuya branding without written authorisation. Aaron's app must be presented purely under his own brand. This is what we want anyway — just confirm with Tuya sales if the OEM App route is ever explored.
"Tuya reserves the right to: Suspend or terminate device access and service support. Ban developer accounts. Block non-compliant capability calls. Report to regulatory authorities." This is the single biggest operational risk for a personal safety product. If Tuya pulls the account, every user's alarm stops working — potentially mid-emergency — with no notice and no recourse under PRC law.
Mitigation: Acceptable for Phase 1 MVP. Before commercial launch, build a contingency: either an offline fallback mode, or a firm migration roadmap to open-SDK nRF52 hardware that doesn't depend on Tuya's cloud staying available.
Aaron discussed a codeword/keyword to silently activate SOS. The Compliance Guide classifies voiceprint data as biometric sensitive personal information with strict requirements:
• Must be disabled by default — cannot ship enabled
• Requires separate, explicit consent — cannot be bundled into general T&Cs
• Cannot be used for model training or profiling without separate disclosure
• Must be deleted irreversibly when user cancels or withdraws consent
• If any user under 16: guardian consent required before voiceprint enabled
This doesn't kill the feature — it means the consent flow must be built correctly from day one. Flag to the developer before Phase 2.
"Developers have the obligation to continuously monitor and comply with the latest legal and regulatory requirements of the target market." Tuya puts the entire regulatory burden on you. All device data routes through Tuya's cloud infrastructure in China — location, emergency contacts, SOS event logs stored offshore. For UK/EU users this is a live GDPR exposure. ICO registration not required for Phase 1 (non-commercial, under 100 users) but must be resolved before any commercial launch.
"If the intelligent agent can control smart devices, accidental triggering may lead to safety risks. Developers need to add confirmation mechanism protection logic." This aligns with Aaron's existing requirement — the B500 requires a 2–3 second hold. The Compliance Guide formalises it as a legal requirement, not just good UX. Document the confirmation mechanism explicitly in the technical spec.
If the app ever adds AI features (safety route suggestions, risk area detection, contextual alerts), the guide prohibits "providing professional advice requiring specific qualifications without special warnings." Add disclaimers for any automated guidance. Not relevant for Phase 1 basic SDK integration.
The guide specifically prohibits "inferring personal emotions in workplaces or educational institutions." If Aaron targets the lone worker or enterprise market with any AI monitoring features, this needs legal review. Not relevant for Phase 1 consumer MVP.
| Risk | Level | Phase 1 MVP | Before Commercial Launch |
|---|---|---|---|
| Tuya account termination without notice | Critical | Accept risk — MVP scale | Build offline fallback or migration plan to nRF52 |
| PRC law jurisdiction | Critical | Accept risk | Legal advice if any IP dispute or contract issue arises |
| All data liability falls on you | Critical | Low impact — non-commercial, no real users | GDPR legal opinion needed; data processor agreements |
| GDPR — Chinese data routing | Critical | ICO registration not required | Must get legal opinion; may need EU data residency |
| Voiceprint keyword trigger = biometric data | Critical | Do not implement in Phase 1 | Build correct consent flow before shipping the feature |
| No Tuya liability for outages | Amber | Note it | Address in Aaron's own T&Cs to users; consider SLA monitoring |
| Accidental trigger confirmation | Amber | Already handled by B500 hold mechanism | Document formally in technical spec |
| AI advice restrictions | Note | Not applicable Phase 1 | Add disclaimers if any AI guidance features built |
| Lone worker / emotion inference prohibition | Note | Not applicable Phase 1 | Legal review if enterprise market targeted with AI features |
Discovered during platform registration. Tuya's own open-source firmware framework, described as "compatible with multiple chips and mainstream LLMs" — not just Tuya-locked SoCs.
Why this matters: Previously the plan assumed a binary choice — stay on Tuya (cloud-locked, GDPR risk) or spend £10–25k migrating to custom nRF52 hardware. TuyaOpen could be a middle path:
Action for Phase 1: Check the GitHub repo to confirm which chips are actually supported. If only Tuya's own ESP32-based modules, the "multi-chip" claim is marketing. If it includes Nordic or other open BLE chips, this materially changes Stage 2 hardware economics.