1,400 Connected Spas Replatformed and Two Brand Apps Unified for a Premium Hot Tub Manufacturer

Industry

Geography

Southern California, US

Cooperation Period

18 weeks

Executive outcome

At the opening of the engagement, the Client ran its connected spa program for both consumer brands on a legacy Digi cloud, with duplicate native codebases per brand across iOS and Android and a cost structure that passed an annual subscription fee onto owners. Clixlogix diagnosed the architecture, replatformed the IoT backend onto PTC ThingWorx on AWS, unified the two brand apps onto one modular codebase per native platform with brand specific configuration, and migrated roughly 1,400 legacy spa units over the air with no technician dispatch. The program removed the owner subscription fee on the connected spa line and reseated both connected apps on an architecture the Client’s product team continues to extend.

About the client

The Client is a long established manufacturer at the premium end of the hot tub and connected spa market, operating from its US headquarters in Southern California. It runs two consumer spa brands that carry separate identities, separate design languages and separate dealer networks, and it sells through a specialty dealer channel across the United States and Canada. Both brands carry connected product lines that owners control from mobile apps on iOS and Android.

The channel shape matters to how the connected products work. The Client sells through independent specialty dealers, so the dealer who installs a spa usually holds the first service relationship with its owner. A connected spa therefore carries two support paths from the day it is switched on, one to the installing dealer and one to the manufacturer, and the app has to route each owner question to the right one.

The product category sets the engineering constraint. A spa is a durable good that stays in place for years after a single installation, so the installed base outlives several generations of cloud platform and mobile operating system. Any connected spa program therefore accumulates a field population that no replacement cycle will refresh, and the cost of reaching those units in person rises with the size of the fleet. That constraint shaped every architectural decision on this engagement.

Diagnosis

Per unit cloud billing drove the owner subscription

The connected spa experience ran on a Digi cloud architecture where each unit on the cloud billed the Client per unit per year. The connected products group had passed the cost through to owners as an annual subscription, which placed the connected feature set in a different commercial category from the free app surfaces owners expected from other connected consumer products.

The two brands shipped on four separate codebases

The two brand apps shipped as two separate iOS codebases and two separate Android codebases, so a single feature change required four parallel builds, four App Store or Google Play reviews, and four regression passes. The engineering group carried a feature cost that scaled with brand count, which further strained the economics behind the owner fee.

SSL polling drove bandwidth cost and command latency

The app to device channel ran on an SSL polling connection between the Hardware Network Appliance inside each spa and the Digi cloud. The connection drove bandwidth cost per unit, delayed remote commands by seconds past the owner’s tap, and did not carry a reliable device heartbeat the Client’s support organization could trust.

Legacy fleet had no over the air repoint route

Roughly 1,400 connected spa units already sat in the field at owner locations. The Hardware Network Appliance firmware had no over the air route to redirect from Digi to a replacement cloud, so a cloud migration risked stranding the installed fleet at owner locations or forcing a technician visit per unit.

Fig 1 - Pre and post engagement architecture for the connected spa line

Device Trust Baseline

Connected consumer devices in the US operate under published federal cybersecurity capability baselines. NIST IR 8259A, the US National Institute of Standards and Technology core device cybersecurity capability baseline for IoT, sets the capability baseline for device identification, device configuration, data protection, logical access to interfaces, software update, and cybersecurity state awareness. A connected spa line held to that baseline carries direct implications for how the IoT cloud, the device firmware, and the owner mobile apps are architected.

Before and after

