Desde

What is Desde?

Desde is two programs for runnable prototypes. A local editor that changes real source code, and a self-hosted app for review.

Desde is for teams whose prototypes are real running front-end apps rather than design files. It gives you two things. A local tool for changing that prototype by pointing at it, and a self-hosted app for putting it in front of teammates and collecting their comments.

They are separate programs. Neither one needs the other, and you can use either on its own.

Editor#

Editor is an app you run on your own machine, against a checkout of your prototype's repository. It starts your prototype's own dev server, shows the running app in a browser panel, and lets you select an element, inspect it, change it, or describe the change in chat.

Every change is written into your source files as an ordinary uncommitted edit. It is the same thing you would see if you had typed it in your code editor, on whatever branch you have checked out. You commit it with git when you are ready.

Start with the Editor quickstart.

Viewer#

Viewer is a web app you host yourself. One Node process, on a machine your team can reach. It connects to a GitHub repository, builds the prototype, serves it at a URL, and wraps it in review tooling: comments pinned to specific elements on the page, replies, mentions and email notifications.

Reviewers sign in and leave feedback without touching your machine. Comments survive a layout change, because they anchor to the element rather than to screen coordinates.

Start with the Viewer quickstart.

Which one do you want#

If you are the person who would fix the thing being complained about, you want Editor. If you are the person doing the complaining, you want a Viewer link from whoever set it up.

Editor Viewer
What it is An app on your machine A web app you host
Where it runs Your laptop, bound to 127.0.0.1 A server your team can reach
Default ports 4321 for the editor UI, 5173 for your dev server 3100
Who it is for The one person making changes Everyone reviewing them
What it shows Your prototype's live dev server, with hot reload A built snapshot of a specific commit
What it changes Your prototype's source files, in place Nothing. It never modifies prototype source
State it keeps Files in your repo: uncommitted edits, plus a .desde/ folder for backups, chat sessions and cached manifests A SQLite database and built assets on disk, under VIEWER_DATA_DIR (default .desde-viewer)
Auth None. Single user, localhost only, protected by a token generated fresh at each boot plus a browser origin check Invite-only. People sign in through a GitHub App, an invite link, a magic link or an admin-minted link; machines use dsv_ tokens
Needs a network Not for selecting, inspecting or deterministic edits. Yes for AI features, cloning a repo, attaching or refreshing a design system, and optional comment sync Yes, for GitHub and the reviewers' browsers

Using both#

They work in sequence, not at the same time.

Warning Do not run Editor and Viewer against the same prototype simultaneously. Editor supervises a live dev server and writes to your working tree. Viewer serves a built, frozen snapshot. Pointing both at one prototype at once means reviewers are commenting on a build that no longer matches the source you are editing.

The working loop is: edit in Editor, commit and push, let Viewer build the pushed commit, and collect review comments there. Then bring the feedback back into Editor for the next round.

See the combined quickstart.

The problem it solves#

A prototype that already runs is usually 80% done. The remaining 20% is polish. The label is wrong, the spacing is off by one step, this card should use the outlined variant, that empty state needs a different tone. Doing that work in a design file means redrawing something that already exists. Doing it in code means a round-trip through an engineer, or through a file tree you did not write.

Editor closes that loop by making the running prototype the thing you point at, while keeping the output production-shaped: components from your design system, props your engineers already use, code your team can read in a pull request. Nothing is exported or translated afterwards, because the source is what you edited.

What makes it different#

Most visual editors either write inline styles onto whatever DOM node you clicked, or ask a language model to guess which line of source to change. Desde does neither by default.

It reads your design system's own type declarations, the .d.ts files the library ships inside node_modules, through the TypeScript compiler. From those it builds a manifest for each component: its real props and its variant options. A manifest is a machine-readable description of a component. That part is free. Nothing is hand-written per library, and nothing needs the library's source code.

Knowing where a given prop ends up in the rendered output is a second, thinner layer called a rendering hint. Those cannot be read out of type declarations, because type declarations say nothing about rendered DOM. A couple ship hand-written, more are inferred from your own components, and the rest are generated on request by probing the running app.

Together they are what make selection meaningful. When you click a piece of text on the page, Desde can route back from the rendered DOM to the prop that produced it. Editing the words in an <EmptyState> changes its title prop, not a text node the framework will overwrite on the next render. Most edits are then a direct, deterministic change to the source file. A language model is engaged only for the cases that string-editing cannot do safely, such as a value that comes from a variable defined in another file.

Read more in design-system grounding and deterministic editing.

Where this is today#

Warning Desde is pre-release. Nothing is published to npm, and there is no public download yet. Both programs run from a checkout of the Desde repository.

Concretely, as of 2026-08-31:

  • Editor edits Vue 3 and React source. It starts the dev server for you on plain Vite, Nuxt, React Router and Next.js. Astro works but is off by default. SvelteKit, Svelte, Angular, webpack and Create React App are not supported.
  • Editor is single-user, on one machine. It has no accounts and no multiplayer.
  • A macOS desktop build exists and is signed and notarized, but has not been released. Until it is, you build it yourself. See the Editor quickstart.
  • The canvas and screenshot-plan features are off by default.
  • Viewer has not yet been used by a team outside the project.

Full details in Editor limits.

Where to go next#