Full Product Ecosystem for Connected-Hardware Brands
How we productized an app, backend, OTA, and subscription blueprint delivered across two device brands
Executive Summary
Running the ecosystem on separate devices and infrastructure
Users on the lead brand, tens of thousands on the second
Second brand launch by reusing the proven blueprint, vs 3 months for the first
Repos delivered and operated across apps, backend, backoffice, and web
The Challenge
Consumer hardware brands can source a physical BLE device, but shipping a true connected product requires far more than hardware: native mobile apps, backend services, realtime infrastructure, a backoffice, firmware update workflows, subscription revenue infrastructure, marketing surfaces, analytics, and firmware-level protocol discipline. Without this ecosystem, connected-hardware teams face expensive operational risk. If OTA firmware updates are missing, every serious firmware issue can become a recall. Without server-side receipt verification, subscription revenue leaks. Without feature flags and remote settings, every configuration change waits for a 1-2 week app-store release. Without a shared BLE protocol contract, iOS and Android can drift and break devices in the field. The alternative would have required hiring separate iOS, Android, backend, web, firmware, and DevOps capability per brand. Amasa faced this challenge twice — two separate consumer connected-hardware brands, both greenfield software builds, neither with an internal engineering organization.
Key Pain Points
- ✕Firmware issues without OTA updates can turn into physical recalls
- ✕Subscription revenue leaks without server-side receipt verification
- ✕Every config change waits 1-2 weeks for an app-store release without feature flags
- ✕iOS and Android protocol drift can break devices in the field
- ✕Hiring iOS, Android, backend, web, firmware, and DevOps teams per brand is prohibitive
Our Solution
Amasa built a reusable 5-6 repo ecosystem per brand: a Node.js and TypeScript backend with MongoDB, AWS Cognito, S3, and an in-process Aedes MQTT broker; native Swift iOS and Kotlin Android apps; a React backoffice; and a React marketing website — with a consistent API response envelope and cross-repo contracts keeping every surface aligned. The ecosystem includes a custom BLE V2 protocol with brand-specific UUIDs, 3-byte command and response headers, checksum validation, 13 preset modes, direct PWM control, and custom-pattern modes, enforced byte-for-byte across iOS and Android. OTA firmware updates over BLE run through a dedicated GATT service and a backend firmware-matrix API that decides which device receives which firmware version — fleet firmware management without physical recalls. Partner Connect gives paired users real-time remote control via MQTT with QoS 2 for control events. Apple and Google in-app purchases are server-verified with tiered content access and context-aware paywalls, and brand teams manage content, moderation, firmware versions, feature flags, and remote app settings from the backoffice. The first brand took roughly 3 months to reach a full ecosystem; the second took roughly 6 weeks by reusing the proven blueprint while keeping separate devices, infrastructure, branding, and content.
Implementation Approach
Blueprint Architecture
Designed the 5-6 repo per-brand ecosystem with a consistent API envelope and cross-repo contracts
Protocol & OTA Foundation
Built the custom BLE V2 protocol enforced across platforms and OTA-over-BLE with a server-side firmware matrix
Revenue & Control Surfaces
Shipped server-verified Apple/Google IAP, tiered paywalls, feature flags, remote settings, and the backoffice
Second-Brand Replication
Reused the validated blueprint to launch brand two in ~6 weeks with separate devices, infrastructure, and content
The Results
The implementation delivered transformative results across all key metrics, with immediate impact on operational efficiency, accuracy, and customer satisfaction.
Impact Metrics
| Metric | Before | After | Improvement |
|---|---|---|---|
| Firmware updates | Physical recall or no path | OTA over BLE with per-device targeting | Recall-free |
| Config rollout | 1-2 week app-store cycle | Instant via feature flags and remote settings | Instant rollout/rollback |
| Revenue infrastructure | No subscription system | Server-verified Apple/Google IAP with tiered paywalls | Leak-free subscriptions |
| Time to launch | ~3 months for the first brand | ~6 weeks for the second | 2x faster |
Key Takeaways
- A connected-hardware software stack can be productized and repeated across brands — the second launch took half the time
- OTA-over-BLE with a server-side firmware matrix turns potential recalls into silent fixes
- Feature flags and remote settings collapse 1-2 week app-store cycles into instant rollout and rollback
- Owning the BLE protocol spec makes manufacturers replaceable — suppliers conform to the brand's app and backend contracts
Inside the Engagement
The Risk Without an Ecosystem
Without a software ecosystem, connected-hardware teams face expensive operational risk. If OTA firmware updates are missing, every serious firmware issue can become a recall. Without server-side receipt verification, subscription revenue leaks. Without feature flags and remote settings, every configuration change waits for a 1–2 week app-store release. Without a shared BLE protocol contract, iOS and Android can drift and break devices in the field. The alternative would have required hiring separate iOS, Android, backend, web, firmware, and DevOps capability per brand.
Flagship Capabilities
- Custom BLE V2 protocol with brand-specific service and characteristic UUIDs, 3-byte command and response headers, checksum validation, 13 preset modes, direct PWM control, and custom-pattern modes – enforced byte-for-byte across iOS and Android.
- OTA firmware over BLE through a dedicated OTA GATT service and a backend firmware-matrix API deciding which device receives which firmware version – fleet firmware management without physical recalls.
- Partner Connect: real-time remote control between paired users through CourierMQTT clients with WebSocket transport, QoS 2 for control events and QoS 0 for near-realtime touch points.
- Revenue infrastructure: Apple and Google in-app purchases with server-side receipt verification, tiered content access, and context-aware paywalls.
- Backoffice control: content editing, public-pattern moderation, firmware version management, feature-flag toggles, and remote app settings.
The Repeatability Proof
The first brand took roughly 3 months to reach a full ecosystem. The second brand took roughly 6 weeks, because Amasa reused the proven blueprint for BLE protocol design, MQTT partner connect, in-app purchases, backoffice patterns, feature flags, and OTA management. Each brand kept separate devices, infrastructure, branding, and content while reusing a validated engineering architecture.
The Workflow After
- The hardware brand defines the connected-device experience and business model.
- Amasa implements the backend, mobile apps, backoffice, marketing surface, realtime layer, and BLE protocol contracts.
- The brand team manages content, firmware rollout, remote settings, paywalls, and subscriptions through the backoffice.
- Consumers control the device, use partner remote-control features, consume premium content, and receive firmware updates over BLE.
- Amasa operates and extends the ecosystem across maintenance and roadmap retainers.
Full Results
| Metric | Before | After |
|---|---|---|
| Brands running the ecosystem | 0 | 2 separate brands, separate devices, separate infrastructure |
| Codebases delivered and operated | 0 | 10–11 repos across two brands |
| Users | Greenfield | 100K+ on the lead brand; tens of thousands on the second |
| Firmware update turnaround | Physical recall or no path | OTA over BLE with server-controlled per-device targeting |
| Config and feature rollout | 1–2 week app-store release cycle | Instant rollout and rollback through feature flags and remote settings |
| Revenue infrastructure | No subscription system | Server-verified Apple/Google IAP with tiered paywalls |
The Impact
Neither brand had to build iOS, Android, backend, web, firmware, or DevOps teams. Device experiences became software-led: partner remote control, premium content, subscriptions, silent firmware fixes, and remote configuration. The architecture proved repeatable – the second brand launched in half the time because Amasa had already productized the connected-hardware platform pattern. And owning the BLE protocol spec made manufacturers more replaceable, because suppliers must conform to the brand’s app and backend contracts.
The Takeaway
Amasa gives BLE hardware brands the apps, backend, realtime layer, OTA firmware updates, subscriptions, backoffice, and protocol control needed to launch connected products without hiring four platform teams – proven across two brands, 100K+ users, and 10–11 operated repos.
Quick Facts
Industry
Consumer Hardware
Solution Type
IoT & Connected Devices
Published
August 24, 2026
Technologies Used
Related Resources
Ready to Achieve Similar Results?
Let's discuss how we can transform your business with AI solutions tailored to your specific needs