Grade a codebase for acquisition before the first talk

Why a feature list is not enough

Buyers are not buying screenshots. They are buying a product that still needs to work after the handover, when the original team is less involved and the pressure is higher.

A polished demo can hide fragile releases, weak backups, thin tests, or one engineer who knows where everything lives. Those gaps often matter more than founders expect. A missing rollback plan or an undocumented service account can slow diligence, lower trust, and change price, timing, or terms.

The most common problem is simple: too much knowledge sits with one person. The code may look tidy, the app may feel fast, and the product story may sound strong. Then a buyer asks who can ship a hotfix on Friday night, restore production data, or rotate secrets without breaking logins. If nobody has a clear answer, the risk becomes obvious.

Picture a SaaS product with happy customers and steady revenue. The demo works. But releases depend on manual steps, only the founder understands the background jobs, and nobody has tested a full restore from backup. The product still has real value. The buyer just sees operating risk along with it.

That is why a short scorecard helps. Grade the codebase on deploy safety, ownership, test depth, security basics, and data recovery. The conversation gets clearer fast. Instead of debating impressions, both sides can look at evidence, see the weak spots, and decide what needs fixing before serious acquisition talks begin.

The five scores that matter

Start with five scores, not a long product demo. Buyers usually care less about feature count than the risk they inherit on day one.

Use the same 1 to 5 scale for every area:

• 1 means unsafe or unclear
• 3 means working, but with real gaps
• 5 means repeatable, documented, and easy to trust

Score these five areas:

• Deploy safety
• Ownership
• Test depth
• Security basics
• Data recovery

The number alone is not enough. Add one short sentence of evidence for each score. That note should explain why the number is fair.

A good entry looks like this: "Deploy safety: 4/5 - releases run through CI, rollback steps are written down, and the last month had no emergency fixes after deploys."

That gives a buyer something concrete to discuss. Keep it brief. One score, one sentence, one reason.

How to run the review

Start with evidence, not the demo. Ask for the repo, build notes, a current access list, and recent incident history before anyone opens a slide deck.

A first pass does not need a large group. One engineer and one product owner are often enough.

The review itself is straightforward:

• Check whether a new person can build the repo from written notes.
• Ask one engineer to walk through the system, the deploy flow, and who gets called when something breaks.
• Ask the product owner to point out the business-critical paths, release rhythm, and known weak spots.
• Review the last few deploys, test runs, alerts, and backup records.
• Fill in the scorecard with proof such as CI logs, tickets, screenshots, and timestamps.

If a team says, "we usually do that" or "only Sam knows that part," score it lower. Buyers care about repeatable work, not hero stories.

A simple test keeps the review honest. If the team says backups are fine, ask when they last restored production data into a clean environment. If they cannot show the date, owner, and result, the score stays low.

End with a short fix list, not a big rewrite plan. Three actions are enough for a first round: write missing build steps, remove stale access, prove a backup restore, or assign an owner for each service. Buyers do not expect perfect code. They trust teams that know their weak spots and fix them quickly.

How to judge deploy safety

Deploy safety tells a buyer whether the team can ship on a normal Tuesday, not only during a polished demo. A product can have strong features and still be risky if every release depends on one person, a chat checklist, or luck.

Start with recent history. Ask about the last five to ten releases. How many went out cleanly? How many needed a hotfix, rollback, or late-night repair? If nobody tracks that, the score should drop.

A safer setup has a build that works the same way every time, release steps written down, and a rollback plan people have actually used. If someone says, "We can roll back," ask how long it takes and who has done it before. A rollback that exists only in theory does not count for much.

A few questions usually expose the real process:

• Who can deploy if the usual owner is away?
• Where do the release steps live?
• Which parts still happen by hand?
• What breaks most often during release?
• How do you undo a bad deploy?

Manual work is where risk hides. Watch for things like editing server settings by hand, copying files over SSH, changing environment values without a record, or running a secret command only one engineer remembers. Every extra manual step raises the chance of a bad release.

Give high marks only when the team can build, release, and roll back without drama and without a hero.

How to judge ownership

A buyer should know who owns each part of the product before the first deep technical call. If nobody can name the person responsible for billing, authentication, data imports, the admin panel, and infrastructure, risk rises fast.

Start with a simple ownership map. List each service, repo, or product area, then put one named owner next to it. Avoid labels like "backend team" or "our contractor." Names matter.

One owner is not enough for a good score. Ask for a second person who can explain each main part, make a safe change, and answer basic support questions. Healthy teams have backup depth. Fragile teams keep the system in one person's head.

