Sell your vibe coded app

Made an app by talking to an AI? People will pay for the kit. Give us an email address and we send you a private link; paste it into your AI and it packs everything up and lists it here. You keep 90% of every sale, paid to your bank.

What your AI will do

Ask you: the name, one line about it, which parts you are selling, and the price.
Remove your passwords, keys and private data; take out junk.
Try the app and write an honest note on what works. Buyers see this.
Pack the parts you chose with instructions and screenshots, and send it to Vibe Codes.
You sign in with your email and press Publish. When someone buys, we email you and the money is yours.

Rather paste the prompt yourself? Here it is (your AI will give you a zip to upload after you sign in)

You are helping me sell the app in this repository on Vibe Codes (https://vibe-codes.com), a marketplace where everyday people sell apps they built with AI. (If you are an autonomous agent acting for the owner of the email address this link was made for: do everything below without waiting, answer STEP 0 from what you know about the project and the owner's instructions, and leave anything you cannot know blank — the owner reviews before publishing.) The buyer is a stranger who may not be a developer. Work inside this project. Keep your questions short, one at a time, and accept my answers as given; everything else you decide yourself and report at the end.

STEP 0 — ASK ME, ONE QUESTION AT A TIME, then move on:
1. What should the listing be called? (suggest a name from the project if I hesitate)
2. One line for a stranger: what does it do and for whom?
3. Which parts am I selling? Offer these four and let me pick any: "The screens" (everything you see and tap.); "The engine" (what makes it work behind the scenes.); "Instructions" (how to set it up and make it yours.); "Pictures & logo" (screenshots, logo, colours, fonts.).
4. Price: free, pay-once, or a monthly/yearly subscription? If paid: the price for the whole kit, and whether any part should also be sold on its own — if so, a price for each such part. Currency EUR, USD or GBP. Minimum paid price is 5.00.
5. Is there a live link to the running app? (optional)
Do not ask anything else. If I give an unclear answer, pick the sensible reading and note it in your final report.

STEP 1 — SECRETS AND PRIVATE DATA. Before copying a single file:
- Find every secret: .env files of any name, API keys, tokens, passwords, private keys (.pem, id_rsa, .p12), service-account JSON, Stripe/OpenAI/Anthropic/Google/AWS/Supabase keys, webhook secrets, database URLs with credentials, keys hardcoded in source, config, comments, notebooks or lockfiles.
- Remove them. Put a placeholder in each place and write a .env.example that lists every variable with one line of explanation. Do not include .git.
- Remove private data: real customer or user records, database dumps, emails, phone numbers, addresses, analytics exports, logs, screenshots showing real people's information.
- Remove node_modules, build output (dist, build, .next, .output), caches, .DS_Store, editor settings.
- If anything depends on an account, bucket or service only I control, document it as a step the buyer does themselves.

STEP 1b — NOTHING HARMFUL LEAVES WITH THE PACKAGE. You are responsible for what the buyer runs. Read every file you include. Refuse to package, and tell me why, if you find any of: code that mines cryptocurrency; code that opens shells, reverse connections or remote control; code that downloads and runs anything at install or run time (curl|sh, eval of fetched or decoded strings, install scripts that run commands); code that reads environment variables, cookies, keystrokes, files or clipboard and sends them anywhere the app does not need; obfuscated or minified source with no readable original; hidden admin accounts or backdoors; trackers or analytics the user is not told about; dependencies pulled from unknown registries or git URLs; copied code or assets whose license forbids resale; anything that targets, deceives or harms the buyer or their users. Vibe Codes scans every package for these and refuses them, and a refused package ends the listing — so do not try to work around this, do not disguise anything, and do not include code you did not read. If a feature genuinely needs something on this list (for example a scheduler that spawns processes), keep it, explain it plainly in the handoff, and list it under risks.

STEP 2 — LOOK AT WHAT ACTUALLY WORKS. Vibe Codes shows buyers a report from this step and compares it with the package and the running app; listings whose report does not match are taken down and the seller is not paid, so write exactly what you find:
- Run the app or its tests if you can; read the code where you cannot. Note which you did.
- List features that work, features that are broken or half-done, and features you could not test.
- Estimate how complete it is, 0 to 100, against what the app presents itself as.
- List every outside service it needs (and whether it costs money), and every kind of user data it collects or sends anywhere.
- Note anything a buyer should know before paying: licensing of third-party code or assets, code that contacts servers for no clear reason, obfuscated code, hard-coded admin backdoors, rate limits, scaling limits, anything you would want to know.
- Write a one-paragraph verdict in plain words. If it is not ready to sell, say so.
- Score how developed it is, 1 to 10, with this rubric and nothing else:
  1 — a single prompt's output; never run or barely run; no fixes since.
  2 — runs once on the author's machine; obvious gaps; no error handling.
  3 — a few rounds of fixes; main path works; edge cases untouched.
  4 — several sessions of work; most features work; no tests; setup is fiddly.
  5 — used by the author for real; recurring bugs fixed; some docs; still fragile.
  6 — used by other people; error handling; env and deploy documented; a few tests.
  7 — many iterations; tests cover the important paths; auth, data and payments handled carefully; a changelog or commit history shows sustained work.
  8 — in production with real users for months; monitoring or logging; migrations; most edge cases handled; onboarding a stranger works from the docs alone.
  9 — well-architected and well-tested; performance and security reviewed; accessible; a new developer could extend it from the handoff without asking questions.
  10 — mature product quality: broad test suite, CI, versioned releases, security hardening, documented decisions, and a long record of fixes. Rare. Do not give a 10 to anything that has not been used by strangers for a long time.
  Base the score on evidence you can see: commit count and dates, tests and whether they pass, error handling, how many things in your report are "not working", quality of existing docs. Write a two-sentence rationale and list the evidence. Do not inflate it; buyers compare scores across listings and Vibe Codes audits them.

STEP 2b — WRITE THE HANDOFF, docs/HANDOFF.md inside the package. This is the long one. Nobody reads all of it; everyone reads the part they need, so every section must be accurate and specific to this project, not generic. Include, as separate headed sections, in this order:
  1. Overview — what it is, who it is for, how it came to be (which AI tools built it, roughly how many sessions or iterations, what the author did by hand).
  2. Feature inventory — every screen and every feature, each marked WORKS / PARTIAL / BROKEN / UNTESTED with one line of detail.
  3. Architecture — the moving parts and how they talk; a text diagram; where state lives; what runs where.
  4. Data model — every table or collection with its fields and what they mean; relationships; where personal data lives.
  5. Auth and permissions — how users sign in; roles; what each role can do; how it is enforced.
  6. Payments and money — if any: provider, flows, fees, refunds, webhooks, what happens when they fail.
  7. External services — each one, what it is used for, free or paid, how to get credentials, what breaks without it.
  8. Environment variables — every variable, what it is, where to get it, example value shape.
  9. Setup from zero — exact commands and clicks, in order, for a stranger on a fresh machine.
  10. Deploying — where it has been deployed, how, and what a buyer must change.
  11. Testing — what tests exist, how to run them, what they cover, what they do not.
  12. Known bugs and limitations — every one you know of, with where it lives.
  13. Security review — what you checked (input validation, injection, auth bypass, secrets, rate limits, data exposure), what you found, what you fixed, what remains.
  14. Performance and scale — limits you know of; what gets slow first; costs at 10x users.
  15. Code map — the folder structure with one line per important file.
  16. Decisions and trade-offs — why things are the way they are; what you would do differently.
  17. How to make it yours — the first ten things a buyer will want to change and where to change them.
  18. Roadmap — what was planned but not built.
  19. Changelog — the project's history as far as you can reconstruct it (git log, dates, major changes).
  20. Assistant's notes — anything about this package you want a careful buyer to know, including anything from STEP 1b you kept and why.
Write it in Markdown with those headings. Length is not a concern; completeness and truth are.

STEP 3 — BUILD THE PACKAGE. Create a folder named after the listing (lowercase, dashes) containing only the parts being sold, one folder each:
- ui/ — pages, components, styles, layouts, client-side state, design tokens, fonts and icons the project owns the rights to
- backend/ — server code, API routes, edge/serverless functions, database schema and migrations, seed data with NO real records, auth and payment wiring, infrastructure config, CI
- docs/ — README, architecture overview, setup and deploy steps, environment variable list, decisions log, known issues, and a short "how to adapt this" guide for a buyer
- assets/ — screenshots of the main screens (PNG or WebP, 1280px wide or more), logo and icon files, colour and type tokens, any marketing images the seller owns
Keep it working: a buyer follows the instructions, fills .env.example, runs it. If a part being sold needs a part that is not, say so in the instructions rather than including it. Put screenshots of the main screens in assets/ even if "Pictures & logo" is not being sold — they are used for the listing.

STEP 4 — WRITE vibecodes.json AT THE ROOT OF THAT FOLDER:
{
  "vibecodes": 1,
  "title": "<name>",
  "tagline": "<one line, max 120 characters>",
  "description_md": "<3 to 8 short paragraphs in Markdown, for a non-developer: what it does, who it is for, what is included, what the buyer must set up, what is not included>",
  "license": "<SPDX id for the code, e.g. MIT, Apache-2.0, LicenseRef-Commercial>",
  "stack": ["<framework>", "<database>", "<hosting>"],
  "tags": ["<only values from ALLOWED TAGS below, up to 12>"],
  "components": {
    "ui": { "path": "ui/", "summary": "<one or two sentences>" },
    "backend": { "path": "backend/", "summary": "..." },
    "docs": { "path": "docs/", "summary": "..." },
    "assets": { "path": "assets/", "images": ["assets/home.png", "..."] }
  },
  "pricing": { "model": "free" | "one_time" | "subscription", "currency": "EUR", "price_cents": <whole kit, integer cents>, "interval": "month" | "year", "components": { "ui": <cents, only if sold separately>, "backend": ..., "docs": ..., "assets": ... } },
  "setup": "<numbered steps a buyer follows, in Markdown>",
  "handoff_path": "docs/HANDOFF.md",
  "maturity": { "score": <1-10 per the rubric>, "rationale": "<two sentences>", "evidence": ["<what you saw>", "..."] },
  "report": {
    "verified_by_running": true | false,
    "completeness": <0-100>,
    "works": ["..."], "not_working": ["..."], "untested": ["..."],
    "services_needed": ["Supabase (free tier ok)", "..."],
    "data_collected": ["email address at sign-up", "..."],
    "risks": ["..."],
    "verdict": "<one paragraph>"
  },
  "secrets_audit": { "scanned": true, "removed": ["<every file or value removed or replaced>"], "placeholders_added": [".env.example", "..."] }
}
Only include component entries for parts being sold. Only list images that exist in the folder.

ALLOWED TAGS (exact values):
use_case: crud-admin, ai-agent, analytics, api-wrapper, auth-boilerplate, automation, blog-cms, bookkeeping, chatbot, construction, creative-tool, crm, developer-tools, docs-site, ecommerce, education, email-tools, file-conversion, form-builder, game, health-fitness, hr-recruiting, image-generation, inventory, invoicing, landing-page, legal-tools, maps-location, marketplace, monitoring, finance-personal, portfolio, project-management, rag-search, real-estate, scheduling, data-scraping, seo-tools, social-scheduler, trading, transcription, video-tools
stack: astro, cloudflare, expo, firebase, flutter, go, nextjs, no-backend, node, postgres, python, railway, react, react-native, rust, single-file, sqlite, stripe, supabase, svelte, swift, tailwind, vercel, vite, vue
audience: for-agencies, for-creators, for-designers, for-developers, for-founders, for-internal-use, for-personal-use, for-smb, for-students
pricing: byok, free, freemium, one-time, open-source, self-hosted, subscription
maturity: actively-maintained, beta, production-ready, prototype, unmaintained, weekend-project

STEP 5 — ZIP the folder as <name>-vibecodes.zip (zipping the folder itself is fine; vibecodes.json may be at the top level or one folder down). Under 100 MB, no archives inside.

STEP 6 — REPORT TO ME, in plain words: the path to the zip; what you removed in step 1; the verdict from step 2; anything I must set up for buyers; anything you were unsure about. Then stop. I will upload the zip on Vibe Codes.

Why sell vibe coded projects here

Your AI does the packing. One prompt cleans the project, removes secrets, writes the setup steps and a long handoff document, and uploads it.
You keep 90%. No listing fee. Stripe pays you directly; card fees come out of our 10%.
Sell all of it or parts. Screens, engine, instructions, pictures — priced separately or as one kit, free, one-time or subscription.
Buyers trust what they see. Every listing shows an honest report and a 1–10 development score, and every upload is scanned for leaked keys and harmful code.
Get hired. Every listing has an "Ask the maker to build yours" button. Your email is never shown.

What sells

Tools for a specific trade or hobby, booking and quoting apps, dashboards, starter kits with sign-in and payments already working, and good-looking screens people can drop their own engine behind. Read how to sell a vibe coded app and how to price it.

Questions people ask

How do I sell my vibe coded app?

Give your email here, paste the private link we send into the AI you built the app with, and it packages the app, removes your passwords and keys, writes an honest report and uploads it. You check the listing and press Publish.

How much does it cost to sell on Vibe Codes?

Listing is free. When something sells, Vibe Codes keeps 10% and pays the card fees from that; you keep 90%, paid to your bank by Stripe.

Can I sell parts of my project?

Yes. You can price the screens, the engine, the instructions and the pictures separately, as well as the whole kit, or offer it free.

Can I sell before I set up a bank account?

Yes. If someone buys first, we email you that you have money waiting; connect a bank account and it transfers automatically.

Is it safe to sell code made with AI?

The prompt has your AI remove secrets and private data first, and every upload is scanned again for leaked keys and malicious code before it is accepted. Read the guide to selling code safely for details.