Axis	Before the engagement	After the engagement
Owner commercial posture on the connected app	Annual subscription fee paid by owners to keep connected features active	Connected app free to owners on the connected spa line, with no per unit cloud bill in the way
Cloud operator for the connected spa fleet	Digi managed IoT cloud with per unit annual billing	PTC ThingWorx on AWS under the Client’s control, cloud subscription priced on data volume
Mobile app delivery across the two brands	four codebases, two platforms times two brands, four store artifacts per release	One modular codebase per native platform, two store artifacts per release under brand identity
App to device communication protocol	SSL polling with bandwidth cost per unit and command latency measured in seconds	MQTT with a reliable device heartbeat and command delivery measured in seconds end to end
Spa provisioning on new installations	Dealer or technician keyed the serial by hand at install, with ad hoc pairing	Barcode scan reads the serial on the hardware label and verifies pairing against the ThingWorx registry before the first command
Owner support routing inside the app	Manufacturer handled every owner contact, including dealer service questions	Dealer locator routes service questions to the owning dealer and routes product questions to the manufacturer
Legacy fleet onboarding under a cloud migration	No route available, a cloud migration would strand existing units or need a technician visit per unit	Over the air repoint moves installed units with no owner action and no technician dispatch

Table 1 - Pre and post engagement axes for the connected spa line

Engagement model

Diagnose (Legacy architecture assessment)

Clixlogix opened the engagement with a working session that mapped the Digi cloud integration, the four app codebases, the SSL polling flow between the Hardware Network Appliance and the cloud, and the owner subscription billing path. The Client’s technical consulting team worked alongside Clixlogix as the direct engagement counterpart from this stage through the Transition handover, with the connected products group as the business owner of the connected spa line. The Diagnose stage captured the four findings in a shared register, inventoried the installed fleet by firmware revision and brand, and ran a feasibility check on PTC ThingWorx as the replatform target.

At the end of this stage the Client’s connected products group owned an architecture assessment of the Digi integration, a four codebase redundancy analysis, a device to cloud protocol audit, and a feasibility note on PTC ThingWorx as the replatform target.

Architect (ThingWorx replatform design)

Clixlogix sized the ThingWorx data model for the combined device fleet, specified the MQTT protocol boundaries between the Hardware Network Appliance firmware and the new cloud, defined the shared codebase architecture for the two brand apps with brand specific configuration resources, and sequenced the over the air repoint approach that would move the installed fleet off Digi.

At the end of this stage the Client’s connected products group owned a ThingWorx data model aligned to the device fleet, an MQTT protocol specification, a shared codebase architecture for the two consumer apps, and a legacy fleet migration plan.

Build (Unified codebase and MQTT firmware)

Clixlogix built the ThingWorx entity model on AWS, migrated the Python Hardware Network Appliance code to speak MQTT to ThingWorx while preserving the on device user experience, and assembled the unified mobile codebase per native platform with the two brand apps as two brand configurations. Core app surfaces delivered covered water temperature, filtration cycles, Boost, mood lighting, music control, and an administrative dashboard with user and device oversight for the Client’s operations group. Access roles separated Spa Owner from Spa Guest so a household could issue a limited control grant to a family member or houseguest without opening the full administrative surface.

At the end of this stage the Client’s connected products group owned a running ThingWorx cloud environment on AWS, Python Hardware Network Appliance firmware wired to MQTT, and a working unified app binary covering both consumer brands.

Harden (Security review and QA validation)

Clixlogix walked the Client’s security team through a review of the APK and IPA artifacts, resolved the findings before resubmission, and ran phased validation on the ThingWorx QA cloud with a controlled slice of legacy and new spa units. The Harden stage also exercised the over the air repoint path on a staging fleet to confirm legacy units could migrate from Digi to ThingWorx with no owner action.

At the end of this stage the Client’s connected products group owned signed off APK and IPA builds, a validated QA ThingWorx environment, and a tested legacy repoint procedure.

Transition (Fleet migration and operational handover)

Clixlogix sequenced the production migration of legacy units in batches, confirmed each batch had reconnected and resumed heartbeat on ThingWorx, moved net new installs onto the barcode scan provisioning path, and handed the operational runbook to the Client’s support organization. Clixlogix cut over the dealer routing and manufacturer routing paths inside the app during the same window.

At the end of this stage the Client’s connected products group owned a fully migrated connected spa fleet on ThingWorx, a published provisioning runbook, and an operational handover record signed with the support organization.

Fig 2 - Owner command and device heartbeat path on MQTT

Methodology highlights

Daily synchronization cadence