Documentation shows whether ownership is real or just claimed. Good signs are short setup notes, runbooks for common incidents, and handover docs for areas that changed hands. These docs do not need polish. They just need to help a new engineer fix a bug or ship a small change without guessing.

The warning signs are familiar:

• The founder answers every technical question.
• One repo has no clear owner.
• Setup depends on private notes on one laptop.
• A contractor built a core flow and nobody else can patch it.

Ownership is in good shape when the names, backup names, and working docs all line up.

How to judge test depth

Test depth tells you whether the team can catch real failures before users do. A large test suite can still be weak if it mostly proves the app starts and a few pages load.

Start by separating test types. Smoke checks tell you the system boots. Unit tests cover small pieces of logic. Integration tests check whether the app, database, queue, and outside services work together. User flow tests answer the buyer's most practical question: can a customer sign up, pay, reset a password, or export data without surprises?

Coverage numbers help, but only when they match the places that break most often. If billing, login, imports, permissions, or background jobs caused the last few incidents, those areas should have deeper tests than low-risk screens or static pages. A team can have 80% coverage and still leave its most fragile paths exposed.

Ask what the team still checks by hand before a release on a busy week. That answer is usually honest. If engineers still open the app and test checkout, failed retries, or rollback steps themselves, the automated suite is not carrying enough weight.

These questions usually get to the point:

• Which user flows must never fail?
• Which areas caused the last five bugs or incidents?
• What do engineers still test manually before release?
• Which paths does CI skip because they are slow or flaky?

Be careful with green pipelines. A build can pass while skipping database migrations, third-party API failures, partial deploys, or permission edge cases. Score test depth by how well tests cover likely break points, not by how often the dashboard says green.

How to judge security basics

Buyers do not expect perfect security. They want proof that the team knows who can access production, where secrets live, and how they would spot a problem quickly.

Start with secrets. Ask where API keys, database passwords, signing keys, and third-party tokens are stored. If people keep them in shared notes, old chat threads, or plain text files in the repo, that is a bad sign. The team should also know who can rotate them and what happens when someone leaves.

Access control says a lot about daily discipline. Production and admin tools should use named accounts, not one shared login everyone knows. Ask who reviews admin rights, how often they do it, and how they remove access for departing staff or contractors. If nobody can show a recent access review, lower the score.

A few checks catch a surprising number of problems:

• admin panels exposed on the public internet without tight access rules
• shared accounts for cloud, database, or payment tools
• stale credentials that still work after role changes
• old dependencies with known fixes left unpatched
• no clear owner for security updates

Logs matter too. A team does not need a huge security stack to do this well. It does need records for sign-in attempts, admin actions, payment events, and access to sensitive customer data. If a buyer asks, "Who changed this setting last week?" the team should have an answer.

One weak area is common. Four weak areas at once usually mean the system grew without enough control, and buyers notice that quickly.

How to judge data recovery

A backup matters only if the team can restore it under pressure. This score shows how much damage a bad deploy, cloud outage, or human mistake can cause.

Start with one blunt question: "When did you last restore real data from a backup into a working system?" If the team cannot name a date, the recovery plan probably lives in a document instead of practice.

Then check four facts:

• how often backups run
• how long the team keeps them
• where the team stores them
• whether the backups live outside the main production account or server

That last point matters more than many founders expect. If production and backups sit in the same cloud account, one lockout, breach, or deleted project can wipe out both. Retention matters too. A daily backup sounds fine until you learn the team keeps only three days of history.

Next, ask who can run a restore and how long it takes. If only one engineer knows the steps, the company has staff risk. Ask for two times: a full restore and a smaller restore for one customer, one table, or one service. Those numbers show whether recovery is realistic during a busy week.

Look for gaps between the plan and the real system. Many teams back up the database but forget file storage, search indexes, secrets, or background job state. That is common, and it can still break the product after a database restore.

A solid answer sounds specific: "We tested a restore last month, it took 42 minutes, and we had to fix one missing environment secret." That is far better than "We back everything up automatically."

Common mistakes in acquisition talks

Fast shipping can hide risky engineering. Buyers often hear, "we deploy every day," and assume the process is safe. That tells you very little by itself. If each release depends on manual fixes, late-night checks, or one engineer watching logs, the pace hides fragility instead of proving strength.

Old tests create the same false comfort. A repo may show thousands of tests, but that number means nothing if the team ignores failures, skips tests before releases, or no longer trusts the results. One blunt question helps: when a test fails, does anyone stop the deploy and fix the cause?

