Why we built ReviewSentry — and why we made it free

Every small business has a version of the same problem. Time is the constraint that shapes every decision — what to build, what to defer, what to automate, and what to just accept as overhead. When you are a team of one or two, an hour spent on something that does not need human judgement is an hour not spent on something that does.

Code review is one of those things. Not because it is unimportant — it is essential — but because a significant fraction of every review is predictable. The same class of issues appears again and again: credentials left in comments, unsafe variable expansion in shell scripts, missing documentation on a new function, a PR that should have been two PRs. These are not hard to spot. They are just time-consuming when you have to look for them yourself, on every branch, every time.

The specific problem

We were spending real time on review overhead that could have been automated. Not the interesting parts of review — the architectural decisions, the logic questions, the “is this the right approach?” conversations. Those need a human. But the surface-level scan, the checklist of things that should always be true, the first pass that catches the obvious before the reviewer even opens the diff — that could run automatically.

We also had a specific concern about security. As a security company, we hold ourselves to a higher standard on what goes into a commit. Exposed credentials, personal identifiers in log output, private paths in error messages — these are the things that matter most and are easiest to miss when you are moving fast. We wanted every PR scanned for them before any code reached a reviewer.

Why we built it ourselves

There are existing AI review tools. We looked at them. Most are dashboard products with per-seat pricing and proprietary infrastructure — which means your code diff leaves your environment, goes through a third party's system, and you have limited visibility into how it is processed or stored.

That model does not work for us, and it probably does not work for a lot of small teams handling client code, regulated data, or anything commercially sensitive. We needed something we could run ourselves, with full control over what went where, using providers we had already assessed and approved.

We also needed it to be affordable. A per-seat review tool at enterprise pricing is not accessible to a sole trader or a two-person consultancy. The free tier of GitHub Models — which lets you run GPT-4o against your PRs using nothing more than your existing GitHub account — changes the economics entirely. A proper AI code review, on every PR, at zero marginal cost.

Our values in practice

Spyced Concepts has a set of values that we hold sincerely and apply consistently. Two of them are directly visible in how ReviewSentry was built and how it is distributed.

Help people first. The primary goal of every Spyced Concepts product is genuine utility for the user. Revenue is how we fund the work — it is never the primary goal. ReviewSentry is MIT licensed and free forever, with no crippled free tier and no paywall on the features that matter. The GitHub Models integration means the most useful configuration costs nothing. That is deliberate.

Quality is universal across tiers. We do not make a lesser product for people who cannot pay. The decision to review on draft PRs by default, to lead every review with a security scan, to document known issues openly and honestly — none of that is gated. If you install ReviewSentry from the marketplace, you get the same thing we run on our own code.

The open source decision

Making ReviewSentry open source was not a marketing decision. It followed directly from the values.

If we are asking people to add a GitHub Action to their repositories — to give that action access to their PR diffs, their code, their credentials-in-environment-variables — they deserve to be able to read every line of what it does. Full stop. SHA pinning (which we document and require for production use) gives cryptographic immutability; open source gives auditability. Both matter.

There is also the question of dependency. We use open source software constantly — pytest-bdd, the Cucumber Gherkin parser, the Python ecosystem we build on. We publish detailed attribution in our test suite documentation, including security due diligence, maintainer geo-provenance, and risk assessments for every dependency we introduce. That is not legal boilerplate. It is respect for the people whose work we depend on, and transparency for anyone who wants to understand what is running in their environment.

The attribution standard

One thing we are particularly proud of in ReviewSentry is the approach to dependency documentation. The test suite uses fourteen third-party packages. Every one of them is documented with the same structured assessment: purpose, maintainer, geo-provenance, repository, licence with SPDX identifier, CVE history at the time of assessment (with NVD links), maintenance status, risk rating, and a written justification for why we chose to use it.

This is not standard practice. Most projects list dependencies in a lockfile and call it done. We think that is insufficient — particularly for a security tool. If you are asking people to trust your code, you should be able to show them that you have done the work on everything your code depends on.

The assessment also notes, explicitly, that no unpatched CVEs were present in any pinned dependency at the time of release. We will update this with each release as part of the standard release process.

What comes next

ReviewSentry is a beta product. The core functionality works and is running on our own repositories. The known issues are documented honestly in KNOWN_ISSUES.md — not buried in a roadmap or passed off as features. The next sprint is focused on a full security and code quality scan of the codebase, issue triage using MoSCoW prioritisation, and building the features that will move it toward a stable release.

If you are using ReviewSentry or have feedback, open an issue on GitHub. If you want to understand how Spyced Concepts can help your team with security, developer tooling, or AI-integrated workflows, get in touch.