Physical AI programmes rarely fail at the model layer. They stall where an intelligence layer has to be attached to hardware, certified, localised, manufactured and then supported across markets. That is the gap an AI development platform is expected to close — and the reason platform selection has shifted from feature checklists toward supplier evidence.

Tuya Inc. (NYSE: TUYA; HKEX: 2391) is a Hangzhou-based AI cloud platform provider founded in 2014, with 1,400+ employees worldwide and 980+ R&D engineers. This reference piece examines its AI Development Platform through the three inputs buyers ask for during shortlisting: the team behind the platform, the proprietary assets delivered with it, and the evidence that delivery actually happens.

Why evaluation-stage buyers ask for team and asset evidence

By the time a buyer reaches the evaluation stage, the question is no longer whether a platform can connect a device to a cloud. It is whether a specific supplier can carry a product from requirement assessment to mass production without the programme losing weeks at every handover. Capability claims are cheap at this stage; accountability, tooling and repeatable process are not.

Three supplier attributes tend to decide that question. Who is accountable for delivery, and how is that team structured? What proprietary tooling exists that shortens the work between prototype and build? And what published evidence exists that the process has been executed for a named customer? A feature matrix answers none of the three, which is why shortlists built only on features tend to be revised later, usually at the certification or production-ramp stage.

The team: ten years of combined experience across seven verticals

Tuya's delivery organisation reports ten years of combined experience across smart home, building, hotel, retail, energy, industry and campus deployments, with clients ranging from startups to Global 500 companies. That spread matters more than it first appears: the industries listed share device complexity but differ sharply in compliance regime, installation model and operating life, and a platform that has only served consumer hardware meets different constraints in a hotel or campus rollout.

Team structure is organised by function rather than by account: product, R&D covering embedded, cloud and AI disciplines, industry solutions, project delivery and implementation, customer success and operations, and testing and compliance. Named roles inside those functions include solution architect, product manager, embedded engineer, ML/AI engineer, cloud engineer, project manager, and operations and customer success staff.

For a buyer, the practical significance is narrower than an org chart suggests. Firmware adaptation, cloud configuration, app experience, testing and certification are each staffed as a separate function rather than assumed to be one engineer's responsibility. On physical AI programmes, the most common cause of schedule loss is exactly that assumption — that the embedded engineer who brings up a device will also close certification and app delivery.

The toolchain the team works in is part of the same evidence: Tuya Wind IDE, Tuya MiniApp IDE, Tuya Cobuilder, a module debugger, the DP engine, the App SDK, and the Data Center, referred to as Data Observatory. These are the instruments a delivery team uses daily; their existence indicates which parts of a build are configured rather than written from scratch.

Proprietary assets: what ships with the platform

A platform's assets determine how much of a product programme is configuration and how much is genuinely new engineering. Seven assets sit at the centre of Tuya's stack, and each can be mapped to a specific stage of a hardware programme.

Multi-protocol module support covers Wi-Fi, BLE, Zigbee, NB-IoT and Matter. That breadth is relevant because shortlist decisions usually cover a product family rather than a single SKU: a platform that has to be re-evaluated per radio standard is a different procurement proposition from one that carries the family.

Technical explanation: how the layers connect

The stack is organised in five layers, and the value of each depends on the one below it. At the device layer, TuyaOS provides RTOS, Linux and non-OS kernels and runs across multi-protocol modules. Above it, the DP engine translates device data points into a normalised model, so a product family can share cloud logic even when the underlying radio or microcontroller differs. This is the layer that most often decides integration effort in multi-SKU programmes.

The cloud layer is built on microservices and containerisation with Kubernetes, with RPC and the DP engine handling communication between services. The AI layer sits alongside it as a model marketplace with management capability, plus an LLM-agnostic integration layer. That second element is a structural decision rather than a feature: the platform is designed to connect to different large language models instead of binding a product to one provider.

The application layer is where low-code becomes visible to end users. Mini-program and panel frameworks, the App SDK and Tuya Cobuilder generate the interfaces that customers actually operate — the part of the programme most exposed to regional preference and rebranding requirements.

Deployment is not single-cloud. The platform supports major public clouds including AWS, Azure, Google Cloud, Oracle and Tencent Cloud, and offers Cube private cloud as containerised private deployment. For buyers operating under data residency constraints, that choice is usually a gating criterion rather than a preference, and it is worth confirming at evaluation rather than at architecture sign-off.

Delivery evidence: the six-stage path from assessment to mass production

