Shouldiuse.dev – Software dependency health checker
As software engineers we are often confronted with the decision of whether to code something ourselves or to add an existing library that does it for us. Whether we like it or not – we are adding dependencies sooner or later. And it's arguably good practice to check a new dependency beforehand: Is it maintained? By whom? How many issues does it have and how many of those are bugs? Are they being fixed? What's on the roadmap? What's the release frequency and how often do APIs break? One of our favorite solutions that already exist to answer such questions is the OpenSSF Scorecard project…
In plain words
Shouldiuse.dev helps software engineers evaluate whether to adopt a new library dependency by providing web-based access to security and maintenance metrics. It displays data from the OpenSSF Scorecard project, showing information about maintainers, issue tracking, bug fixes, release frequency, and API stability. The tool is designed for developers making informed decisions about adding external dependencies to their projects.
written from the facts on this page · September 2026
From the sources
In the maker’s words, at launch
As software engineers we are often confronted with the decision of whether to code something ourselves or to add an existing library that does it for us. Whether we like it or not – we are adding dependencies sooner or later. And it's arguably good practice to check a new dependency beforehand: Is it maintained? By whom? How many issues does it have and how many of those are bugs? Are they being fixed? What's on the roadmap? What's the release frequency and how often do APIs break? One of our favorite solutions that already exist to answer such questions is the OpenSSF Scorecard project (https://github.com/ossf/scorecard) – we use this ourselves and can only recommend it. We built shouldiuse.dev around it to make results accessible as a website, and used the opportunity to dive deep into heavily LLM-assisted coding for the first time in a professional project. Three people (devs and non-devs) each started vibe-coding an initial prototypes, one using v0, one using lovable and one using Cursor. At first blown away by how fast we were able to generate these and how great there were looking, we soon ran into issues merging different ideas as there were multiple different web frameworks and versions flying around. The most work on the frontend definitely went into getting the details and small adaptions right. In parallel, on the backend we started to write a Go application that uses the ossf/scorecard library to do a lot of the checks we want. To also play around with AI on that end, we intentionally made heavy use of Copilot and tried around with different models and prompts. We also added more metrics to the dependency check that we gather via GitHub API, and finally generate textual summaries via OpenAI. The Prompt to generate a final textual recommendation consists of: * A header stating the role, capabilities and limitations, and the expected response format (JSON and no lists/bullet points) – We also tell it to be critical, objective and give short and concise answers. * The result of the scorecard check * Additional community-related data * The questions that are being shown in the FAQ section – The answers to those are also generated by the LLM. Since such a check involves heavy use of the GitHub API, we require users to input a GitHub personal access token when requesting a check. The first time a repository is checked on shouldiuse.dev it will take a few seconds, but then the results are stored in a postgres for faster retrieval later on. For now it only works for public GitHub repos, but we might add other platforms if there is interest. We also added a remote MCP server with built-in authentication, so you can directly access shouldiuse from your IDE and automatically check new dependencies anytime a coding assistant introduces one to ensure that only safe dependencies are added to the project. What started as a fun internal experiment quickly surprised us with how useful it turned out to be. We didn’t plan to release it publicly, but we think might be useful for other devs and therefore we wanted to share it here. Any feedback is welcome!
More dev tools this month
the category →
Open-source GTM skills for technical founders
Dev tools · 29d ago · gtmcofounder.com
OpenTrailPaper is open-source bike computer firmware for the LilyGO T5S3 4.7" E-Paper PRO. It supports offline maps, GPX routes, FIT recording and Bluetooth sensors.
Dev tools · 1d ago · opentrailpaper.com
Launched alongside, June 2025
the whole month →- IM
Hey HN! Pilots everywhere are required to keep a logbook of all their flying hours, aircraft, airports, and so on. Since I track everything digitally (some people still just use paper logbooks!), I put together some data visualizations and a few 3D globes to show my flying history. This globe is probably my favourite so far: https://jameshard.ing/pilot/globes/all If you’ve got ideas for other graphs or ways to show this kind of data, I’d love to hear them!
Life & fun · 2025 · jameshard.ing
Stunning presentations with AI. No design skills required.
AI · 2025 · chroniclehq.com
Build native mobile apps for iOS and Android without code.
Dev tools · 2025 · bble.io
All your connections, across all your socials.
AI · 2025 · pally.com
- WC
I was the main contributor to workout.lol, an open-source fitness app to easily build a workout routine. The project had traction (1.4k GitHub stars, 95 forks, ~20K visits/month), but was eventually sold due to video licensing hurdles. The new owner stopped maintaining it, and the repo went abandoned. Over the next 9 months, I sent 15 emails to try to save it : no replies. Feature requests & issues were ignored. The community was left with a "broken" tool let's say. I couldn't just let it die So I built the new version from scratch with the same open-source spirit, but a better…
Dev tools · 2025 · github.com