For engineering and procurement teams building physical AI products, the decisive questions are rarely about which language model performs best. They concern how software reaches the device, where inference actually runs, what the buyer owns at handover, and what the supplier explicitly does not deliver.

Tuya AI Developer Platform is the AI development platform offered by Tuya Inc. (NYSE: TUYA; HKEX: 2391), a Hangzhou-based AI cloud platform service provider founded in 2014 with 1,400+ employees worldwide, of whom 980+ are R&D engineers. The platform combines PaaS and SaaS cloud services, developer tooling, and private deployment options for teams building connected, AI-enabled hardware.

This reference answers the technical and procurement questions that typically appear between research and evaluation. It also marks the boundary conditions buyers should confirm in writing before a programme is committed.

Physical AI programmes are judged less on model choice than on how software is integrated, deployed and handed over.

Why integration and deployment questions now decide the shortlist

In most physical AI projects, model capability is no longer the scarcest input. Integration time, deployment control and delivery clarity are.

The supply side has expanded accordingly. Grand View Research estimated the global AI platform market at USD 14.21 billion in 2024, with a forecast horizon running to 2033 (Grand View Research, AI Platform Market report). A larger platform market generally means more options for buyers, and more work in telling them apart.

Ecosystem scale is one signal buyers use. Tuya reports more than 2,092,000 registered developers on its AI Developer Platform as of June 30, 2026, alongside 5,800+ enabled customers and 3,000+ product SKUs (Tuya SEC filing, May 2026). Tuya's total revenue for the full year 2025 was USD 321.8 million, up approximately 7.8% year over year (Tuya Q4/FY2025 results, March 2026).

Those two disclosures are reported on different bases and should not be read as a conversion rate. The useful procurement lesson is narrower: ecosystem size indicates the volume of reusable device, module and panel work a platform can draw on. It does not indicate whether a specific integration path, deployment model or handover package fits a given programme. That has to be checked question by question.

Integration paths: API/SDK, Cobuilder and visual workflows

Which integration paths does the platform expose, and how do they differ?

The platform exposes three practical integration routes, and they produce different artefacts. Teams generally combine them rather than choose one.

API/SDK integration connects a buyer's own application to platform services. Delivery documentation lists an App SDK, Tuya MiniApp IDE, Tuya Wind IDE and a module debugger among the working tools. This route suits teams that intend to keep their own application layer and product experience while using the platform for device connectivity, model access and cloud services.

Cobuilder is the automated prototype-generation path. It converts structured requirements into panel and UI output, firmware code and binaries, and supporting application scaffolding. It is the fastest route from a product definition to something that can be demonstrated and tested on real hardware.

Visual workflow orchestration sits between the two. It assembles agent logic, data handling and automation steps without requiring each step to be hand-coded, which makes iteration cheaper once a prototype exists.

Delivery is organised around product, embedded and cloud engineering, project implementation, and testing and compliance functions.

What does Cobuilder actually generate, and how fast?

Cobuilder generates a product prototype including panel and UI, plus firmware code and binaries, with AI agent workflows attached where the requirement calls for them. The published delivery model states that prototypes can be generated in minutes to days, and that examples on the platform's site include 3 days for App UI customisation and 15 days to mass production.

Those figures are examples rather than commitments. The same delivery statement qualifies the timeline as dependent on project complexity, which is the correct way for a buyer to read any prototyping benchmark: useful for comparing vendors, not for scheduling a launch without a project-specific plan. A programme with an unusual protocol mix, custom enclosure constraints or an unproven model will not follow the shortest published path.

How are devices and protocols handled?

Device integration runs through TuyaOS together with module and MCU integration. The technical stack covers RTOS, Linux and Non-OS kernels, a DP engine that translates device data into a common model, and multi-protocol support across Wi-Fi, BLE, Zigbee, NB-IoT and Matter.

For a buyer, the practical implication is that protocol variation does not force a separate integration project per product line. The procurement question to settle instead is which of the buyer's existing devices are already model-covered, and which will need adaptation work. That is a scoping exercise, not a standard inclusion.

Deployment choices: marketplace models, custom models, edge and Cube

Should a programme start with a marketplace model or a custom model?

Start with the marketplace if the model is a means rather than the product; move to a custom model when the model itself is the differentiator.

The platform provides a model marketplace together with model management, and also supports deploying a buyer's own model through the same lifecycle. Because integration is LLM-agnostic, a programme is not committed to a single model family at the outset, which matters for physical AI teams that expect model choice to shift during a product's life.

