> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hyperwisor.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Why Hyperwisor

> The full case — what you'd otherwise build, what Hyperwisor gives you, who it's for, and when it isn't.

The [Introduction](/learn/introduction) makes the short case. This page makes the
full one — including where Hyperwisor *isn't* the right tool, because you should
know that before you invest.

## The thesis

> Hardware people should spend their time on hardware. Everything between a
> working device and a paying customer is undifferentiated infrastructure —
> and Hyperwisor is that infrastructure, so you don't rebuild it.

The value isn't any single feature. It's that the **whole chain** — firmware →
connectivity → dashboard → app → onboarding → distribution → payments — is one
platform that already fits together. You skip the integration tax.

## What you'd otherwise build (and maintain)

A realistic "build it yourself" checklist for a shippable IoT product:

| Layer                 | Roll-your-own reality                                              |
| --------------------- | ------------------------------------------------------------------ |
| Device connectivity   | Wi-Fi 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/fulfillment tracking                |
| Payments              | A gateway, revenue splitting, payouts, tax                         |

Every row is weeks of work and a permanent maintenance liability. None of it is
what makes *your* product good.

## What Hyperwisor gives you instead

<CardGroup cols={2}>
  <Card title="Firmware SDK" icon="microchip" href="/firmware/overview">
    `device.begin()` and you're provisioned, connected, and OTA-ready. Push a
    value to a widget in one call.
  </Card>

  <Card title="No-code dashboards" icon="table-cells" href="/dashboard/overview">
    50+ widgets. Bind to device data, send commands back — no front-end build.
  </Card>

  <Card title="Product Studio" icon="grip" href="/studio/overview">
    Database, users, rules, testing, voice assistants, backend jobs — per product.
  </Card>

  <Card title="White-label app" icon="mobile-screen" href="/apps/overview">
    A branded web + mobile app for your device line, screens AI-generated.
  </Card>

  <Card title="Marketplace" icon="store" href="/monetization/marketplace">
    List and sell your product as a template — software, hardware bundle, or a
    manufacturer kit.
  </Card>

  <Card title="Built-in payments" icon="credit-card" href="/monetization/overview">
    Charge for actions, sell products, take revenue — settlement handled.
  </Card>
</CardGroup>

## The part no one else does: the business layer

Most IoT tooling stops at "your device is connected." Hyperwisor keeps going to
**"your product is sold and earning."** That's the real differentiator:

* **Marketplace** — turn one design into a product other people (and other
  manufacturers) can buy and clone. See [licensing](/monetization/licensing).
* **White-label apps** — ship *your brand's* app without building one.
* **Payments & revenue sharing** — a flat, predictable fee; you keep the rest.

This is the "infrastructure once, every vertical on top" model — the same shape
as Stripe for payments or Shopify for commerce, applied to IoT hardware. Build
the primitive once; let it carry any product in any vertical.

## You keep what matters

<CardGroup cols={3}>
  <Card title="Your firmware" icon="code">
    Your device logic is yours. The SDK is a client, not a cage.
  </Card>

  <Card title="Your customers" icon="users">
    Your brand, your users — the white-label app is yours to ship.
  </Card>

  <Card title="Your product" icon="box">
    Your design, your IP. The platform distributes it; it doesn't own it.
  </Card>
</CardGroup>

## Which boards?

Turnkey firmware SDKs ship for **ESP32-class** chips today — and board support is
**actively expanding**, with more platforms on the way. Under the hood, devices
connect over **standard IoT protocols — WebSocket, MQTT, or HTTPS** — so **any
board that can speak one of them can already talk to the platform**. You just wire
up the protocol yourself instead of using a drop-in SDK.

<Note>
  Building on a different board, or planning **mass production**? Reach out at
  [support@nikolaindustry.com](mailto:support@nikolaindustry.com) — we'll help you
  get it connected, and we prioritize board support around real production plans.
</Note>

## Who it's for

**A great fit if you:**

* Build (or want to build) **connected devices** and want them to be *products*, not prototypes
* Want to reach users without building a web app, a mobile app, and a backend
* Want a path to **sell** your product or license your design
* Are a small team or solo maker who can't staff a full platform build
* Are an integrator assembling multi-device dashboards for clients

## When Hyperwisor isn't the right tool

Honesty first — it's not for everything:

* **You need to own the entire stack on your own metal.** If regulatory or
  contractual reasons require self-hosting everything, a managed platform is a
  poor fit.
* **A one-off internal gadget with no users or product ambitions.** If you just
  need a personal device to log to a script, the full product stack is overkill.
* **Ultra-low-level or hard-real-time control loops** that must live entirely on
  the device — those belong in firmware regardless of platform.

If none of those apply, the math favors building here.

## The bottom line

You can spend the next few months building infrastructure, or the next few days
building your product. Hyperwisor exists so hardware teams choose the second one.

<CardGroup cols={2}>
  <Card title="See how it works" icon="diagram-project" href="/learn/how-it-works">
    The one idea behind the whole platform.
  </Card>

  <Card title="Create your first product" icon="wrench" href="/studio/create-product">
    Start building — with guidance on every choice.
  </Card>
</CardGroup>