How whatwemade works

A library of things people make with AI, where the how matters as much as the what. Anyone can post, nobody reviews by hand, and a few simple rules keep it worth visiting.

Three ways to share

Open source

Import a public repo. Anyone can fork it in one click, and forks that come back are shown as remixes with credit to you.

Showcase

Keep the code private. Share screenshots, a demo and a build recipe: a brief your own agent writes, so anyone can rebuild the project with theirs.

Later

For sale

Coming later. List a running project with its code, domain and users, and hand it over safely to someone who'll keep it going.

What every project shows

This is the part that makes whatwemade different from a gallery. You learn something from every post.

Agents

Every AI tool involved, what it did and roughly how much of the work.

Stack

Frameworks, databases and hosting, so you can filter by what you know.

MCP servers

Which servers the agent used while building, and for what.

Build recipe

One prompt, written by the maker’s agent, that rebuilds the whole project without the code.

Time and cost

How long it took and what the AI cost. Honest rough numbers.

Visuals

A cover, screenshots and a short demo video, ideally made by the agent.

whatwemade.json

Put this file in your repo and connect GitHub. The listing fills itself in, and stays in sync every time you push.

  1. 1

    Connect GitHub

    Read-only access to the repos you choose.

  2. 2

    Add the manifest

    Write it by hand, or let your agent write it with the asset pack prompt below.

  3. 3

    Push

    We read the manifest, the README and the files in /whatwemade, then update your project page.

whatwemade/whatwemade.json
{
  "title": "Tidepool",
  "tagline": "A calm money dashboard that reads your bank exports",
  "type": "web-app",
  "category": "finance",
  "tags": ["personal finance", "csv", "privacy"],
  "links": {
    "repo": "github.com/idalund/tidepool",
    "live": "tidepool.money"
  },
  "agents": [
    { "name": "claude-code", "role": "Architecture, parsers, tests", "share": 72 },
    { "name": "v0", "role": "First pass of the dashboard UI", "share": 18 },
    { "name": "chatgpt", "role": "Category rules and copy", "share": 10 }
  ],
  "stack": ["Next.js", "Supabase", "Tailwind", "Vercel"],
  "mcp": [
    { "name": "Supabase", "use": "Schema, migrations and seed data" },
    { "name": "Playwright", "use": "End-to-end tests and the demo" }
  ],
  "build": { "time": "3 weekends", "cost": "$46", "prompts": 182 },
  "recipe": "whatwemade/recipe.md"
}

The asset pack prompt

Everything here is made with AI, so the listing can be too. Paste this into your agent inside the project.

Creates /whatwemade with a manifest, cover, screenshots and a demo video
You are preparing this project for whatwemade.app, a community library of things made with AI. Create a folder called /whatwemade in the project root with the following, then stop and show me what you made.

1. whatwemade.json, a manifest with these fields:
   title, tagline (max 70 characters), description (2 to 4 short paragraphs, plain language, no marketing words),
   type, category, tags (max 5), links (repo, live),
   agents: [{ name, role, share }] for every AI tool used, with an honest share of the work in percent,
   stack: [frameworks, databases, hosting],
   mcp: [{ name, use }] for every MCP server used while building,
   build: { time, cost, prompts }.
   Read the git history, package files and any agent rules files (AGENTS.md, CLAUDE.md, .cursor/rules) to fill this in. Ask me about anything you can't find instead of guessing.

2. recipe.md, a build recipe: one prompt that someone else can paste into their own agent to build this project from scratch without seeing the code. Write it as instructions to an agent with these sections: what it does, stack, how it fits together, data model, build it in this order, tools to connect, watch out for, and done when. Leave out secrets and anything private. Under 1,000 words.

3. cover.png at 1600×1067. A clean screenshot of the most characteristic screen, centred on a plain background colour taken from the app's own palette. No device frames, no text overlays.

4. Three to six screenshots (shot-1.png, shot-2.png, …) at 1600×1067 showing the main flows in the order a new user meets them.

5. demo.mp4, 20 to 45 seconds, 1600×1067, no sound needed. Use Playwright (or the Playwright MCP server if available) to record a real walk-through: open the app, do the one thing it's for, show the result. Move the cursor at a calm, human speed.

6. logo.svg if the project has one.

Use realistic sample data in every screenshot, never lorem ipsum, and never show real personal data, API keys or tokens.

The build recipe prompt

Most useful when the code isn’t public. Paste this into your agent inside the project, and it writes a brief that lets anyone rebuild it with their own agent.

Writes whatwemade/recipe.md from your code and history
Write a build recipe for this project and save it as whatwemade/recipe.md. The recipe is one prompt that someone else can paste into their own coding agent to build the same thing from scratch, without seeing this code.

First read the code, the git history, the package files and any agent rules files (AGENTS.md, CLAUDE.md, .cursor/rules). Then write the recipe as instructions to an agent, in plain language, with these sections:

- A first line: Build a [type of project] called [name]: [what it does].
- What it does: the problem, who it's for and the main flow, in one short paragraph.
- Stack: the frameworks, database, hosting and services, and why each one was chosen.
- How it fits together: the main parts and how data moves between them.
- Data model: the tables or collections and their important fields.
- Build it in this order: numbered steps, each small enough to try on its own.
- Tools to connect: any MCP servers or APIs the agent should use.
- Watch out for: the mistakes and dead ends from building the original.
- Done when: how to tell that the rebuild works.

Leave out secrets, API keys, customer data and anything private about the business. Keep it under 1,000 words. Show me the recipe before you save it.

Curation without gatekeeping

Hand review doesn't scale and slows people down. These guardrails do the work instead.

Automatic checks at submission

Live link responds, repo is public and licensed, no API keys in the text, at least one image. Failing checks block publishing; weak ones lower the ranking.

Links are monitored

Every live link is checked every few hours. If it's down for two days the project gets a visible flag and leaves Trending until it's back.

Votes are weighted by track record

An upvote from a member with projects, helpful comments and a few months of history counts more than one from a new account. Vote rings stop paying off.

Members confirm it works

Commenters can mark that they tried it. Confirmations count toward ranking and show on the project.

Community reports

Three reports from established members hide a project until it's reviewed. Reasons: broken, not made with AI, spam, or someone else's work.

New accounts start small

New members can post two projects a week and their votes count less until they've been around for a bit.

Websites have their own lane

Landing pages and marketing sites are welcome, but they live under Websites so the main feed stays about tools.

How ranking works

Every project starts in New. From there, Trending is a score that goes up with weighted upvotes, forks and “tried it” confirmations, and slowly goes down with age so the front page keeps moving.

Projects that share how they were made (agents, the stack, a build recipe) rank higher than ones that don't. A broken live link takes a project out of Trending until it's fixed.

Open question we're discussing with the community: should open source projects get a boost over showcase ones?

Join the discussion

What moves a project up

  • Upvote from an established memberStrong
  • Fork that comes back as a remixStrong
  • Someone confirms they tried itMedium
  • Shares agents, a recipe and a videoMedium
  • Upvote from a brand new accountWeak
  • Live link down for two daysRemoved from Trending

Community guidelines

  • Share how, not just what.

    Prompts, set-ups and the mistakes you made are what make a post useful.

  • Be honest about the AI.

    Say which tools did what. Rough numbers are fine, made-up ones aren't.

  • Post things that work.

    Demos and experiments are welcome. Mark them as such.

  • Critique the work, not the person.

    Specific, kind and actionable.

  • Credit what you build on.

    Forks link back to the original automatically. Mention the rest.

  • No spam, no backlink farming.

    Self-promotion belongs in a project page, not a comment.