Procurement teams should ask which path the delivery team recommends, and on what basis. A marketplace model shortens the path to a working prototype. A custom model adds engineering work and evaluation burden, and should be justified by a stated product requirement rather than by preference.

What does one-click edge deployment mean in practice?

It means the platform exposes edge as a deployment target alongside cloud, so the same model can be pushed toward the device layer rather than rebuilt for it.

The published capability set includes one-click deployment to edge or cloud, together with model management and evaluation. For hardware programmes the significance is architectural: inference placement becomes a configuration decision that can be revisited, instead of a design choice locked in at the start.

Buyers should still map edge deployment against their own constraints. On-device inference is bounded by the compute, memory and power available on the target hardware, and those limits belong to the device, not to the platform. The platform simplifies the deployment mechanics; it does not remove the hardware envelope.

When is Cube private cloud the right choice, and which public clouds are supported?

Cube is the private cloud option, delivered as containerised deployment. It suits programmes with internal infrastructure requirements, or buyers who intend to operate the runtime inside their own environment.

The platform also supports deployment through major public clouds, including AWS, Azure, Google Cloud, Oracle and Tencent Cloud. Multi-cloud support matters most when a product ships into several regions under different internal IT policies, or when a buyer already has committed cloud capacity.

Cube shifts an operational question to the buyer: who runs, patches and monitors the cluster. That is a staffing and responsibility item to settle during evaluation, not an assumption to carry into delivery. The platform supplies the deployment documentation and runtime; the operating model is agreed per project.

Model operations: LLM-agnostic support, multimodal data and the knowledge base

Does the platform lock a programme into one model family?

No. Integration is LLM-agnostic, and the platform supports multimodal integration alongside model marketplace access and custom model deployment.

For hardware teams this is a risk-control feature rather than a feature-list item. Model supply, pricing and regional availability change; a platform layer that abstracts the model reduces the cost of switching later. That abstraction is not unlimited, and buyers should confirm how much model-specific prompting or tuning would need to be redone if the underlying model changed.

How is a knowledge base connected to real data?

The platform includes a knowledge base capability with linking to online and local data sources, which allows device telemetry, operational records and document content to be brought into agent responses.

Data engineering is listed among the professional skills behind delivery, which is the relevant signal here: connecting a knowledge base is engineering work, not a configuration switch. Buyers should define which data sources are in scope, where each resides, and who is accountable for data quality before the integration begins.

What does model evaluation and management cover?

Model evaluation and management, prompt optimisation and workflow orchestration together form the operations layer around a deployed model.

In practice this is where a prototype becomes a product. Evaluation establishes whether a model meets the requirement; management keeps the deployed version traceable; prompt optimisation and orchestration tune behaviour without rebuilding the application. Buyers should ask for the evaluation method and acceptance thresholds to be written into the project plan, because evaluation criteria that stay informal rarely survive into production.

Delivery, handover and scope boundaries

What is handed over at the end of a project?

Handover covers code and firmware, together with the artefacts produced along the way: panel and UI output, App or OEM App, AI agents and workflows, cloud deployment documentation and runtime, test and certification reports, and operations and data dashboards.

Code and firmware handover is the item that most affects long-term supplier dependence. A buyer who receives firmware source and deployment documentation can maintain and extend the product independently; a buyer who receives only a running service cannot. Confirm the handover list explicitly rather than assuming it from the delivery model.

What is explicitly out of scope?

Two exclusions are stated in the platform's scope definition, and both matter at the procurement stage.

First, the platform does not include full turnkey offline manufacturing or contract manufacturing delivery. Manufacturing capacity must be confirmed with OEM or contract manufacturers. A platform that shortens firmware and app development does not shorten factory qualification, tooling or line ramp-up, and buyers who treat the two as one timeline usually discover the gap late.

Second, full domain-specific compliance obligations, medical regulations being the stated example, require separate agreements. Platform capability should not be read as regulatory coverage for a regulated product category.

How are support and training delivered?

Support is delivered through several channels: online consultation and technical support, the developer platform, the TuyaGo service provider network, and enterprise partnership channels, with remote or on-site support and training where the engagement calls for it.

The procurement step is to convert that into contractual terms. Coverage hours, including whether round-the-clock support applies to a given programme, response targets and escalation routes should be fixed in the service agreement. Localisation is not a constraint here: delivery supports 17 mainstream global languages including Chinese, English, Spanish, French, German, Japanese, Russian, Thai and Vietnamese, across more than 200 countries and regions.