Clixlogix held daily synchronization sessions with the Client’s technical consulting team embedded on the program and weekly sprint reviews with the hardware group. The sessions kept the development work on AWS and ThingWorx aligned with the physical constraints of the spa controller hardware, which was the single largest source of integration risk on the program.

No dispatch migration strategy

The migration strategy held the over the air repoint as a hard constraint. Clixlogix exercised the over the air repoint path on a controlled staging fleet before the production rollout, then moved 1,400+ units off the Digi cloud with no technician visit and no owner action.

Security by design

IoT programs carry inherent security risk when household data moves across cloud and device surfaces. During the Harden stage, Clixlogix ran security audits on all application artifacts and operated a feedback loop with the Client’s security team to resolve findings before production deployment.

Operational handover

Clixlogix produced a standardized provisioning runbook, cut over the dealer routing and manufacturer routing paths inside the app, and handed a signed support handover to the Client’s support organization. The deliverable at close was an operational asset the Client’s support organization could run on its own.

Architecture decisions

Decision 1. PTC ThingWorx on AWS as the IoT backend

Alternatives Clixlogix evaluated

Stay on Digi with renegotiated per unit pricing
Build a custom MQTT broker on AWS IoT Core with a hand built device registry
Move to Microsoft Azure IoT Hub

Decision criterion

The Client required a cloud that supported the installed Hardware Network Appliance firmware with low rewrite cost, carried device fleet management features out of the box, and allowed the connected products group to retire the per unit subscription with no firmware replacement across the installed base.

Rationale

ThingWorx carried a device model, event rule configuration, and remote device management surface that matched the connected spa product shape with limited custom build. Digi stayed on a per unit billing model that would have kept the owner subscription in place. AWS IoT Core would have required the Client to build the fleet administration surface from scratch and extend firmware beyond the available development budget. Azure IoT Hub carried the same construction cost as AWS IoT Core and introduced a cloud vendor change that extended procurement timelines.

Decision 2. MQTT over SSL polling for device to cloud communication

Alternatives Clixlogix evaluated

Keep SSL polling on a longer interval to reduce bandwidth consumption
Use AMQP for device messaging
Use ThingWorx AlwaysOn protocol for all device traffic

Decision criterion

The Hardware Network Appliance running inside each spa required a protocol that carried a lightweight heartbeat, delivered remote commands within seconds of a user action in the app, and ran inside the existing CPU and memory envelope of the spa controller.

Rationale

MQTT ran inside the spa controller envelope, carried a reliable heartbeat under the ThingWorx subscription, and delivered command round trips measured in seconds. SSL polling drove bandwidth cost per unit and would have left the per unit billing model intact under ThingWorx. AMQP carried heavier framing than the Hardware Network Appliance CPU budget could absorb at the heartbeat cadence the Client required. ThingWorx AlwaysOn would have forced a wider firmware change on every legacy unit, which conflicted with the over the air repoint goal for the installed fleet.

Decision 3. One modular codebase for both brand apps

Alternatives Clixlogix evaluated

Keep four separate codebases, two platforms times two brands
Fork from a shared core per release

Decision criterion

The Client required a single engineering backlog across both consumer brands, two App Store and Google Play listings under distinct brand identity, and the ability to ship a feature once and verify once.

Rationale

One modular codebase per native platform cut the parallel build count from four to two, kept each release behind a single QA pass per platform, and let the design team swap brand assets at a configuration file level with no change to engineering code. Four separate codebases carried the duplicated engineering cost that drove the subscription in the first place. Fork per release pushed merge debt back into the engineering group on every brand divergence.

Decision 4. Over the air repoint for the installed fleet

Alternatives Clixlogix evaluated

Technician field visit per unit to repoint firmware
Dealer coordinated owner self install over Wi-Fi
Phased hardware swap during the next scheduled service call

Decision criterion

Any migration path had to clear the installed Digi fleet off per unit billing with no technician dispatch to every owner.

Rationale

An over the air repoint delivered the migration inside the normal connected session each spa opened to Digi, so the owner saw no interruption and the migration completed with no owner action. A technician visit per unit multiplied the migration cost by the fleet size and extended the subscription unwind by months. Dealer coordinated owner self install carried a completion risk the Client could not absorb at the fleet scale. Phased hardware swap tied the migration to natural service cycles and would have left the owner subscription in place for years.

