Check the code before you buy a SaaS app

1. Get read access to the real repository

There are two ways to do it, depending on how much the seller wants to share before the sale.

• The seller runs the scan. They connect the repository to Zelsis, scan the branch that is deployed and send you the PDF report. The report lists risk areas and each open issue with its file, line and a short snippet. Ask them to share their screen while it runs so you can see the repository name and the commit.
• You run the scan. The seller pushes a copy of the repository to a private repository you own, and you connect it as described in Scan a private repo. This is the stronger option because you control the scan.

2. Read the findings by what they would cost you

Sort the open issues by the damage they could do after the sale, not by count.

• Data leaks: one user reading another's records, database tables without access rules, secret keys in client code.
• Money: prices or amounts the browser can change, payment webhooks without signature checks.
• Account takeover: weak session or token handling, admin routes without a role check.
• Licenses: dependencies whose license limits how you can sell or close the code.

Each of these is something you would pay to fix after closing. Put a fix estimate next to each one and bring it into the price discussion.

3. Check by hand what a scan cannot see

A static scan reads code. It does not see the live database, the hosting account or how the app behaves at runtime. Our list of what Zelsis does not check covers this in detail. Before you pay, check these yourself:

• Every API key and secret will be rotated at handover, including keys the seller may have pasted into chats or old commits.
• Database access rules in the live project match the ones in the repository.
• Backups exist and you have restored one at least once.
• Domain, hosting, payment and email accounts can move to you, and you know which ones are in the seller's personal name.