> ## 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.
# Create a Product
> The 4-step new-product wizard — every field, and how to think about what you enter.
Creating a product is the first thing you do as a manufacturer. It's a **4-step
wizard**, and the choices you make here shape everything downstream — your
firmware, your dashboard, your API, and what your users experience. This guide
walks each step and, more importantly, **how to think about each field**.
The wizard: **AI Generator → Basic Info → Commands & Actions → User Info &
Metadata**. You can skip the AI step and fill everything by hand.
## Step 1 — AI Generator (optional)
Describe your product idea in plain language and the AI scaffolds a starting
point for you — basic info, a command set, database tables, and dashboard
widgets — which you then refine in the following steps.
**How to think about it:** treat the output as a *first draft*, not the final
answer. It's fastest when your product is a common pattern (a smart light, a
thermostat, a sensor node). Describe **what the device does and what it reports**,
e.g. *"a soil-moisture sensor that reports moisture and temperature and can
trigger a water pump."* Then review every generated command and field in the next
steps — you own the result.
Prefer full control? Skip this step and build from scratch.
## Step 2 — Basic Info
The product's identity. This is how it appears everywhere — the Studio, the
marketplace, and your users' apps.
| Field | Example | How to think about it |
| -------------------- | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Product Name** | Smart Thermostat | The user-facing name. Make it clear and specific — what the thing *is*, not a codename. It shows on cards, dashboards, and the marketplace. |
| **Category** | Home, Climate, Sensor, … | Pick the closest match. It drives discovery in the marketplace and how the product is grouped. Choose the category a buyer would search. |
| **Description** | — | One or two sentences on what it does and who it's for. This is your pitch on the marketplace listing — lead with the value, not the internals. |
| **Model Number** | TH-1000 | Your internal/product SKU. Use a scheme you can extend across a lineup (e.g. `TH-1000`, `TH-2000`). This is *your* reference, not the user-facing name. |
| **Firmware Version** | 1.0.0 | The starting firmware version. Use semantic versioning (`major.minor.patch`) so OTA updates and version tracking stay clean over time. |
| **Icon** | — | A visual shorthand shown across the platform. Pick one that reads at a glance for your category. |
Name and category are the two fields buyers see first in the marketplace. Spend a
moment on them — they affect discovery and trust more than any internal field.
## Step 3 — Commands & Actions
This is the heart of the product: the **command vocabulary** your device
understands. It's organized as a tree — **Commands → Actions → Parameters** —
and it's what dashboard controls send and what your firmware handles.
### The structure
```
Command (a named capability, e.g. "GPIO_MANAGEMENT")
└─ Action (a specific operation, e.g. "ON" / "OFF")
└─ Parameter (an input to the action, e.g. gpio, status)
```
Each **Command** has a name, an **API Endpoint**, a **Method**, and a
description. Each **Action** sits under a command. Each **Parameter** has a name,
type, default value, and description.
### How to think about it
* **Model capabilities, not wires.** A command should describe *what the product
can do* ("Operate", "SetBrightness"), not a raw pin. Keep names stable — they
become your public contract with firmware, dashboards, and the API.
* **Actions are the verbs.** Under one command, actions are the distinct
operations (ON / OFF, START / STOP). If two operations are truly different,
they're different actions.
* **Parameters are the inputs.** Add a parameter only when the action needs a
value from the caller (a brightness level, a target GPIO, a duration). Give each
a sensible **default** so a basic call works without every field.
* **Design for the dashboard and firmware together.** Every command you define
here is what a [control widget](/dashboard/binding-data) will send and what your
[`setUserCommandHandler`](/learn/lessons/04-core-loop) will receive. If a
command is awkward to send from a Button or handle in firmware, simplify it now.
* **Start small.** Define the commands you'll actually use first. You can add more
later — but renaming a command after devices ship is painful.
These commands power several Studio tools: [Command Flow](/studio/flow) visualizes
them, the [Testing Suite](/studio/testing) exercises them, and
[Voice Assistants](/studio/voice-assistants) map traits to them.
## Step 4 — User Info & Metadata
The finishing details for the people who use the product.
| Field | How to think about it |
| ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **User instructions / manual** | Plain-language guidance your end users see. Write it for a non-technical owner: how to set the device up, what it does, what to do if something's wrong. |
| **Metadata** (key / value) | Custom attributes on the product — e.g. `warranty_period` → `2 years`, `voltage` → `5V`. Use it for structured facts you or integrations may want to reference later. |
**How to think about it:** the manual is the first thing a confused user reads —
keep it short and task-focused. Metadata is for *structured* facts (specs,
warranty, compliance), not prose.
## After you finish
Saving the wizard creates the product and drops you into the
[Product Development Studio](/studio/overview). From there you'll design the
dashboard, set up the database, flash firmware, and publish. If you used the AI
step, review what it generated in each Studio tab before shipping.
Every tool in the product workspace.
Build the UI your users get.
Store your device's data.
Get a device online.