Add to it.

58 tools across 9 shelves, and the list only grows when somebody has an afternoon free. Three ways around that — one of them takes two minutes and needs nothing but an opinion.

Three routes in

Pick the cheapest one that fits.

Suggest one

Two minutes · needs a GitHub account

Fill in the form. It opens an issue, and 👍 reactions on that issue are the votes — 3 of them and the tool appears at the foot of its shelf, marked unreviewed, until somebody here has written it up properly.

Open the suggestion form

Add it yourself

Fifteen minutes · one file

A pull request adding an entry to src/data/tools.ts, and that is the whole change — the row, the tool page, the category counts, the sitemap and the structured data all follow from it. It skips the vote threshold, because a written-up entry is written up however it arrived.

How to add one

Say it is wrong

One minute · no account

Tools shut down, get acquired and quietly drop their free tier, and nothing here notices automatically. Every entry has a Report link at the foot of it. If you know what it should say instead, the correction form is better still — it arrives with the fix in it.

Open the correction form

The editorial standard

Where's the catch?

It is the only question this directory exists to answer. Anyone can list a tool's features; the tool already does that, better and at greater length. Every entry here carries two fields, and they do different jobs.

tagline

What it does and who it is for, in one line, under 95 characters, no full stop. It has to survive being read against five others on the same page. No "powerful" and no "modern" — every tool here is both, so the words carry no information.

Merchant of record for software — it owns the global tax problem

description

Two or three sentences saying something the tagline cannot: the trade-off, the catch, who it is genuinely not for. This is the whole reason a tool page exists. If it restates the tagline at greater length, it is not a description yet.

Paddle is the seller of record, which means it registers for and remits sales tax and VAT worldwide instead of you. You pay a higher percentage than a raw processor and accept less control over checkout; for a small team selling internationally that is usually the right trade.

On a suggestion, that paragraph gets written here rather than by you — not to be precious about it, but because a directory in fifty voices is just a list of landing pages. Your notes on the form feed it, and the "where is the catch?" box is the one the review actually reads.

What happens to a suggestion

No backend, no inbox, nothing to wait on.

GitHub is the database: issues hold the submissions, reactions hold the votes, labels hold the moderation state. A daily job writes the result into the repo and the site rebuilds from it.

You submit
The form opens an issue, visible immediately. Nothing is moderated away before anyone sees it.
Readers vote
A 👍 on the issue is a vote — one per account, and accounts have history. Below 3 votes a suggestion is real and visible, but only in the tracker.
It reaches the shelf, unreviewed
Below the comparison table, dashed rather than solid, no write-up, no icon, and the outbound link is nofollow ugc — so it passes no ranking signal at all until a human has checked it. Spamming this buys nothing, which is the point.
It gets reviewed and written up
Accepting it opens a pull request with your facts already filled in and the description left blank — and the build refuses to publish until that paragraph is written. That step is the one thing here that deliberately does not automate.

Declare it if the tool is yours — the form asks, and a declared interest is shown next to the entry rather than filtered out. You know the tool best; the honest move is to let the reader weigh that themselves.

Before you build something

What this site is deliberately not.

Code contributions are welcome — bugs, accessibility, build, performance. But a few obvious improvements have already been argued out and turned down, and a pull request is a sad way to find that out.

No filtering. The facts you would filter on are already on every row, and search covers the rest.
No index of every tool. It would be the fifty-row wall the three-page structure exists to avoid.
No ranking. Tools within a shelf are alphabetical, which is visibly arbitrary — the honest signal, because this directory has not earned a ranking.
No JavaScript beyond the theme toggle and search, and no database. The report form is plain HTML posting to one function; everything else is static files.

None of that is permanent. Each one is a decision with a paragraph behind it, and the way to reverse one is to argue with the paragraph first —they are all written down.

The long version

Setup, the schema field by field, what the build checks and what gets turned down — in the repository, where the work happens.

Read the contributing guide The repository

src/data/tools.ts — the one file an entry lives in
Content model — every field, and how to write it
Code of conduct
Security — what's in scope, and where to send it
hello@devtool.fyi — if none of the above fits