Claude Code project ideas: 15 builds that suit a coding agent

By Post your build ideas · 28 October 2026 · 14 min read

The best Claude Code projects have a spec you can write in a page, output you can check by running something, and a scope that fits one repo. Think parsers, converters, CLIs, diff tools and small web apps with one core workflow. Avoid projects whose success is a matter of taste or depends on a third party’s behavior you cannot test. Below are 14 that pass those three tests.

What makes a project suit Claude Code?

Claude Code is Anthropic’s agentic coding tool. It runs in your terminal, reads the files in your repo, edits them, and can run commands (tests, a build, a linter), asking for your permission first unless you have configured it otherwise. That loop is the whole advantage: the agent writes code, runs something, reads the result and fixes what broke. A project suits it when that loop has something to read.

Three properties decide it. Each one is a question you can answer before you start.

The three tests a project should pass
Test	The question	Passes when	Fails when
Clear spec	Can you describe correct behavior in a page?	Inputs and outputs are concrete: a file goes in, a normalized file comes out	“Make it feel premium” or “make it fun”
Testable output	Can a command say pass or fail?	You can write ten example inputs with known answers	Success is a judgment call you make by squinting at a screen
Contained scope	Does it fit one repo and one session of work?	One core workflow, one data store, no accounts	Needs five integrations, a mobile app and a back office

A fourth property helps but is not required: a project where mistakes are cheap. A converter that mangles a file is annoying. A billing system that charges the wrong amount is a different category of problem, and an agent’s output there needs a human reading every line.

Which projects should you build with Claude Code first?

The list runs from the best fit for an agent to the ones that need more of your own judgment. Every entry names who it is for, a first version small enough to finish, the part that will actually cost you time, and a cheap way to find out whether anyone wants it.

01 Cron expression explainer

A small library with a demo page that explains any five-field cron schedule in words and lists when it will run next.

Who it’s for: Developers and ops people who read cron lines they did not write.
First version: Five-field expressions to a sentence, with the next five run times listed.
Hardest part: Ambiguity: in many cron implementations, day-of-month and day-of-week combine with OR when both are set, which surprises people.
How to test demand: Ship it as a single page and watch whether anyone returns without a prompt.

This is close to the ideal agent task. The spec is the cron grammar. The tests write themselves: a table of expressions and the sentences they should produce, plus a check that the next-run times match a reference implementation. Claude Code can run the table after every change and show you which rows broke.

The reverse direction (English to cron) is where it gets interesting, because natural language is looser. Cap it to a fixed set of phrasings in version one and say so on the page. See the idea on the board.

Read “Cron expression explainer” on the board and copy its build prompt →

02 Environment variable diff between two deploys

A tool that compares the environment of a working deploy with a broken one and names which variable changed.

Who it’s for: Anyone who has lost an hour to a missing or renamed variable after a deploy.
First version: Paste two .env-style files or two exports; get added, removed and changed keys, with values masked.
Hardest part: Secrets. Mask values by default and never send them anywhere; do the diff in the browser or locally.
How to test demand: Offer the CLI first. If people pipe it into their deploy scripts, the web version is worth building.

A diff is pure input and output, which an agent handles well, and the masking rule is easy to turn into tests: no output line may contain a value from the input. Put that rule in your CLAUDE.md so it applies in every session.

The hosted-provider integrations (pulling env from a platform’s API) are a second project. Keep version one to files.

Read “Environment variable diff between two deploys” on the board and copy its build prompt →

03 Changelog generator that people read

Turns merged pull requests or commit messages into a short, grouped changelog written for users rather than developers.

Who it’s for: Small teams who ship often and never write release notes.
First version: Read git history between two tags, group by conventional-commit prefix, output Markdown.
Hardest part: Rewriting developer language into user language without inventing changes that did not happen.
How to test demand: Generate the changelog for three public repos and ask each maintainer whether they would publish it.