Ownership gets overstated all the time. Founders often say, "our lead engineer knows this area inside out," as if that removes risk. It usually creates it. If one person holds the setup steps, architecture choices, and production habits in their head, the buyer is inheriting a dependency.

Backups fool people too. A scheduled backup job sounds reassuring, but recovery is what matters. If nobody has restored a clean copy into a fresh environment and checked that the app actually works, the backup is still unproven.

Another trap is the roadmap. A long list of planned fixes, refactors, and future hires can distract from current risk. Buyers are not purchasing next quarter's intentions. They are judging today's system.

When a conversation starts drifting into promises, pull it back to proof:

• a recent deploy with rollback steps
• test results the team trusts
• shared ownership across more than one person
• a real restore drill, not a backup screenshot

That shift changes the tone quickly. The feature list gets shorter, but the picture gets clearer.

A simple example scorecard

Picture a SaaS startup with one web app, one mobile client, and a team of six. The product solves one clear problem, customers use it every week, and the buyer can understand the business in a short demo. That part helps, but it is still only part of the story.

A realistic first pass might look like this:

• Deploy safety: 4/5 - the team ships every week, watches errors after release, and can roll back.
• Ownership: 3/5 - two engineers hold most of the backend knowledge, and handoff notes are thin.
• Test depth: 3/5 - billing and login have tests, but many user flows still depend on manual checks.
• Security basics: 3/5 - access rules are decent, secrets are stored properly, and updates happen, but reviews are informal.
• Data recovery: 1/5 - backups run on schedule, but nobody has tested a full restore in months.

That last score changes the whole buyer conversation. Instead of asking only about growth or roadmap, the buyer starts asking what happens after a bad deployment, a broken migration, or accidental data loss. They want to know who can restore production, how long it takes, and whether the team has done it under pressure.

A weak recovery score also makes stronger areas feel less solid. Good deploy habits matter less when one failed release can turn into a long outage. Mixed ownership and thin tests then look riskier, because fewer people can fix the problem fast.

A 30-day cleanup plan can improve the story a lot:

• Run a full restore test in a separate environment and record the steps.
• Assign clear owners for backend, mobile, and infrastructure.
• Add automated tests for the top revenue paths.
• Put release, rollback, and recovery notes into one short internal document.

The codebase does not need to look perfect. Buyers mostly need proof that the team understands its weak spots and can fix them.

Quick checks before the meeting

Buyers notice two things quickly: whether you know your system, and whether you can prove it. A short prep pack beats a long deck full of product screenshots.

Bring one page that shows the five scores side by side. For each score, add one proof line with a number, date, or short fact. For example: "Deploy safety: 4/5 - 22 production deploys in 45 days, one rollback, recovered in 7 minutes." Details like that calm people down.

Before the call, make sure you can show these without digging through Slack, email, or old tickets:

• a recent deploy record with the date, result, and approver
• an owner list for the main systems, such as the app, database, infrastructure, billing, and authentication
• proof that backups restore
• a direct answer to one hard question: what breaks if one person leaves tomorrow?
• the five scores in the same format on one page

If one score uses data, another uses opinions, and a third has no proof, the whole review feels shaky.

Mixed scores are fine if the evidence is clear. A codebase with a weak backup story but clear owners and clean deploy records often looks safer than one with better claims and no proof.

What to do next

If one score is much lower than the rest, start there. Do not try to improve everything at once. Buyers trust a team more when they see one weak spot fixed cleanly than when they hear broad promises about future cleanup.

Pick a gap that is easy to verify. If deploy safety is weak, write a rollback checklist and run a test deploy. If ownership is unclear, assign named owners for the most important services and repos. If data recovery is the problem, prove that a restore works and save the notes.

Keep the scorecard alive until the buyer review ends. Update the score, date, evidence, and owner each time you close a gap. Keep the wording plain. A buyer should understand it in a few minutes without needing a long engineering call.

An outside review often helps. A CTO or technical advisor who was not part of the original build can spot weak evidence quickly and tell you when your self-scoring is too generous.

If you need that kind of second opinion, Oleg Sotnikov at oleg.is reviews codebase risk across architecture, deployment, testing, security basics, and operations. He works as a Fractional CTO and startup advisor, and that outside view can help founders turn technical findings into a plain-language summary for buyer conversations.

Keep that summary simple: current score, proof, open risks, and what changed this month. Buyers do not need a pitch. They need a clear record that shows the team knows its weak spots and fixes them.