Ask a supplier who can switch off the cloud behind your product. If the answer is "the platform", you are not buying software; you are renting access to it. It is a deal with terms, and the terms need to be on the table before the mold is cut.
For an OEM buyer, the choice is between a Tuya-based stack and a proprietary app built around their own cloud. The first gets a connected product to market faster. The second buys control and a permanent engineering obligation. The useful question is not which sounds more ambitious, but which one fits the stage of the business.
What Tuya actually provides
A Tuya-based product is built around a platform module and the Tuya cloud. The app already exists; the buyer adds a logo, a color scheme and a product name. Voice integration with Alexa and Google is part of the package, and the platform's data centers serve multiple regions. The 4L automatic pet food dispenser with Tuya app control and the 4L/6L OEM dual-bowl camera feeder are examples of SKUs that ship on that stack.
The commercial value is time. The connectivity work, the app-store presence and the basic cloud infrastructure are already done. A buyer can focus on the hardware, the packaging and the channel. For a marketplace seller testing a connected product, or a retailer adding a private-label line, that time is often worth more than the differentiation a custom app might eventually provide.
What the dependency costs
The trade-off is control. The platform owns the cloud, sets the feature roadmap and decides how accounts are governed. If a policy changes, a fee rises or an outage lasts longer than expected, the buyer owns the customer complaint even though the buyer does not own the system. A contract can allocate some of that risk. It cannot make the platform disappear.
There is also a differentiation ceiling. When every brand in a category runs the same app with a different logo, the app stops being a reason to choose one product over another. For a brand whose entire proposition is the software experience, it is a ceiling worth naming before launch.
The proprietary path is a software company
A proprietary app is not a one-time development fee. It is an iOS and Android product, a cloud service, a security patch process and a support desk. The build commonly takes six to twelve months before the first unit ships, and the running cost starts on day one after launch. Operating-system updates arrive on someone else's schedule. App-store review can delay a fix. A firmware bug in the field becomes a release-management problem, not a factory rework.
The legal side follows the software. If the product collects personal data from EU customers, the importer, not the factory, is likely to carry the obligations for how that data is used. That brings a privacy notice, a lawful basis, a retention policy and a process for access or deletion requests. All of it needs an owner. Ask who maintains the app once the launch is over, who answers a data request, and who ships the patch when a phone update breaks pairing. If the answer is "the factory", get it in writing with a service level.
Five clauses to lock before tooling
Whichever path you choose, the contract should answer the same questions. These five clauses are the minimum for a connected product.
- Firmware ownership. Separate the platform's stock firmware from code written for your program. State who owns the custom code and what happens to bug fixes, security patches and derivatives.
- App brand license. If your logo sits on a stock app, define the license term, the renewal price and what happens at expiry. A license that ends can take the product's user interface with it.
- Data ownership and export. Name the data you own, the format of a machine-readable export, and how often you can request it. Without this, the customer list lives on someone else's server.
- Migration and exit. Define a tested path to a second cloud or a replacement app, including the handover window and the support the supplier will provide. "We will help" is not a clause.
- Supply continuity. Cover spare parts, firmware updates and security fixes for the warranty period and a defined period after it. If the supplier stops supporting the SKU, the buyer needs a plan for the installed base.
Add a service-level schedule for uptime and incident notification if the product depends on the cloud. The details can be short, but they need to be measurable.
Match the path to the stage
The right answer changes with volume and with what the buyer is actually selling. A marketplace seller with a new listing needs speed and a credible app; Tuya with a branded skin is usually the lower-risk start. A chain adding a private-label line needs the same speed plus contract protection; the five clauses matter more than the app's visual identity. A brand whose product promise is the software experience needs proprietary control, but should budget the build and the maintenance as a multi-year commitment, not as an optional extra.
Production mechanics do not change with the app choice. OEM programs begin at 1,000 units and are quoted at 15 to 25 days of production. ODM work begins at 3,000 units and runs 30 to 45 days. A private-label small order can start at 50. The app decision sits in front of those timelines, not inside them. A Tuya SKU can use an existing platform module. A proprietary build adds the software schedule before the first saleable unit.
Migration is a contract feature
Buyers often assume they can start on Tuya and move to their own app when volume justifies it. The move depends on a data export right, a firmware design that can point at a second cloud, and a migration window the supplier will support. Without the export, migration means asking customers to re-register. Without the firmware path, it means replacing hardware. Both are expensive ways to learn that the contract should have been more specific.
If migration is part of the plan, design the customer experience to survive it. Keep the app name and the account flow stable, migrate in cohorts, and test the new cloud with a small group before switching the installed base. The goal is that the customer notices a better app, not a change of ownership.
The questions behind the contract
Who owns the firmware?
It depends on what the firmware is. Stock platform firmware usually stays with the platform and is licensed with the module. Custom code written for your product should be covered by an assignment or license clause. The clause should also cover derivatives: bug fixes, security patches and feature updates. If the contract is silent, the answer is decided later by whoever holds the code.
Can I move users to my own app later?
Only if the contract gives you the data and the technical path. You need a machine-readable export of user and device data, a firmware route to a second cloud, and a migration window the supplier will support. Without those, moving users means re-onboarding them one by one. Plan the exit before launch, even if the move is years away.
Start with the buyer you are, not the app you admire. The cheapest contract is the one that answers the exit question before the first deposit, and the most expensive is the one that discovers it after the mold is cut.