The deterministic half (parse commits, group, render) is a good agent job with plain unit tests. The rewriting half needs a model call and a rule: every line in the output must map to a commit in the input. Test that mapping, not the prose.

The idea is on the board: a changelog your users actually read.

Read “Changelog generator that people read” on the board and copy its build prompt →

04 Markdown-to-anything converter with a strict schema

A command-line tool that converts a folder of Markdown notes into a fixed structure (JSON, a static site, or a PDF bundle).

Who it’s for: People with years of notes stuck in one format.
First version: Frontmatter plus body to JSON, with a report listing files that failed validation.
Hardest part: Edge cases in real notes: odd frontmatter, nested lists, files with the wrong encoding.
How to test demand: Run it on your own notes first. If you need it twice, someone else does too.

Real-world files are the best test fixtures. Copy twenty of your messiest notes into a fixtures folder and tell Claude Code that the tool must handle all of them. Each new failure becomes a fixture, and the suite grows with the tool.

05 Which abandoned repo is closest to finished

Scans your GitHub repositories and ranks the unfinished ones by how little work remains.

Who it’s for: Developers with a graveyard of half-built side projects.
First version: Read repo metadata and the last 50 commits; score on recency, open TODOs and presence of a README and tests.
Hardest part: “Close to finished” is a judgment. Publish the scoring rules so users can argue with them.
How to test demand: Run it on ten friends’ accounts and see whether the top result matches what they would have said.

The scoring function is a pure function over repo data, so it is testable with canned fixtures and no network. Keep the API fetching in a separate module so the agent can change one without touching the other. The original idea is here.

Read “Which abandoned repo is closest to finished” on the board and copy its build prompt →

06 Invoice and receipt extractor to CSV

Takes a folder of PDF invoices and outputs a CSV with date, vendor, net, tax and total.

Who it’s for: Freelancers and small shops preparing for an accountant.
First version: Text-based PDFs only, one layout per vendor, with a manual review screen for low-confidence rows.
Hardest part: Layout variety. Scanned images need OCR, which is a different project.
How to test demand: Ask three freelancers for a month of invoices and see how many you can extract without edits.

Checkable because totals must add up: net plus tax equals total, and the sum of line items equals the subtotal. Those arithmetic rules catch most extraction errors without a human. Write them as tests before you write the extractor.

07 Link checker for documentation sites

Crawls a docs site or Markdown folder and reports broken internal links, missing anchors and redirects.

Who it’s for: Open-source maintainers and docs teams.
First version: Check a local build folder, not the live site, so results are deterministic.
Hardest part: Anchor generation differs between site generators; support one generator well.
How to test demand: Open pull requests that fix broken links in three real repos using your tool’s output.

Fixture folders with known-broken links give you exact expected output. This is also a good first project for learning plan mode: ask Claude Code to propose the module layout before it writes anything, then read the plan and push back on anything you would not maintain.

08 Subscription tracker from bank CSV exports

Reads a bank statement CSV and lists recurring charges, their cadence and the next expected date.

Who it’s for: People who suspect they pay for things they forgot.
First version: One bank’s CSV format, processed entirely in the browser, so no statement leaves the device.
Hardest part: Detecting a recurring charge when the merchant string changes slightly every month.
How to test demand: Ask five people to run it and report one charge they cancelled.

Recurring-charge detection is a clustering problem with a clear definition: same merchant (after normalization), similar amount, regular interval. Synthetic statements make good tests. The privacy constraint (nothing leaves the browser) belongs in CLAUDE.md so no later change breaks it. See the board’s subscription graveyard idea.

Read “Subscription tracker from bank CSV exports” on the board and copy its build prompt →

09 Meeting cost ticker

A small app that shows what a meeting costs in real time from attendee count and hourly rates.