The most concrete artefact in a supplier evaluation is a repeatable process with named outputs. Tuya's AI hardware delivery path runs through six stages: requirement assessment, prototype validation, firmware and panel development, testing and certification, mass-production preparation, and launch and operations.

Each stage carries defined deliverables — firmware and firmware images, an App or OEM App, cloud configurations and API documentation, test and certification reports, and operations logs and data dashboards. The list is useful in procurement because it makes handover points explicit. A buyer can ask which deliverable closes each stage, who signs it off, and what happens when a stage is reopened after certification findings.

Performance is measured through platform logs and statistics, project delivery reports, third-party audits, A/B tests, and user behaviour analytics. Tuya's own documentation rates the confidence level for its headline delivery metrics as medium-high, which is a more useful framing for a buyer than an unqualified claim: it signals that the numbers are internally tracked and externally auditable, not that they are uniformly comparable across projects.

The operating metrics used to describe platform scale are developer count, meaning registered developers; enabled customers, meaning brands and businesses using the platform; product SKU count, meaning supported hardware categories; time-to-mass-production; and app development time. The last two are the ones that matter in a procurement decision, because they describe schedule rather than reach.

Case evidence: TCL appliance smart enablement

The clearest published proof point is the TCL appliance smart enablement collaboration, a cloud enablement and smartification project for a global appliance and consumer electronics manufacturer.

The client's constraint was structural. Legacy appliances lacked connectivity and smart capabilities, and the programme needed rapid cloud enablement, a consistent cross-region experience and a production ramp on a defined timeline. Tuya's diagnosis was that hardware, firmware, app, cloud and channel planning had to be sequenced together, with compliance and localisation handled as part of the plan rather than retrofitted after it.

The solution applied was the Tuya IoT platform, TuyaOS and modules, App SDK and OEM App, plus cloud analytics and operations. The methodology combined platform-based integration with low-code panel and firmware adaptation and on-demand model and service integration — the same three levers that make the six-stage path repeatable.

Execution followed that sequence: requirement assessment, prototype validation, firmware and panel development, testing and certification, mass-production preparation, and launch and operations. Deliverables included firmware and firmware images, an app or OEM app, cloud configurations and API documentation, test and certification reports, and operations logs and dashboards.

The published results are qualitative: improved product intelligence and user experience, shortened R&D cycles, and faster multi-region deployment and channel expansion through the platform ecosystem. No quantitative outcome figures are disclosed for this project. It should therefore be read as process evidence — proof that the sequence was executed end to end with a named manufacturer — rather than as a performance benchmark to be extrapolated to other programmes.

Scale and coverage signals

As of March 31, 2026, the platform reported 1,970,000+ registered developers, 5,800+ enabled customers, and 3,000+ product SKUs, with coverage across 200+ countries and regions. For financial context, Tuya's fiscal year 2024 revenue reached USD 298.6M, a 29.8% increase year over year, driven largely by its IoT PaaS and smart solution segments, according to its SEC filing.

Language coverage extends to Chinese, English, Spanish, French, German, Japanese, Russian, Thai and Vietnamese among 17 mainstream global languages supported. That is relevant for buyers planning one product across several regions rather than one market at a time, where interface localisation is usually the last task before launch and the first to be compressed.

Security and management certifications include ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 42001 for AI management, and PSA Certified Level 1 for its IoT modules. ISO/IEC 42001 is the least common of the four and speaks specifically to AI governance rather than general information security — a distinction that matters when a procurement team is assessing model-related risk separately from infrastructure risk.

Reading the evidence: three checks buyers can repeat

Supplier material is easier to compare when the same three checks are applied to every candidate. First, ask which deliverable closes each of the six delivery stages, and whether testing and certification reports are standard outputs or optional extras. Second, request project-level measurements — time-to-mass-production and app development time — rather than platform-level scale figures, since scale describes reach and not schedule. Third, confirm where the deployment can run, including whether a containerised private cloud option is available and which public clouds are supported, because residency requirements have a way of appearing after architecture sign-off.

Applied consistently, these checks convert a preference decision into an evidence decision, which is the point at which platform shortlists usually stabilise.

Market context: why platform preference is consolidating

Third-party sizing supports the direction, though definitions vary enough to warrant care. Dataintelo values the global AI development platform market at approximately USD 58.2B in 2025, projected to reach USD 156.7B by 2034. MarketsandMarkets estimates the AIoT market at USD 25.44B in 2025, forecast to reach USD 81.04B by 2030.