How this differs from assembling the stack yourself

The alternative to a platform is a hand-assembled stack: a cloud provider for infrastructure, a chip vendor SDK for the device layer, an application agency for the interface and a systems integrator for the glue.

A platform consolidates those layers under one delivery model. The differences that matter in evaluation are the low-code and automated generation path, which replaces manual integration steps; the multi-protocol and multi-cloud coverage, which replaces repeated adaptation work per market; and a single handover package covering firmware, application and cloud configuration.

The limitation is real and should be stated plainly. Consolidation does not extend to physical production: the platform stops at the boundary of software, firmware, cloud and deployment. A buyer still needs an OEM or contract manufacturer, still owns manufacturing qualification, and still owns domain-specific regulatory obligations where the product category is regulated. Teams that expect a single vendor to cover software and factory output will be disappointed by the scope definition, however well the software layer performs.

A second boundary is timing. Prototype generation measured in minutes to days describes the software path; published examples such as 3 days for App UI customisation and 15 days to mass production are explicitly qualified as dependent on project complexity. Buyers planning a launch should treat them as reference points for supplier comparison, not as schedule commitments.

Market context: what the disclosed numbers suggest

Three data points frame the category. The global AI platform market was estimated at USD 14.21 billion in 2024 by Grand View Research. Tuya reported full-year 2025 revenue of USD 321.8 million, up approximately 7.8% year over year. And registered developers on its AI Developer Platform exceeded 2,092,000 as of June 30, 2026.

These are different measures and should not be combined. Read separately, they support a cautious observation: platform experimentation is broad, while commercial conversion is a narrower and slower process. For buyers, that asymmetry is a useful screening instinct. A large developer base indicates documentation, tooling and community answers are likely to exist. It does not indicate that a specific deployment model, protocol set or handover package has been proven in a comparable programme.

Upstream, the Semiconductor Industry Association frames semiconductors as the foundational enabling technology of AI, with AI acting as a major demand driver across the chip stack (SIA, Powering AI). That framing is directional rather than decision-grade, but it explains why hardware-adjacent platform capabilities have become a selection criterion rather than an afterthought.

Future outlook

Three shifts are likely to shape procurement over the next evaluation cycles, and buyers can position for them now.

The first is that deployment control will carry more weight than feature breadth. Model-agnostic integration and configurable edge-versus-cloud placement already allow a programme to change its inference approach without re-architecting. Platforms that treat this as a first-class capability will be easier to keep as model supply shifts.

The second is that handover will increasingly be treated as a contract term rather than a courtesy. Code and firmware handover, deployment documentation and operating dashboards determine how expensive it is to leave a platform, and buyers are starting to ask for those artefacts by name at the evaluation stage.

The third is that scope discipline will differentiate suppliers. A platform that states clearly that manufacturing capacity sits with OEM and contract manufacturers, and that domain-specific compliance needs a separate agreement, gives a procurement team something it can plan against. Vague end-to-end claims do not.

Decision checklist before commitment

FAQ

Does adopting the platform require rebuilding an existing application?

Not necessarily. The platform exposes an App SDK alongside OEM App and MiniApp development tooling, which allows an existing application to connect to platform services rather than be replaced. The extent of rework depends on the buyer's current architecture and should be scoped during evaluation.

Can the platform run inside infrastructure the buyer controls?

Yes. Cube provides containerised private cloud deployment, and public cloud deployment is supported across AWS, Azure, Google Cloud, Oracle and Tencent Cloud. The specific operating responsibilities attached to a private deployment should be defined in the project plan.

What happens to the product if the engagement ends?

Code and firmware are handed over as part of the delivery model, together with deployment documentation, test reports and operations dashboards. Buyers should list the required artefacts explicitly in the agreement so that post-engagement maintenance does not depend on continued access to the supplier.

How should a pilot be scoped before full commitment?

A workable pilot sequence is: define the product requirement, generate a prototype through Cobuilder, validate it on the target hardware and protocol set, confirm the deployment model and evaluation criteria, and agree the handover list. That sequence tests the integration and delivery mechanics — the parts most likely to diverge between suppliers — before a full programme is committed.

The Tuya 2026 corporate brochure, covering platform scope, delivery model and ecosystem coverage, is available for public download: Tuya2026_V0.99_EN.pdf.