Who it’s for: Managers and teams who want a nudge to keep meetings short.
First version: A single page: enter headcount and a blended rate, press start, watch the number climb.
Hardest part: Avoiding the urge to add calendar integrations before anyone uses the basic page.
How to test demand: Share the link in two team chats and count how many people start a timer.

A tiny scope with one visible output. It suits an agent because there is little to get wrong, and it suits you because it shows how the CLAUDE.md, plan and test loop feels on a project that ends in an afternoon. The meeting cost ticker idea describes the pitch.

Read “Meeting cost ticker” on the board and copy its build prompt →

10 API client generator from an OpenAPI file

Generates a small typed client for one API from its OpenAPI description, with only the endpoints you list.

Who it’s for: Developers who find full generators too heavy for a three-endpoint integration.
First version: GET and POST with JSON bodies, typed responses, no auth flows beyond a header token.
Hardest part: Schema features like oneOf and discriminators. Reject them with a clear error in version one.
How to test demand: Publish the generated client for a public API and see whether anyone installs it.

The OpenAPI specification is a formal document, so the spec is already written. Test by generating a client for a handful of public descriptions, compiling the output and running it against a mock server. If it compiles and the mock calls pass, the generator works for that case.

11 Photo palette with contrast already checked

Pulls the dominant colors out of an image and flags which text and background combinations are readable.

Who it’s for: Designers and developers choosing brand colors from a mood photo.
First version: Extract dominant colors, compute contrast ratios for all pairs, mark pairs that pass the 4.5:1 text threshold.
Hardest part: Picking colors that look good, not only colors that are frequent.
How to test demand: Post three palettes in a design community and see whether people ask for the tool.

Contrast math is exactly specified by the WCAG formula, which makes half of this project fully testable. The aesthetic half is not, so be honest about which part the agent can verify and which part you must judge yourself. See the idea.

Read “Photo palette with contrast already checked” on the board and copy its build prompt →

13 Staging data scrubber

Copies a database to a staging copy with personal fields replaced by fake but consistent values.

Who it’s for: Small teams who test against production-shaped data.
First version: Postgres only, a config file listing columns to scrub, deterministic fake values so joins still work.
Hardest part: Missing a column. Fail loudly on any column not mentioned in the config.
How to test demand: Use it on your own project and count how often you reach for it.

Testable with a throwaway database and a rule: after scrubbing, no value from the sensitive columns may appear anywhere in the output. Run destructive commands only against a disposable database, and keep Claude Code’s permission prompts on for anything that touches data.

Read “Staging data scrubber” on the board and copy its build prompt →

14 Browser extension that rewrites one annoying page

A small extension that changes one site’s layout or behavior for the people who hate it.

Who it’s for: Regular users of one site with one specific complaint.
First version: A content script that hides or moves two elements, plus an on/off toggle.
Hardest part: The site changes its markup and your selectors break. Keep selectors in one file.
How to test demand: Post the problem and a screenshot in the site’s community and count the replies that say “I need this”.

Ranked lower because success is visual and the agent cannot see your browser unless you describe what it looks like. You can still get far with saved HTML snapshots as fixtures and tests that assert on the transformed DOM.

15 Photograph-to-answer utilities

Any tool where a photo goes in and one structured answer comes out, such as a parking sign or a bill.

Who it’s for: People facing a rule or a bill they do not want to read.
First version: One document type, one question answered, with the source text shown next to the answer.
Hardest part: Wrong answers with confident wording. Show the reading, not just the verdict.
How to test demand: Collect twenty real photos from friends and check how many the tool gets right.

Last because correctness depends on a model’s reading of messy images, which an agent cannot unit test the way it can test a parser. Build an evaluation set of real photos with known answers before you build the app. The board has examples, such as photographing a parking sign.

Read “Photograph-to-answer utilities” on the board and copy its build prompt →

How was this list chosen?

By editorial judgment against the three tests above, not by data. No survey, no download counts, no ranking of what earns money. The order reflects how much of the project an agent can verify on its own: parsers and diffs first, projects that depend on images, taste or third-party behavior last.

