Navigation
Make the app map match the product
Replace the fixed OEM shell with navigation shaped around your categories, core tasks, and release priorities.
Tuya OEM-to-SDK
Tuya SDK app development with a practical first phase.
For teams outgrowing the Tuya OEM app and moving toward a branded, product-fit Tuya App SDK experience.
OEM to SDK
Upgrade direction
Scope review
Before rebuild
Phase 1
Setup and control
Vesetail Home
My Home
Living room active
Online
3
Current scene
Evening
Warm lights, comfort AC
Indoor
24 C
Power 1.8kW
Humidity 48%
Air Good
Scenes
Tap to preview
Frequent devices
Core controls
What changes with SDK
What can actually be customized.
Moving from OEM to SDK is about changing the parts of the app where the template starts to feel generic and the product needs its own voice.
Home
Organize devices around real usage
Homes, rooms, groups, and shortcuts can follow the way customers actually live with the product.
Setup
Shape onboarding
Pairing, permissions, recovery, and empty states can carry product context instead of template language.
Users
Control how access is shared
Invitations, roles, and shared-device flows can be tuned for households, teams, or managed spaces.
Control
Design the screens users touch daily
Control panels, scenes, schedules, dashboards, and status feedback can feel native to the product.
Logic
Add product-specific rules
Use SDK work for states, conditions, and decisions that the standard OEM app cannot express cleanly.
When OEM starts to limit the product
Signs it is time to move beyond the template.
A standard OEM app helps a product reach market faster. The shift usually starts when the app becomes part of product value, not just device access.
Signal 01
Customers say the app feels like a different brand than the product
Signal 02
Setup, control, or sharing flows hit limits the OEM template cannot bend
Signal 03
The next release needs flexibility the OEM app simply cannot offer
Signal 04
The OEM app can no longer keep up with the product roadmap
OEM to SDK shift
What changes when the app becomes yours.
SDK work turns template constraints into product decisions: brand, listing, navigation, flow control, and app logic become yours to shape.
OEM app limits
01 Template-led brand experience
02 Shared app listing
03 Fixed navigation
04 Limited flow control
05 Shared template logic
What usually gets scoped first
The four areas teams usually start with.
A first phase is about choosing what to change first, not trying to upgrade everything at once.
Setup & onboarding flow
The first thing every user touches, and usually the most product-specific.
Device control & status
The screens users return to every day. Small UX gains here change how the product feels.
Room & home structure
Important once product lines or device counts grow, but often safe to phase later.
Sharing & multi-user access
Worth scoping early when households or teams are core to the product.
How OEM-to-SDK migration usually starts
A review first, not a rebuild.
Most projects begin with a structured review of the current setup and a clearly scoped first phase.
Step 01
Review the current app
Look at the existing OEM setup honestly: what works, what constrains the product, and where friction lives.
Current state Real friction
Step 02
Define the first phase
Decide which flows should change now, which can wait, and what a realistic first release includes.
Scope decisionsFirst-phase plan
Step 03
Build the first SDK release
Stand up the SDK base: branded shell, core flows, and the app foundation later phases depend on.
Branded base 2 Core flows
Step 04
Improve in later phases
Layer in rooms, sharing, deeper logic, and product-specific UX after the first release is stable.
Phase 2+
Steady expansion
Why teams work with us
Built around product fit, not template delivery.
We help decide whether SDK is actually needed
If OEM still fits, we keep the scope lighter. If more control is needed, we define where the SDK path should begin.
We focus on the flows users actually feel
Brand, setup, pairing, and core control come first because they shape the everyday product experience.
We turn app ideas into a first release
Vesetail separates phase-one needs from later improvements, so the SDK scope stays clear and buildable.
We design around product fit and market expectations
The app should fit the product, users, and markets it serves, not just look like a nicer template.
Common questions
Common questions about OEM-to-SDK upgrades.
How is the Tuya App SDK different from the OEM app?
The OEM path is more template-led and configuration-driven. The SDK gives you full control over brand, navigation, flows, and product logic, but it is a real app project, not a configuration.
Do we have to rebuild everything at once?
No. Most teams start with a clearly scoped first phase, usually brand, setup, and core control, then grow from there.
What usually gets included in the first phase?
Typically: a branded shell, the setup or pairing flow, and the core control screens users touch every day.
What can actually be customized in a Tuya SDK app?
Navigation, device and room structure, onboarding and pairing, sharing, control UX, and product-specific logic.
When does OEM become too limiting?
Usually when the app starts shaping how customers see the product and the OEM template blocks brand, UX, or flow decisions.
Can Tuya Cloud API or backend integration be part of the app scope?
Yes, when the app needs backend logic, automation workflows, dashboards, or integrations beyond the mobile experience.
How long does the first phase usually take?
Most first phases land in a few months, depending on scope, device types, and how much custom UX is included.
Start point
Need a clearer OEM-to-SDK plan?
A scope review helps define what should change first, what can wait, and what a practical first phase should include.