# Choosing a path

Choose between a branded desktop binary and running WAMP behind a product you already operate.

Source: https://docs.vampikez.fun/ship/choosing-a-path/

You have an extension that builds and runs. This page decides where it goes.
Choose by what your users need to run. A branded Desktop product uses the
extension artifact; a backend integration uses the HTTP API and does not need
an extension. `wamp ext install` installs a build into your own Desktop, but it
is a local authoring step rather than a distribution channel.

## What your users download

| | **Branded desktop product** | **Your own product** |
|---|---|---|
| They download | your app, as its own installer, with its own name, icon and window | whatever you already ship; nothing of WAMP is visible |
| They need a WAMP install | no — your binary *is* the install | no |
| You maintain | one extension plus a product file and a release feed | your product; WAMP is a dependency of your backend |
| Execution and identity | Agent runtime in your binary; users sign in with WAMP | Your backend or client calls the model proxy, or starts managed Cloud sessions |
| Distribution | your own download page and update feed | your existing release channel |

## The questions that decide

**Are you only installing the extension for yourself?** Keep using `wamp ext
dev` and `wamp ext install`; there is nothing to ship. The public catalog is
published through the WAMP operator's maintained workflow.

**Is your extension the whole product?** A product wants its own window, its own
name in the dock, and no WAMP chrome around it. Build a branded product and set
`rootPageId` to one of your pages so it boots straight into it.

**Do you already have a server and a user directory?** If yes, use your own
product. You are not
looking for an app shell — you have one. You want metered model access with
per-end-user attribution, which is exactly what an app principal gives you, and
none of it requires shipping a desktop binary.

## Identity follows the distribution path

A branded Desktop product is a WAMP client: its users sign in with WAMP, and
the product receives the same account-backed platform services as the default
Desktop. Identity is not configurable in `product.json`.

If your product already owns its users, keep that identity in your own backend
and mint app-signed end-user tokens for model access. That is the backend path,
not a second Desktop account mode. See [Your own backend](/ship/own-backend/).

## What remains identical

Local installation and a branded Desktop product share the extension: same
[manifest](/build/manifest/), same [permissions](/build/permissions/), same
[plugin API](/build/plugin-api/), same build. A branded product bundles the same
staged artifact that `wamp ext install` validates, so there is no second version
of the extension to maintain.

## Where each path stands today

Read this before you commit to a path — the two are not equally finished.

**Branded desktop product.** The product file, the build pipeline, and the
release upload script all live inside the WAMP monorepo, so producing a branded
binary requires access to that repository today. Signing, notarization, release-build update gating, and artifact architecture
are covered in
[Branded desktop product](/ship/branded-product/).

**Your own product.** The HTTP integration is available, but `@wamp/app-sdk` is not published to npm, so today you either vendor
the package or call the endpoints directly. The token you have to mint is a
signed JWT with four claims, which is a short function in any language — see
[Your own backend](/ship/own-backend/) for the contract and a worked example.

## Not on this page

Running agents on WAMP's own infrastructure rather than on a user's machine — a
durable session driven from a CRM, a bot, or a scheduler — is a separate product
with its own documentation at
[docs.cloud.vampikez.fun](https://docs.cloud.vampikez.fun). It is orthogonal to
the two paths here: a branded product and your own backend can each drive Cloud
sessions.