Phase 1: Discovery & BLE Architecture
The first phase focused on understanding the hardware ecosystem and defining a system architecture that could support the client’s current equipment line and future product additions.
BLE Protocol Mapping and Optimisation. The team conducted a detailed audit of the client’s existing BLE communication layer. The original iOS app used a basic Core Bluetooth implementation with hardcoded service and characteristic UUIDs, minimal error handling, and no reconnection logic. Pairing was slow and unreliable, particularly on older equipment models where firmware advertised services inconsistently.
Our engineers mapped every GATT service and characteristic exposed by each device variant, documenting data payload structures, notification intervals, and characteristic write behaviours. This audit revealed that pairing delays were primarily caused by redundant service discovery passes and an overly conservative connection timeout. By restructuring the connection sequence to cache discovered services, implementing a targeted scan filter using manufacturer specific advertisement data, and introducing exponential backoff with jitter for reconnection attempts, pairing time was reduced by 35%. Post optimisation, BLE sync reliability exceeded 99% across all supported device models.
Modular System Architecture. Rather than building the current equipment line alone, the team designed a device abstraction layer that treats each piece of hardware as a pluggable data source. Each equipment type registers its own BLE profile handler, defining which characteristics to subscribe to, how to parse incoming byte arrays into structured metric objects (speed, distance, calories, duration, resistance level), and what fallback behaviours to invoke on disconnection.
This architecture means onboarding a new piece of exercise equipment requires writing a single profile handler and registering it with the device manager. No changes to the app’s core data pipeline, UI rendering, or analytics ingestion are needed. The team validated this by integrating a prototype profile for an unreleased desk cycle model during the discovery phase itself, confirming the abstraction held under real conditions.
Phase 2: Cross Platform Application Development
With the architecture defined, the team moved into full stack development. The key engineering decisions at this stage centred on framework selection, state management, and the separation between mobile and web concerns.
Flutter for iOS, Android, and Web. Flutter was selected after evaluating it against React Native and native per platform builds. The deciding factors were Flutter’s compiled to native performance (critical for realtime BLE data rendering), its single widget tree approach that eliminated UI parity issues between iOS and Android, and its web compilation target which allowed the team to ship the end user facing web experience from the same codebase. This decision reduced total frontend development effort by approximately 40% compared to maintaining separate native codebases.
The Flutter app was structured using BLoC (Business Logic Component) pattern for state management, separating BLE device state, workout session state, user profile state, and social/leaderboard state into independent, testable streams. This made it possible for multiple developers to work on the gamification layer, the BLE integration layer, and the reporting module simultaneously without merge conflicts or tightly coupled dependencies.
React Web Dashboard for Enterprise Administration. The admin and coach dashboard was built as a standalone React application consuming the same NestJS API. Corporate wellness administrators can view aggregated engagement metrics across teams, set organisation wide challenges, export compliance ready activity reports, and manage user groups. The dashboard was designed for role based access: programme administrators, team coaches, and individual employees each see a scoped view of the data.
Backend: Node.js + NestJS + PostgreSQL. The backend was built on NestJS for its modular, decorator driven architecture, which aligned well with the domain separation already defined in the Flutter app. PostgreSQL was chosen for its JSONB support (useful for storing flexible workout metadata and device telemetry), strong indexing performance for time series queries, and native support for full text search on user generated content like challenge descriptions and workout notes. Authentication was implemented via OAuth 2.0 with JWT, supporting SSO through email, Google, Apple ID, and Facebook.
Phase 3: Engagement & Gamification Engineering
The client’s original app displayed workout metrics in a static dashboard. Users logged in, saw numbers, and left. There was no reason to return unless they were actively using the equipment. The engagement layer was designed to change that equation.
Retention Loop Design. The team designed a three tier engagement model. At the individual level: daily, weekly, and monthly goal setting with visual progress arcs and streak tracking. At the social level: group challenges where teams compete on cumulative metrics (total calories, total minutes, total distance) over defined periods. At the competitive level: ranked leaderboards with tiered badges and achievement milestones that unlock at specific activity thresholds.
Each tier was instrumented with event tracking from day one. Every goal set, challenge joined, leaderboard viewed, and badge earned emitted a structured event to Firebase Analytics and Segment, allowing the team to measure which features drove return visits and which were ignored. Early beta data showed users exposed to group challenges returned 2 to 3x more frequently than those using the app in solo mode.
Push Notification Intelligence. Rather than scheduling notifications on fixed intervals, the team built a pattern detection layer that analysed each user’s historical workout times, session frequency, and equipment preferences. Notifications were dispatched at the times a user was most likely to exercise, with content tailored to their current goal progress. A user three sessions away from completing a weekly challenge would receive a different prompt than one who hadn’t logged in for a week. Notification delivery was handled through Firebase Cloud Messaging (FCM) for Android and web, and Apple Push Notification Service (APNS) for iOS.
Real Time Data Visualisation. During active workout sessions, the app renders BLE streamed metrics in real time: a live speed gauge, cumulative distance and calorie counters, elapsed time, and a session intensity graph that updates every second. The visualisation layer was built to handle variable BLE notification intervals (different equipment models report at different frequencies) by normalising incoming data against a consistent 1 second render tick. If a BLE notification is delayed, the UI interpolates based on the last known data point rather than showing a stutter or blank frame.
Phase 4: Staged Rollout & Continuous Delivery
The launch was deliberately staged to control quality and gather structured feedback before broad availability.
Beta Programme. The app was distributed to an initial beta cohort via TestFlight (iOS) and Google Play Store internal testing tracks. The beta programme attracted over 5,000 registrations, providing a substantial feedback base. The team ran three beta iterations over four weeks, each addressing specific clusters of reported issues: BLE reconnection edge cases on older Android devices, UI rendering inconsistencies on tablets, and notification permission flows that differed between iOS 16 and 17.
CI/CD Pipeline. A continuous integration and deployment pipeline was established to support a weekly release cadence. Every commit triggered automated unit tests across the BLoC state management layer, integration tests against the NestJS API, and UI regression tests on iOS and Android emulators. Builds that passed all gates were automatically promoted to TestFlight and Play Store internal tracks. Production releases were gated by manual QA sign off and client approval, ensuring no build shipped without explicit stakeholder review.
Post Launch Iteration. Within three months of public launch, the app exceeded 20,000 downloads on the App Store. The weekly release cycle allowed the team to respond rapidly to user feedback, shipping refinements to the goal tracking UI, adding export to CSV functionality for workout reports (a request from enterprise clients), and tuning the notification timing algorithm based on two months of production behavioural data.
DM Us