Where an entry matches a live idea on the board, it links there. Those ideas were posted by visitors, and builders can attach a link to what they shipped, unverified. Nothing here is a claim that a given project will find users.

How should you set up the repo before the first prompt?

Claude Code reads a CLAUDE.md file in your project as standing context. Use it for the things you would otherwise repeat every session: what the project is, how to run the tests, and the rules that must never break. Keep it short and specific.

A starter CLAUDE.md for a small tool

# Project
A CLI that diffs two .env files and reports added, removed and changed keys.

# Commands
- Run tests: pnpm test
- Type check: pnpm tsc --noEmit

# Rules
- Output must never contain a value from the input, only keys.
- No network calls anywhere in the code.
- Every bug fix starts with a failing test.

# Out of scope for v1
Hosted integrations, a web UI, encrypted files.

Then use plan mode for the first request: ask for a plan, read it, and correct the scope before any file changes. Reviewing a plan costs a minute. Reviewing a wrong implementation costs an evening. For the wording of the request itself, see how to write an app build prompt, and for the full workflow, how to build an app with Claude Code.

How do you pick one and check that it is worth finishing?

Write the spec in one page. If you cannot, the project fails the first test; shrink it until you can.
Write ten example inputs with the outputs you expect. These become the first tests.
Name one person who would use it this month. Not a market, a person.
Build the smallest version that person could use, and ask them to use it within a week.
Decide in advance what counts as a signal: a return visit, a pasted link, a request for the next feature.

The MVP scope planner helps cut a project down to one workflow, and the AI coding prompt builder turns the result into a first prompt. If none of these fits, browse the idea board or post an idea you won’t build; every idea page also has a generated prompt you can open in Claude Code.

If you are comparing agents rather than projects, read Claude Code vs Cursor vs Lovable. If you only have two days, the weekend project list cuts scope harder.

Which projects are a poor fit for a coding agent?

Anything where “done” is a feeling. Games that must be fun and landing pages that must convert cannot be verified by a test, so you become the test suite.
Anything with money or health consequences. Payment logic and medical advice need a human to read every line, which removes most of the speed gain.
Marketplaces with two cold-start sides. The code is the easy part; getting supply and demand is not an agent task.
Projects built on an API you cannot call in tests. If every test needs the live service, the agent’s feedback loop is slow and flaky. Record responses as fixtures.

Frequently asked questions

What kind of project is best for Claude Code?

Projects with a clear spec, output you can check by running a command, and a scope that fits one repository. Parsers, converters, command-line tools, diff utilities and single-workflow web apps fit well. Projects judged by taste, or dependent on services you cannot test against, give the agent nothing to check its work with.

Can Claude Code build a whole app on its own?

It can write most of the code for a well-scoped app, but you still decide what to build and review what it produces. The reliable pattern is a short plan, a small first version, tests that run after each change, and your review before you merge. Large, vague requests tend to produce large, vague results.

What is CLAUDE.md and should I write one?

CLAUDE.md is a file in your project that Claude Code reads as standing instructions. Put in the project’s purpose, how to run tests, and rules that must not break. Writing one takes ten minutes and saves repeating yourself every session. Keep it short; long files get ignored by humans and agents alike.

Where can I find Claude Code project ideas with prompts ready?

Every idea page on Post your build ideas has a generated build prompt containing the whole description, with an Open in Claude Code button. You can also paste the same prompt into Cursor, Codex, Lovable or another builder. Browsing the board is free and posting needs no account.

How do I know if my Claude Code project is too big?

If you cannot describe the finished product in one page, or it needs more than one data store and several third-party integrations, it is too big. Cut it to one workflow for one kind of user, and move everything else to a list titled “version two”.

Created with AI assistance and edited for this site. Examples are illustrative and do not represent customer research. About the publisher.