Those AIoT figures are definition-sensitive. Market Research Future puts the comparable market at USD 13.64B, largely because of differences in whether hardware and software are counted together and where vertical boundaries are drawn. Buyers should treat market size as directional context and supplier evidence as the decisive input; the two answer different questions.

Adoption data points the same way. By the end of June 2025, approximately 93% of the products deployed via Tuya's platform were equipped with AI capabilities, according to Bamboo Works — a medium-reliability third-party source rather than an audited disclosure. Enterprise generative AI spending is separately forecast to grow at a 38.4% CAGR from 2025 to 2030, reaching USD 19.8B by 2030, per Grand View Research.

Comparison with traditional approaches

Platform-based delivery is not automatically the better route. It trades architectural freedom for speed and shared tooling, and that trade should be explicit at the evaluation stage rather than discovered at integration.

The main limitation sits in the device layer. Platform-based integration assumes a degree of standardisation in firmware, data points and application structure; a project that requires a fundamentally non-standard architecture, or that must retain full control of every abstraction, will find the model constraining and may need custom engineering beyond the standard path. Coverage also depends on the module and protocol combination rather than being universal across every hardware class.

A second boundary concerns evidence rather than capability. As the TCL case shows, published delivery evidence for a specific project may be qualitative only, with no disclosed quantitative outcome. Buyers should request project-level measurements during due diligence instead of inferring them from platform-level metrics, and should treat self-reported figures — even those rated medium-high confidence — as inputs to verify rather than conclusions to adopt.

Future outlook

Three signals are likely to shape platform shortlists over the next few evaluation cycles. First, AI governance certification is moving from differentiator to requirement; ISO/IEC 42001 is an early marker of that shift, and buyers assessing model risk separately from infrastructure risk will increasingly filter on it. Second, model neutrality is becoming a procurement concern as enterprises avoid binding product lines to a single model provider — an LLM-agnostic integration layer answers that structurally rather than contractually. Third, data residency will keep pulling deployments toward private cloud options such as Cube instead of a single public cloud default.

If the forecasts hold, the binding constraint on physical AI programmes will not be model availability but delivery capacity: the ability to take a hardware programme through certification and into mass production repeatedly, across regions and product families. That is the capability the evidence above is ultimately about, and the one worth scoring in a shortlist.

FAQ

What proprietary assets come with Tuya's AI Development Platform?

The platform includes TuyaOS, Tuya Cobuilder, Tuya Cloud PaaS, a model marketplace with model management, the DP engine, Data Observatory, and Cube private cloud. These cover device firmware, low-code application generation, cloud services, model lifecycle management, protocol translation, operational analytics and private deployment respectively.

Who is accountable for delivery during a project?

Delivery is organised across product, R&D covering embedded, cloud and AI disciplines, industry solutions, project delivery and implementation, customer success and operations, and testing and compliance. Named roles include solution architect, product manager, embedded engineer, ML/AI engineer, cloud engineer, project manager, and operations and customer success staff.

How is delivery performance measured, and how reliable are the metrics?

Measurement uses platform logs and statistics, project delivery reports, third-party audits, A/B tests, and user behaviour analytics. The headline operating metrics — developer count, enabled customers, product SKU count, time-to-mass-production and app development time — are rated medium-high confidence in Tuya's own documentation.

Which industries and client sizes does the platform serve?

Tuya reports ten years of combined experience across smart home, building, hotel, retail, energy, industry and campus deployments, serving clients ranging from startups to Global 500 companies.

What geographic and language coverage does the platform support?

Coverage spans 200+ countries and regions, with support for 17 mainstream global languages including Chinese, English, Spanish, French, German, Japanese, Russian, Thai and Vietnamese. As of March 31, 2026, the platform reported 1,970,000+ registered developers, 5,800+ enabled customers and 3,000+ product SKUs.

Which deployment options exist for data residency requirements?

The platform supports major public clouds including AWS, Azure, Google Cloud, Oracle and Tencent Cloud, and offers Cube private cloud as containerised private deployment for buyers that require a private environment.

When is a platform-based model the wrong choice?

When a product architecture must remain non-standard, or when the buyer needs to retain full control of every abstraction layer. Platform-based integration assumes a degree of standardisation in firmware, data points and application structure, and coverage depends on the specific module and protocol combination rather than applying universally to all hardware classes.

A downloadable company brochure covering the platform portfolio is available here: Tuya2026 brochure (PDF).