Fig 3 - Over the air repoint sequence for the installed fleet

Delivery narrative

Subscription unwind architecture

The Client opened the engagement with a direct commercial goal, ending the owner subscription fee on the connected spa line. The fee existed because every unit on the Digi cloud billed the Client per unit per year, and the connected products group had passed the cost through to owners. The replatform to PTC ThingWorx on AWS replaced the per unit billing posture with a Client owned cloud subscription that priced on data volume. Clixlogix sized the ThingWorx subscription against the combined fleet, modeled the message rate under MQTT, and confirmed the data volume economics before the Architect stage closed. The owner subscription for the connected spa line came off at launch of the replatformed app, and the Client’s commercial organization repositioned the connected spa line against the connected consumer product substitutes owners compared it against.

Fig 4 - Commercial model shift from per unit cloud billing to a data volume cloud subscription

Owner Expectation Posture

The US connected consumer products market now carries explicit federal signaling on connectivity as a product feature across a device’s connected life. The FCC voluntary US Cyber Trust Mark program applies to connected consumer electronics marketed in the US and sets labeling criteria tied to the device’s security posture across its connected life. The Client’s connected spa line sits inside this category, and the replatform reseated the owner relationship on terms the connected consumer products market now expects.

Dual brand codebase consolidation

The two brand apps carry the same functional surface for connected spa owners, with brand specific identity and dealer routing. Clixlogix built a single modular codebase per native platform where the brand configuration file carries the color palette, the typography, the dealer directory binding, and the manufacturer address, and shared code decides the hardware control flow and the user experience. The release pipeline runs one engineering backlog and produces two signed store artifacts per release. Each artifact goes to Apple App Store and Google Play under its own brand identity. The Client’s engineering group now ships a feature once and verifies once, with brand divergence confined to a configuration file.

Fig 5 - Codebase consolidation from four repositories to one modular codebase per native platform

Legacy fleet migration without field dispatch

The Client carried roughly 1,400 connected spa units installed at owner locations under the Digi cloud. Clixlogix built the over the air repoint procedure inside the Harden stage, exercised it on a staging fleet, and rolled it to production in batches. Each batch of units reconnected to ThingWorx inside its normal session with no owner action and no technician dispatch. Batch confirmation gated on heartbeat count on ThingWorx and command round trip verification per unit. The complete installed fleet migrated inside the Transition stage with no field service call.

Owner installation and support routing

New spa installations under the replatform run on a barcode scan provisioning flow. The dealer or installer scans the serial on the hardware label at install, the app verifies the pairing against the ThingWorx registry, and the owner account binding completes before the first command. At activation the owner record is pushed to the Client’s existing Salesforce instance, which holds customer registration. Owner support routing inside the app sends dealer service questions to the owning dealer identified by the dealer locator and sends manufacturer questions to the Client’s support organization. The two routes cut the Client’s support load on first touch dealer tickets, and the barcode flow replaced the ad hoc install pairing that had generated support incidents on the Digi line.

Fig 6 - Owner installation and provisioning flow

Post launch results

The engagement moved the connected spa line onto an owned IoT architecture, cleared the installed fleet off the legacy cloud with no field dispatch, and retired the owner subscription fee.

1,400+ Legacy Units Migrated with No Field Visit

More than 1,400 installed spa units moved from the legacy cloud to the new IoT platform through an over the air repoint delivered inside each device's normal connection session. The rollout ran in production batches, each checked for restored heartbeat and successful command round trips before the next moved. No owner action, no hardware swap, no technician dispatch.

Owner Subscription Fee Removed on the Connected Spa Line

The legacy cloud billed the manufacturer for every connected spa each year, and that cost had been passed to owners as an annual app subscription. The replatform replaced the per unit charge with a cloud subscription priced on total data volume, modeled against fleet size before launch. The owner fee came off when the replatformed apps launched.

4 App Codebases Consolidated to One per Native Platform

