Sensors in the Field, No Visibility, and Half the Mobile Market Uncovered
Connected hardware products often ship with mobile coverage for one platform and a gap on the other. This engagement started exactly there. The client made pool and water monitoring devices that measured free chlorine, pH, and flow in real time. An iOS app was live in the store. There was no Android app at all, and a significant portion of their consumer base was on Android.
The second problem was operational. The devices were generating data continuously, but the operations team had no structured way to query across the fleet. Which units reported all three readings yesterday? Which consumed consumables faster than expected? Which went quiet? Which showed motor anomalies alongside missing reads? The answers were in a database that required a developer to reach.
These are two of the most common gaps Sequoia sees in growing IoT product companies: incomplete platform coverage and device data that operations staff cannot access without engineering involvement.
Two Parallel Workstreams, One Coherent IoT Solution
Sequoia Applied Technologies is a Santa Clara software engineering firm that builds IoT mobile products and analytics systems for hardware companies across cleantech, life sciences, and enterprise software. This engagement ran as two separate statements of work with distinct scopes, delivered concurrently.
The Android app was built from the iOS reference already in the App Store and from AdobeXD design files the client provided. The client supplied all graphics; Sequoia handled the engineering, code documentation, and Google Play submission. Matching an existing iOS product on Android is not a simple port. Device fragmentation means the experience has to be validated across a range of actual hardware models. That validation was built into the process from the start.
The analytics workstream had a different character. The client already had a Tableau license. The question was how to get device data into it without building a custom analytics layer. Sequoia used a CData driver to bridge the device database to the existing Tableau environment. Before committing to the full query build, the first deliverable was deliberately constrained: pull one report from the test database through the CData connector in the actual client setup. That proof-of-concept step confirms the integration path works before any broader development begins. It is a discipline worth keeping regardless of how tractable the initial setup looks.
From there, Sequoia built up to fifteen predefined queries covering the operational questions the team needed answered daily. All source code and IP transferred to the client at completion, with documentation written so the team could own the system going forward.
What the IoT Solution Covers
The two workstreams share the same deployed device infrastructure as their data source but are architecturally independent. The Android app communicates with the backend via REST API. The Tableau analytics layer reaches the device database directly through the CData connector. Neither depends on the other to function, which matters for maintenance and for extending either system separately.
Built from the iOS reference app and AdobeXD design files. Client supplied all graphics. Sequoia handled engineering, code documentation, and Google Play submission. Validated across a range of Android hardware models. Core consumer flows and visual design match the iOS product.
CData driver connecting the device database to the client's existing Tableau license. First deliverable was a scoped proof of concept: one report pulled from the test environment through the connector. Full query build followed, covering up to fifteen predefined device fleet views. Extensible by the client's team without outside help.
Queries covering: units reporting FCL, pH, and flow readings daily; units consuming more than three pads; units missing all three readings versus partial misses; and units showing elevated motor current alongside missing sensor data. That last combination flags a specific hardware condition for field follow-up. Up to fifteen queries in scope.
All source code, connector configuration, and technical documentation delivered to the client at close. Full IP transfer on both statements of work. Documented so an engineer new to the codebase can operate and extend both the app and the analytics layer independently.
The Tableau-plus-CData approach is well suited to IoT companies that already hold a Tableau license and want to surface device data for operational reporting without building a custom analytics layer from scratch. The same pattern applies beyond pool monitoring to any connected product where operations needs per-unit visibility across a deployed fleet.
IoT Mobile Apps and Fleet Analytics: Common Questions
Can you build an Android companion app for an IoT hardware product that already has iOS?
Yes. Sequoia has done this on connected hardware products where an iOS app was in the market and Android coverage was absent. The work starts from the existing iOS reference and the design files the client provides, runs through Google Play submission, and validates across a range of Android hardware models. Device fragmentation on Android shows up in testing, not planning, and coverage has to hold across actual devices in the field rather than a simulator.
How do you connect IoT sensor data to Tableau for fleet reporting?
The approach used here was a CData driver connecting the device database to an existing Tableau environment. The first deliverable was a proof of concept: pull one report from the test database through the connector before expanding to the full query set. That step confirms the integration works in the real environment before committing to the broader build. It is worth doing even when the path looks straightforward on paper.
What kinds of IoT fleet queries can Tableau surface?
For this pool monitoring engagement, the queries covered daily reporting counts for FCL, pH, and flow; consumable usage rates; units missing one, two, or all three readings; and units with elevated motor current alongside missing sensor data. That last pattern points to a specific device state worth field investigation. The same query logic applies to any connected product where an operations team needs per-unit visibility across a fleet, not just aggregate trends.
What does Sequoia deliver at the end of an IoT software engagement?
Source code, technical documentation, and any configuration or connector files needed to operate the system. All IP transfers to the client at completion. For this engagement that included the Android app codebase, the Tableau CData connector setup, the full query set, and written documentation thorough enough that a new engineer could take ownership without a handoff call.
What IoT and connected hardware companies does Sequoia Applied Technologies work with?
Sequoia Applied Technologies is a Santa Clara, California software engineering firm. IoT engagements span consumer hardware, smart water and environmental monitoring, cleantech, industrial equipment, and life sciences devices. Work typically involves mobile companion apps, cloud-connected device pipelines, analytics and reporting layers, and QA across deployed device fleets.