DocsSell
Selling on UpFork
Selling end to end: applying, the product's shape and its rules, the registry item UpFork makes from your folder, the live preview, the install check and its common failures, the review, the listing, releases and updates, and getting paid in USDT.
Updated This page as Markdown
Selling on UpFork takes your project's folder to a product on sale. UpFork builds its live preview from your code, installs it the way a buyer will on every save, serves it from its shadcn registry to the CLI and to AI assistants, and buyers pay your own wallet. This page is the whole path, in order; Selling a component is the editor's own guide to the same steps.
What it solves
The problem. Selling code yourself means a store, a site for previews, a license, a way to deliver updates, a bug tracker and payments, all before anyone knows your code even installs into their project.
What you get. You drop the folder. UpFork turns it into a live preview, checks the install with the real shadcn CLI and strict TypeScript on every save, gives it an address the CLI and AI assistants install from, and collects reviews and bug reports only from people who have it. Buyers pay in USDT straight to your wallet.
How it grows. Every install and download is counted on the product and on your developer page. Reviews, answered bugs and your articles build a record that your PDF résumé prints and anyone can check, and each version you publish reaches everyone who has or watches the product.
Apply
- Create an account, then apply to sell.
- Prove a link is yours: your GitHub account, with a code UpFork gives you in a gist (secret or public), or your website, with a small file on it whose address answers with exactly that code. A proved link is what makes you a "Verified developer" on your page. Add your résumé if you like.
- UpFork looks at your work, usually within a few days. Every seller is reviewed.
- In the developer panel, set the wallet address buyers pay: USDT on TRON (TRC-20).
The product's shape
| Kind | What it is | How buyers get it |
|---|---|---|
| Component | React with Tailwind CSS 4 (or 3, with its tailwind.config), written the way shadcn/ui components are | npx shadcn add, into their own project |
| Landing page | The same, as a whole page; or plain HTML, CSS and JavaScript | Installed like a component; plain HTML is downloaded |
| Mobile component | React Native for Expo apps, TypeScript, Expo SDK 57 | Its folders and an npx expo install line, or an AI assistant |
| Full-stack project, desktop software | Anything that ships as files | Versioned releases (Releases and updates) |
Lay a component's project out like this. When there's a registry/ folder, only it is listed, so the app you built it in
(its pages, configs, playground) never reaches buyers:
my-product/
registry/
components/<name>/… what buyers install (also lib/ and hooks/)
demos/default.tsx a screen that shows it: default export, never installed
demos/<other>.tsx up to 6 demos
public/images/… pictures, fonts and videos the code names ("/images/team/ana.jpg")
app/globals.css its own variables, @theme, keyframes: the product's Styles
package.json its packages; its description and keywords feed the listing
README.md feeds the description
LISTING.md the listing's values (Templates has one to copy)Drop the folder, or a ZIP of it (GitHub's Download ZIP works), on a new product in the developer panel. It's read in
your browser, without node_modules or build output, and you see where every file goes, and what's left out and why,
before anything changes.
The rules, and why
| Rule | Why |
|---|---|
Paths start with components/, hooks/, lib/ or app/; forward slashes; no ., .. or names starting with a dot; 120 characters at most; .tsx, .ts, .jsx, .js or .css | The shadcn CLI installs only into those folders |
Imports stay inside the product: relative, or @/… | A file outside it doesn't exist in the buyer's project |
shadcn/ui's own components (@/components/ui/button) are dependencies, not files | The CLI fetches them in the buyer's own flavour. To depend on another flavour (Base UI, say), ship those primitives inside your folder, as components/<name>/ui/ |
Plain <img> and <a>, not next/image or next/link; next/font/local only in demos | It installs into any React project, not only Next.js |
No imports of Node's child_process, vm, net, http and the like | A UI never needs them; they're refused at save |
The Styles hold your own :root and .dark variables, @theme, keyframes, @utility, @property. Rules on body or *, @import and @plugin are refused, and shadcn's own tokens (--color-accent, --font-sans) are dropped | The CLI merges the Styles into the buyer's stylesheet: they mustn't restyle the buyer's whole site |
A file named *.config.ts is skipped; call your settings hero-config.ts | It's read as the project's config |
Data imported as JSON from public/ is refused: export it from a .ts module | Only code and assets travel; public JSON is neither |
Strict TypeScript: no implicit any, nulls handled | A fresh Next.js project is strict, and so is the check |
| Limit | |
|---|---|
| Files | 100, each up to 100,000 characters, 400,000 in all |
| Demos | 6, names up to 30 characters |
| Assets | Pictures 10 MB, fonts 5 MB, videos 40 MB, sounds 20 MB; 300 assets and 100 MB a product |
The registry item
What buyers install is a shadcn registry item that UpFork makes from your files, at https://upfork.dev/r/<name>.json, where
<name> is the product's URL name. A free product installs from that address with no account; a paid one with the
buyer's token, as @upfork/<name> (Install components). AI assistants get the same item from
install_product.
{
"$schema": "https://ui.shadcn.com/schema/registry-item.json",
"name": "<url-name>",
"type": "registry:component",
"title": "<Title>",
"description": "<Summary>",
"author": "<Your name> <https://upfork.dev/developers/<your-name>>",
"dependencies": ["motion"],
"registryDependencies": ["button"],
"files": [{ "path": "components/<name>/<name>.tsx", "type": "registry:component", "content": "…" }],
"cssVars": { "light": { "glow": "…" }, "dark": { "glow": "…" } },
"docs": "What the CLI prints after installing it"
}| Field | Where it comes from |
|---|---|
name, title, description | The URL name, the title and the summary of your listing |
type | registry:component, or registry:block for a landing page |
author | You, linking your developer page |
dependencies, devDependencies | The npm packages your files import; the type packages the install check found they need |
registryDependencies | The shadcn/ui components your files import |
files | Your files (never the demos'), each with where it installs; links to your assets point at UpFork's copies |
cssVars, css, tailwind | Your Styles, as the CLI merges them, and as a Tailwind CSS 3 config for buyers still on it |
docs | What the CLI prints once it has installed it |
You never write this file: you write the folder, and the item follows it on every save.
The live preview
Every save builds a live preview from your demos: your component running, not a picture of it, on its card and its page. Most build in under a minute; up to three minutes, packages included, so keep them few and small. Set each demo's look in the editor, or on its first line, and every import keeps it:
// @upfork layout=full-page background=plainlayout is centered (with padding none, small, medium or large), full-width (a section) or full-page;
background is plain, muted, dots or grid. A demo that's a window tall is shown as a full page anyway. Pick the
theme previews open in: the visitor's own, always dark or always light.
The install check
Every save of a component is installed the way a buyer installs it:
- a fresh Next.js app with
shadcn init(Tailwind CSS 4), its packages pinned; - the real shadcn CLI adds your item: your files at their targets, your Styles merged into
app/globals.css, the shadcn/ui components fetched; - npm installs your packages, with
--ignore-scripts; next typegen, thentsc --noEmitover the whole project. A package without types gets its@typespackage when npm has one, which your item then brings.
Nothing you wrote runs during any of it. Publishing waits for a clean check, and each problem comes back at its file and line. The ones met most:
| Code | Means | Fix |
|---|---|---|
install-package-missing | An import names a package npm doesn't have | Fix the package's name, or the import |
install-package-version | npm couldn't install a package; npm's own words follow | Fix the version, or the peer it asks for |
TS2307 | A file isn't among those that install (demo files aren't), or a package path doesn't resolve | Add the file to the product, or fix the path against the package's exports |
TS2305, TS2614 | The name isn't exported, or a default and a named export are mixed up | Import it as it's exported |
TS7016 | A package has no types, and npm has no @types package for it | declare module "the-package" in a .d.ts file of the product |
TS7006, TS18048, TS2532 | Strict mode: an implicit any, a value that may be undefined | Type it where it comes in, or check it first |
install-type-page | A page or layout under app/ exports what Next.js refuses | Default-export a component, and nothing Next.js disallows |
install-reference-dropped | The CLI leaves out a /// <reference lib="…" /> line | Type what it covered without it |
Under the preview, try the install gives you a private link, good for a day, that installs your code as last saved
into a project of your own, through UpFork's registry. A mobile component is checked in a fresh Expo app instead: its
packages installed with npx expo install, strict TypeScript, a web build (Install mobile components).
The review
Every save is also read for what a reviewer looks at: the sites your code sends to or loads from, text it runs as code, code that hides what it does, private things it reads (cookies, storage, the clipboard, environment variables), code that runs on the buyer's server, and your packages (install scripts, names a letter or two from a well-known one, new or little-used packages, deprecation, known malware). Each shows under the code, under For the review, at its line. Most are honest code that needs a word: name each site your code talks to in Connects to, on the product's Details, with what it sends there. Buyers see that list, and the reviewer compares it with the scan's (How code is checked).
The Publish step lists what's left: a built preview, a clean install check, a price or free, a license, and the listing. Send it for review: UpFork publishes it once it's approved, or sends it back with a note at the top of your editor. Later revisions are built, checked and reviewed the same way, while buyers keep the approved one; once UpFork marks you trusted, a revision whose checks raise nothing to look at goes out without waiting.
The listing
The listing is what a buyer, a search engine and an AI assistant read before they try the product. Keep its values in
the product's LISTING.md, beside the code, so each version starts from the last (a template to
copy).
| Field | Limit | Why it matters |
|---|---|---|
| Title | 120 characters | The name, then what it is in the words people search for, then the stack: what search engines and the catalog show first |
| URL name | 80; lower-case letters, digits and hyphens | The address and the install name: use the search phrase, and never change it once people install by it |
| Summary | 280 | The card's text, the search result's line and what search_products answers with |
| Categories | 4 | Where the catalog shelves it; the first is on its card |
| Tags | 8, each up to 24 characters, lower-case and hyphens | The other words people search for: features and the stack |
| Description | 20,000 characters of Markdown | What it does, section by section, then what's included and what it needs |
| License | MIT, the UpFork Standard License, or another open-source one | What buyers may do with it |
| Price | Free, or USDT with up to two decimals |
Write only what the code does: the live preview sits beside every claim. No other company's trademark in the title, and no invented numbers, users or reviews.
Releases and updates
A component updates by saving new code: it's built, checked and reviewed, then goes out, on its own or as a version with notes under Updates.
A product that ships as files has releases: a version (such as 1.2.0), notes, and files for any platform, Windows,
macOS, Linux, Android, iOS or the web, up to 95 MB a file and 100 releases a product. Each file is scanned for malware
and published with its SHA-256 checksum; older versions stay downloadable (Templates and downloads).
Either way, everyone who has or watches the product hears about the new version on the site and by e-mail, and notes that say "fixes #12" (or fixed, closes, resolves) mark bug #12 fixed in that version and tell everyone who reported it (Reviews, bugs and updates).
Getting paid
Buyers pay in USDT on TRON, wallet to wallet (Paying with USDT): UpFork never holds the money. UpFork's share is taken as whole sales, not a cut of each: today 20%, so 1 of every 5 sales of each product, starting with the first, is paid to UpFork's wallet, and every other sale straight to yours, in full. There's no payout threshold and nothing held back. The sell page always states the current share. Buyers get a receipt by e-mail; you see each sale in the developer panel.
After it's on sale
- Reviews and bugs come only from people who have it; answer them in public, and set each bug's state.
- Buyers' tickets: when a ticket is about your product, UpFork can bring you in; you answer under Buyers' tickets in the developer panel.
- Numbers: views, installs and downloads, on the product and on your page.
- Articles: write about how you built it, with its code and preview in the text and the lessons you learned (Writing articles). Your developer page and PDF résumé show them (Profile and résumé).
With an AI assistant
An assistant connected to UpFork's MCP server knows this page's rules: the prompt make-product walks it
through shaping your project so it registers cleanly, and write-listing through the listing; get_guide with topic
products or listings gives it the rules and templates on their own. Dropping the folder, the price and publishing
stay yours, in the developer panel.
Stuck on something the editor doesn't explain? Open a ticket about selling, with your product's name.