The mobile estate moved from four separate repositories to two modular codebases, one per native platform. Shared engineering code carries the spa control experience while configuration resources hold each brand's identity, typography and dealer binding. One backlog, one QA cycle per platform, two signed store artifacts per release.

42% Rise in Connected Spa Sales Reported Post Launch

The Client reported a 42% rise in connected spa sales after the replatformed apps went live. The launch combined remote temperature, filtration, boost, lighting and music control with clearer device status, and the line shipped without the previous annual owner fee. The figure is a client reported post launch result and causal attribution sat outside the engagement scope.

29% Drop in Connected Spa Service Requests Reported

The Client reported a 29% drop in connected spa service requests after launch. New installations gained barcode provisioning, registry verification and a confirmed first command before the installer finished, while dealer questions route to the installing dealer and manufacturer questions to central support. The figure is a client reported result.

58% Rise in Positive Owner Feedback Reported Post Launch

The Client reported a 58% rise in positive owner feedback after the replatform. Owners received refreshed native apps with faster command delivery, visible device status and separate owner and guest roles, and the installed fleet moved across without repeating setup or scheduling a visit. The figure is a client reported post launch measure.

Forward looking recommendation

ThingWorx event rules - the next release can promote the current manufacturer alert thresholds into ThingWorx rule triggers so the Client’s support organization sees fleet anomalies before owners open tickets.
Dealer facing analytics - the dealer locator and routing data captures service and parts volume across the dealer network and can drive a dealer facing dashboard for warranty and inventory planning.
Firmware update orchestration - the replatform established an over the air route for the Hardware Network Appliance. A staged rollout tool with canary cohorts takes advantage of it at the next controller firmware release.
Pricing economics review - the data volume cloud subscription on ThingWorx opens an economic review cycle, measuring message cost per owner and planning for fleet growth under the current pricing envelope.

What the client can do now

Ship a feature across both brands with one engineering pass - the modular codebase runs one QA cycle and two store submissions per release, which keeps the engineering backlog aligned with the brand roadmap on both sides.
Extend the ThingWorx data model as the product line grows - new connected spa variants slot in under the existing device model with no cloud replatform required.
Repoint any future legacy cohort over the air - the over the air repoint procedure is a replayable operational asset covering any future cloud transition at the Hardware Network Appliance level.
Keep the owner subscription off the connected spa line - the data volume cloud economics let the Client’s commercial organization keep the connected app free to owners across the product line.

Technologies and tools

Area of the engagement	What ran there
IoT cloud for the connected spa fleet	PTC ThingWorx on AWS
Device to cloud communication protocol	MQTT, replacing the legacy SSL polling connection
Hardware Network Appliance firmware	Python
Mobile apps for the two consumer brands	Native iOS (Swift) and native Android (Java)
Backend services carrying owner, device, and dealer records	Java Spring Boot
Administrative web interface for user and device oversight	AngularJS
Relational data store for owner, dealer, device, and content records	Microsoft SQL Server
Authentication and authorization for app and admin surfaces	Spring Security with JWT
Device provisioning on new installations	Barcode scan with ThingWorx registry lookup
Customer registration record at activation	The Client’s existing Salesforce instance, receiving a record push
Owner support routing inside the app	Dealer locator service with manufacturer handoff
QA environment for replatform validation	Phased ThingWorx QA cloud with staged device cohorts

Table 2 - Technologies and tools across the connected spa engagement

Services Delivered

IoT, Mobile App Development, iOS App Development, Android App Development, Firmware Integration, Over the Air Fleet Migration

Team Composition

Solution Architect, IoT Engineer, Backend Developer, iOS Developer, Android Developer, QA Analyst, Project Manager

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.

IoT farm management platform for a MENA AgriTech operator

Building an IoT Integrated Farm Management Platform for a MENA AgriTech Operator

Digital Engineering Emerging Technologies IoT Agriculture & AgriTech Enterprise Software

Statewide EV charging platform engineering for a Florida network operator

EV Charging Platform Engineering with Route Optimization for a Florida Operator

Mobile App Development Digital Engineering Devops IT strategy consulting IoT Automotive & Mobility IT Consulting

View All IoT Case Studies