See what Hacker News really thinks of the tools in your stack

Build me a tool evaluation workbench that our platform team opens whenever we are picking a new piece of our stack or re-reviewing something we already run. The question it answers is the one we currently answer with ten ad hoc searches: what does Hacker News actually think about this tool, and is the project behind it healthy. The audience is engineering leadership doing build versus buy, so keep it dense and skimmable rather than decorative.

The app is built around a tracked list of tools that we curate by hand, covering both the tools we run today and the ones we are evaluating. Each tool has a name, a short category such as database, queue, auth, observability or CI, the GitHub repository behind it in owner/repo form, the search terms to use when looking for it on Hacker News, and our own status. Let me add a tool by typing its name and repository, and let me store one or more search aliases plus optional exclusion words, because a product with a common name otherwise drags in a pile of unrelated threads. Everything that is ours, meaning status, reasoning, aliases, briefs and decision links, is stored in the General Input Database, keyed by both the team and the person who wrote it, so the team works from one shared list while individual notes stay attributed.

The main view is that list, one row per tool, showing the Hacker News signal and the GitHub health side by side. For the Hacker News side, use Search Posts (Algolia) scoped to stories matching the tool's search terms and filtered with numeric filters on points and num_comments, and show how many substantial threads exist in the window, the points on the biggest one, and when the most recent substantial thread happened. For the GitHub side, use Get a Repository for stars, open issue count, last push date and whether the repository is archived, and Get Latest Release plus List Releases for the last released version, when it shipped, and how many releases came out in the last year. Put a plain badge on any tool whose last release is more than a year old, because whether the project has shipped anything recently is half of what we are asking.

Across the top of the list put the controls that make this useful instead of noisy. A points floor and a comment floor, defaulting to 50 points or 30 comments, so we only see threads with real discussion rather than the hundred passing mentions. A date window defaulting to the last three years, because an opinion from 2019 about a database should not read as current. A status filter, and sorting by thread count, biggest thread, stars or release recency. Let me lower the floors when a niche tool has almost no coverage, and say so plainly on the row when a tool barely gets discussed at all, because thin coverage is itself a finding.

Opening a tool gives me its detail page. The first section is the threads worth reading, highest signal first, found with Search Posts (Algolia) and hydrated with Get Item so I see the real story record. Each row shows the title, the year it was posted, points, comment count, whether it was a Show HN, an Ask HN or a general discussion, and a link straight to the thread on Hacker News. Show the year prominently on every row and every quote in the app, because half of reading Hacker News well is knowing how old the take is.

Underneath that goes the part I actually want, which is what people keep saying. Read the comments on the top threads, using Get Item to walk each story's comment tree, and group what comes back into recurring praise, recurring complaints, and the alternatives people keep suggesting instead of this tool. Each theme should carry how many separate threads it showed up in, plus two or three short quoted comments with their dates and links, so I can click through and judge for myself. Split the themes into recent, meaning roughly the last eighteen months, and older, so a problem that got fixed in 2022 does not sit there looking live. Rank the alternatives by how often they came up, and let me add any of them to the tracked list in one click.

Give me a discussion volume trend for each tool, a simple chart of substantial threads per quarter or per year across the window, so I can see whether a tool is being talked about more or less over time. Build it with Search Latest Posts (Algolia, by date) bucketed by created date with the same points and comment filters applied, so the trend measures real discussion rather than mentions.

Every tool carries our own status, one of evaluating, adopted, on hold or rejected, with a free text reasoning field and the date it last changed. Both save in the app, in the General Input Database, and are never written to any connected tool. Show the status on the list rows too, and flag anything whose status has not been touched in over a year as due for re-review.

Put an Evaluate this tool button on the detail page that kicks off a background agent. The agent reads the highest signal Hacker News threads in full, walking the comment trees with Get Item rather than skimming titles, checks release cadence with List Releases and Get Latest Release and recent issue activity with List Repository Issues to judge whether maintainers are responsive or the tracker is a graveyard, and searches the internet for the tool's own documentation, its current pricing and any recent write ups. It then writes a build versus buy brief back into the app covering what the tool does well, the failure modes people actually report and how often, who it suits and who it does not, and which alternatives came up most with a line on each. Save the brief on the tool with the date and who ran it, show a clear running state on the button while the agent works, and keep previous briefs so we can see what we thought last time.

The second button is Save decision record, and it only makes sense once we have decided. It creates a page in our engineering Notion database using Create a Page, containing the verdict and status, the date, who decided, the brief the agent wrote, the reasoning we typed, and links to the specific Hacker News threads that informed it. Let me pick the target database once in settings using Search by Title, and store the returned page URL back on the tool so the record and the tool always point at each other. The whole point of this button is that the next person asking about this tool finds the reasoning instead of reopening the argument.

Two constraints to build against. Hacker News is public, unauthenticated and read only, so nothing here posts, votes or comments, and the app never needs a Hacker News login. Everything read from GitHub is read only as well. The only thing written anywhere outside the app is the Notion decision record, and everything else, meaning statuses, reasoning, aliases, briefs and decision links, lives in the General Input Database.