Infrastructure for connected products
Everything between a working device and a paying customer
is undifferentiated infrastructure. Hyperwisor is that infrastructure — firmware, dashboards, apps, distribution and payments — so hardware teams can spend their time on hardware.
product-studio
Devices
1,284
Online
1,197
Commands / hr
48.6k
Throughput
Device
State
Uptime
a41f-0e77
99.2%
8c30-b512
97.8%
2d94-77af
—
f60b-31c8
99.9%
End to end
One platform under the whole chain
A manufacturer defines a product once. It's built into many devices. Each device belongs to a user, who reaches it through whichever surface you decide to ship — and commands travel back down the same channel.
The integration tax
A shippable product needs all of this
Every row is weeks of work and a permanent maintenance liability. None of it is what makes your product good.
Layer
Build it yourself
Here
Device connectivity
Provisioning UI, a realtime server, reconnection, heartbeats
OTA updates
Signed firmware pipeline, partitioning, rollback
Dashboard
A web app, live data binding, a widget library, theming
Database
Schema, storage, per-user access rules
Accounts & onboarding
Auth, device-to-user linking, QR provisioning
Mobile app
A branded iOS/Android app, store submissions, updates
Distribution
A storefront, licensing, order and fulfilment tracking
Payments
A gateway, revenue splitting, payouts, tax
Core concepts
Four ideas, and the rest follows
One product design becomes many physical devices. Each belongs to a user. Each user sees a dashboard. The platform makes no assumption about what the hardware actually is.
01
Product
The design, not the object. Commands, database schema, dashboard and firmware bundled into one reusable template.
02
Device
One physical unit running that product's firmware. It emits values and receives commands — nothing more is asked of it.
03
User
Owns one or more devices, onboarded by scanning a code, and controls them through the dashboard that shipped with the product.
04
Dashboard
A canvas of widgets bound to device data. Ships with the product, or gets built by a user across everything they own.
Getting to your users
Four ways in, one platform behind them
Ship on ours, ship on yours, build it yourself, or put it inside someone else's product. The device, the data and the realtime channel are the same underneath — only the surface changes.
The Hyperwisor app
Your customer installs the app, scans the QR on the unit, and the device is live. Nothing to build, nothing to submit to a store.
AI Insights, built in
Owners ask questions of their own device data in plain language — trends, anomalies, comparisons — and get a readable answer back. No dashboards to configure, no SQL. Voice mode reads it aloud hands-free.
"Have there been any unusual fluctuations this week?"
Your own app
Clone the app starter, set your branding, and ship web and native from one codebase — already wired to the manufacturer API and the realtime relay.
Boots in mock mode. Explore with fake devices before adding a single key.
One config file. Branding, theme and single- or multi-product scope.
Real React screens. Editable code you own, not a locked widget grid.
The manufacturer API
The authenticated REST surface underneath everything else. Build whatever front end you want, or wire devices into tooling you already run.
x-secret-key: msk_…
The secret key stays on a server you control — never in a browser bundle.
API referenceInside your platform
If you run a PCB tool, a hardware shop or a builder, offer Hyperwisor as your "Connect IoT" layer. Your users never leave your interface.
Connect
One-click OAuth — they sign in to Hyperwisor once.
Create
Their project becomes an IoT product they own.
Ship
You render the QR in your own UI; their customer scans it.
Dashboard designer
Build the screen, not the front end
Drop a widget on the canvas, give it an ID, and it reads values and sends commands in both directions. The dashboard ships with the product — changing it doesn't need an app release.
Drop
Pull a widget onto a grid that lines itself up.
Bind
An ID is the whole contract between firmware and screen.
Publish
Every unit inherits it, without shipping a new build.
tempGauge
pumpSwitch
flowRate
12.8L/m
Product studio
A workspace per product
Grouped by the stage you're actually in, from first sketch to settled revenue.
Monitor
Live device state, database, users, rules, quotas, revenue and command flow.
Design
The dashboard designer — build the interface your users get, and publish it without an app release.
Develop
Code generator, device simulator, server-side processes, API commands and keys, circuit builder.
Test
Exercise API commands and device responses before anything reaches a customer.
Deploy
QR distribution, voice assistant integrations, firmware versions and OTA rollout.
Earn
List the product, license the design, charge for actions, and track what settles back.
For developers
One loop holds it together
Firmware and dashboard widgets share a widget ID. Push a value to that ID and the widget updates. The widget sends a command and your handler receives it. That's the whole contract — a thermostat, a soil sensor and a drone all run it.
Developer referenceFirmware
device.updateWidget(
targetId,
"tempGauge",
27.4
);Widget
tempGauge
26.9°C
27.4°C
Handler
device.setUserCommandHandler(
[](JsonObject &msg) {
// drive a GPIO…
}
);pumpSwitch
Pump
Honest fit
When this isn't the right tool
You must own the entire stack on your own metal for regulatory or contractual reasons.
It's a one-off internal gadget with no users and no product ambitions.
It's an ultra-low-level or hard-real-time control loop that belongs in firmware regardless of platform.
If none of those apply, the maths favours building here.
Build the product, not the platform
Create a product, wire up a board, and see it on a dashboard.