Customized App

Tuya customizes apps based on the latest version of Smart Life available during project kickoff. Customized app provides brand-specific UIs and business logic to meet personalized customer requirements. They have all available configuration capabilities of OEM Apps.

Process

If you have app customization requirements, contact your Tuya business manager to kick off a project. The following part describes the app customization process. Read it carefully to learn about the specifics in each phase and relevant output to ensure the project successfully and efficiently.

Requirements gathering

• Participants: business manager, project manager, and customer
• Events: The business manager discusses the requirements with the customer. The project manager helps the business manager sort out the functional logic for the hardware, app, panel, and brand-specific UI design request. If the customer has its own product or design capability, the customer can provide the product requirements document (PRD) or UI design document. The business manager will compile a preliminary requirements document.

Requirements evaluation

• Participants: business manager, project manager, R&D team, and customer
• Events: The project manager confirms the preliminary requirements document with the business manager and customer. The project manager and R&D team review the requirements and estimate the workload.

Business negotiation

• Participants: business manager and customer
• Events: The business manager negotiates the estimated workload with the customer, reaches an agreement on the project scope, and then signs a business contract with the customer.

Review and kickoff

• Participants: business manager, project manager, and project management office (PMO)
• Events: The business manager submits the business contract to Tuya’s internal system. The project manager submits relevant documents, including the preliminary requirements document and detailed requirements document. The PMO reviews the contract and documents. Upon approval, the project kicks off.

Project implementation

• Participants: customer, business manager, project manager, R&D team, and Tuya designer

• Events: The customer and Tuya personnel need to communicate with each other in a timely manner and work closely, side by side to guarantee successful project implementation as scheduled.

  • Detailed requirements document preparation: The project manager describes the requirements to provide a detailed requirements document.
  • Detailed requirements clarification: Based on the preliminary requirements document, detailed requirements document, and PRD or design document from the customer, the R&D team lists the detailed requirements that are ambiguous or not described in these documents in Issues to Be Confirmed. The customer checks Issues to Be Confirmed and clarifies the relevant items in a timely manner.
  • PRD or UI design document confirmation: If the customer has a PRD or UI design document, the customer provides it to Tuya. If not, the customer assists the Tuya designer in working out a design document by recommending modifications to the design drafts until the final version is confirmed.
  • Schedule confirmation: As the API provider for some requirements, the customer determines when the APIs and API definition document will be available to prevent project delay. If the customer provides the sample, the customer determines when the sample will be ready for testing. Tuya can then determine the time for joint app commissioning with the sample.
  • Tuya’s project team members cooperate with each other during development, testing, and internal acceptance to ensure that the project deliverables meet the customization requirements.

Customer acceptance

• Participants: customer, business manager, and project manager
• Events:
  • Tuya provides the customer with deliverables including software as scheduled.
  • After receiving the deliverables, the customer tests functions of the software and devices, including the app UIs, panels, and device control through the app, within the appointed time. If the customer fails to complete the acceptance testing as scheduled and cause to a project delay, the customer shall be responsible for the delay.
  • Tuya fixes bugs discovered during the acceptance testing.
  • The customer proposes requirement changes and negotiates with Tuya on the time when the changes will be incorporated into a new version in the next iteration cycle.

Additional information

• Precautions for the customer

  • If you have a PRD or UI design document, provide it to Tuya in a timely manner.
  • If Tuya provides the UI design document, check and recommend modifications to the design in a timely manner.
  • Check Issues to Be Confirmed sent by Tuya and reply to the questions as soon as possible.
  • If you provide APIs for some requirements, determine when the APIs and API definition document will be available to prevent project delay.
  • If you send samples to Tuya for joint commissioning, schedule the time for sending them and provide the sample testing report, to ensure the overall project progress.

• Requirement changes during the project

  • Change definition

    • New modifications to confirmed UI details
    • New logical functions based on the confirmed business logic
    • Functions or UIs not included in the preliminary requirements

  • Requirement change handling

    • Incorporate requirement changes into a later version through iteration, but release the current version as scheduled.

    • Incorporate requirement changes into the current version and postpone the release of the current version. This method only can be applied after customer confirmation.

      Note: If requirement changes need to be incorporated into the current version, extra time will be scheduled for handling them, which will extend the overall project cycle.