Build a tool. Keep your name on it.
A first working version of a small tool comes together quickly now. The distance from “it runs” to something worth handing a stranger — edge cases, tests, accessibility, verification — is the actual work, and it is where most solo attempts quietly die. Work here has been deleted rather than shipped for exactly that reason. So the catalog is open: you walk that distance with review, hosting, and users already in place.
What you get
Hosting costs you nothing
A tool that runs in the browser adds a page, not a server bill, so there is nothing to pass on. Tools that need server compute are a separate conversation about who pays, held in the issue before any work starts.
Your name stays on it
The catalog records an owner for every tool. That credit belongs to whoever built it, and the tool page links back to you.
You do not walk it alone
Proposal, review, and the pull request are done with you rather than left to you. For some people that is a portfolio piece with a live URL; for others it is review experience that is hard to get alone.
How it goes
Agree on the problem
Open a proposal issue describing the task, the free result, where the work happens, the worst thing someone might paste in, and how we know the output is correct. Agreement on the problem comes before code.
Declare it
Declare the tool in the catalog manifest: what it does, whether it runs locally, how sensitive the data is. The schema refuses a local tool that also asks for network access, so the promise is enforced rather than assumed.
Build and test it
Write the work as plain functions with tests beside them, then build the interface on top. Heavy work belongs in a worker so the page never freezes.
Open the pull request
Run the verification suite, sign off your commits, and open the pull request from a branch on your fork. Main is the deployed branch and only takes reviewed changes.
The full walkthrough, with the commands, lives in docs/contributing/add-a-tool.md. It is about a fifteen-minute read. Getting a tool through its quality gates afterwards is the long part — days to weeks, not minutes.
Smaller ways in
Adding a whole tool is not the only useful contribution. These are scoped to finish in one sitting.
What gets declined
Being technically correct is not sufficient. A tool is declined when it needs a subscription, an account, or a watermark to make sense; when it sends data to a server for work the browser can do; when the result cannot be verified; or when it carries a maintenance cost the project cannot sustain. These are product decisions, and they are explained in the issue rather than left unsaid.
Questions are welcome as an issue before any code exists.