Your codebase health, in plain words

https://github.com/acme/example-saas · 2026-10-21

Overall health: critical

Your product works, but four gaps put revenue and customer trust at risk -- two of them need fixing this month.

Your product works and customers can use it today, but it was built fast and nobody is checking it automatically. That makes every change slower and riskier than it needs to be, and a few specific gaps could cost you money or customer trust before anyone notices.

▲ +3 since your previous audit on 2026-09-17

Healthier than 38% of the codebases we have audited.

Your codebase at a glance

Each area is scored from 0 to 100. Higher is healthier.

Code organisation: How well the code is organised, which decides how quickly a developer can find and safely change things.; How you are doing: Mixed: most of it is tidy, but a few oversized parts slow every change down.
Repeated code: How often the same logic is copied instead of shared, which decides whether one fix fixes everything.; How you are doing: Weak: important rules exist in several copies that already disagree.
Automatic checks: How much is checked automatically before a release, which decides how often updates break things.; How you are doing: Very weak: almost nothing is checked, so problems reach customers first.
Third-party parts: The outside building blocks your product relies on, and whether they are current and safe.; How you are doing: Fair: mostly up to date, with a few known security issues to patch.
Security basics: Basic security habits, such as keeping passwords and keys out of the code.; How you are doing: Needs work: some access keys are stored where they should not be.

How serious are the problems

Every problem area we found, sorted by how soon it could hurt you.

What it affects in your business

Which part of your business each key finding touches most.

What we found

Fix now

Anyone on the internet can tell your system that an order has been paid, without actually paying.

What it may cause: Free orders, refund disputes and lost revenue that only shows up when you reconcile the books.

What you gain by fixing it: Closing this gap means only your payment provider can mark an order as paid, so revenue and orders always match.

Fix now

Passwords and access keys for one of your environments are stored inside the code itself.

What it may cause: Whoever gets a copy of the code -- a contractor, a leaked laptop, a public repository by mistake -- gets the keys too.

What you gain by fixing it: Moving them out of the code and rotating them removes a standing risk of a data breach and a compliance headache.

Fix soon

The same business rules, such as how discounts are applied, exist in several copies that have already started to differ.

What it may cause: Customers can be charged different amounts for the same basket depending on which screen they use, and a fix in one place does not fix the others.

What you gain by fixing it: One shared version of each rule means consistent prices for customers and changes that take an afternoon instead of a week.

Fix soon

Almost nothing is tested automatically before a release.

What it may cause: Every update is a gamble: a small change can quietly break sign-up or checkout and you learn about it from customers.

What you gain by fixing it: A basic safety net lets you ship improvements faster and with far fewer surprises.

Your roadmap

1
Replace the exposed passwords and keys and move them out of the code

Nobody with a copy of the code can get into your systems
Effort: A few days
2
Add automatic checks around checkout and payments

Payment bugs are caught before customers see them
Effort: A couple of weeks
3
Merge the copied pricing rules into one

Every customer pays the same, correct price
Effort: A couple of weeks
4
Run those checks automatically on every change

The improvements stay in place as the product grows
Effort: A few days

Expert's note

I have read the automated findings against the code and agree with the ranking, with one change: the unverified payment webhook is the most urgent item here, ahead of the committed secrets. The secrets are real and must be rotated, but they are scoped to a staging project; the webhook lets an unauthenticated caller mark any order as paid in production. I removed two duplication findings that flagged generated API clients, which are meant to be identical, and downgraded the god-object finding to medium: it is a genuine constraint on future work but nothing breaks because of it today. Two weeks of focused work on the first four items would move this codebase out of the risk band it is in.