You Inherited a SaaS Codebase: Audit It Before You Change Anything

When you inherit a live SaaS codebase, do not ship a feature in week one. First get full control of the accounts, make it build the same way on a clean machine, then audit the two risks that end products: writes that can silently lose data, and queries that can show one customer another's data. Pin current behaviour with tests before you change anything. Stabilise first, improve second.

If you would rather have the audit done for you, see how RAITHub would help below. This is the SaaS-specific first week for a founder, a new CTO or an acquirer who now owns software with paying customers and no one who wrote it. It builds on the general taking over a codebase from a freelancer guide, with the parts that matter most for a multi-tenant product carrying real customer data.

Why not start with features on an inherited SaaS?

Because you do not yet know what the code does, and a SaaS with paying customers punishes guesses. A feature change on a codebase you have not mapped can wipe data, cross a tenant boundary, or break a payment path, and you will not have a test to tell you.

An inherited codebase has knowledge that lived in the previous developer's head and left with them: which parts are load-bearing, which are abandoned, what the undocumented assumptions are. Your first job is to recover that knowledge safely, not to prove you can ship. The order below is by how much damage each gap can do and how hard that damage is to undo. Data loss and a cross-tenant leak cannot be undone; a slow page can.

What does the safe first week look like?

Day	Do	Why it comes here
1	Get and verify access: repositories, hosting, database, domains, DNS, email, payment and API accounts, all in your name	If you do not control the accounts, you do not own the product; this blocks everything else
1–2	Confirm backups exist and restore one into a scratch database	A backup you have never restored is a hope, not a safety net, before you change anything
2–3	Make it reproducible: clean checkout, documented env vars, build and run locally and in a staging copy	You cannot safely change code you cannot run the same way twice
3–4	Audit the money and data-loss paths: payments, order/record writes, migrations	These are the changes you can least afford to get wrong
4–5	Audit tenant isolation: can one customer reach another's data?	The most common serious SaaS flaw, and invisible until it is exploited
5	Write characterisation tests around the critical paths before touching code	They record today's behaviour so any later change is deliberate

Only after this week do new features and cleanups begin, and each one lands behind a test.

How do you take control of the accounts safely?

Move every account into your organization's ownership and verify you, not the previous developer, hold the keys. Owning the code is not the same as owning the product; a SaaS lives in its hosting, database, domain and payment accounts too.

Make a checklist and confirm each item: source repositories (you are the owner, not a collaborator), the hosting platform, the production database, DNS and domain registrar, the transactional email sender, the payment processor, and every third-party API key. Rotate any credential the previous developer knew, and remove their access. If something is missing or still under their control, that is the first thing to resolve. The fuller access-recovery checklist is in what to do when a developer disappears with your code.

How do you find the data-loss risks?

Trace the write paths, from the button to the database row, and check three things: that updates change only what the user meant to change, that money and stock move inside a database transaction, and that the schema can be rebuilt from its migrations.

Partial updates are a classic silent data-loss bug. In a pre-launch review of this site, an admin reorder action sent a small update like { id, order }, but a schema helper filled in default values for the omitted fields, so every reorder also wrote published: false and emptied other fields, unpublishing and wiping content. All tests were green. The write-up is zod 4 .partial() keeps default values. On an inherited codebase you find these by reading what actually reaches the database on each write, not by trusting that green tests prove correctness. Check too that payments are idempotent, so a retried request cannot create a second charge, and that the database can be rebuilt from empty using only the migration files; if it cannot, nobody knows what production really looks like.

How do you check tenant isolation?

Log in as one customer and try to read and change another customer's records by changing the ID in the request. Being logged in is not the same as being allowed, and the check must happen on the server for every record, every time.

This is the most common serious flaw in SaaS. The OWASP Top 10:2025 keeps broken access control in first place (OWASP A01:2025 Broken Access Control). The strongest form of the fix pushes the rule into the database with row-level security, so a forgotten check in one handler cannot leak data. A policy that scopes rows to the current tenant looks like this:

-- Rows are visible only to their own tenant, enforced by the database.
ALTER TABLE invoices ENABLE ROW LEVEL SECURITY;

CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.tenant_id')::uuid);

On Sundor Skin, a B2B wholesale platform RAITHub built with 146 PostgreSQL tables and 530+ tests, CI fails the build if a buyer-scoped table has no such policy, and a security suite deliberately tries to read other buyers' data. The pattern and how to add it to an existing schema are in the PostgreSQL row-level security guide; retrofitting it on a single-tenant-shaped codebase is covered in turning a single-tenant app into multi-tenant SaaS.

Why write characterisation tests before changing code?

Because they record what the system does today, even where it is wrong, so any change in behaviour afterwards is a decision, not a surprise. On an undocumented codebase they are your map.

Write them around the three to five journeys that make money or hold data: sign-up and login, the core action the product exists for, checkout or billing, and any admin action that changes customer-visible data. Gate them in CI so a failing test blocks a merge. You are not aiming for high coverage in week one; you are aiming to pin the behaviour you cannot afford to break. The method is in scaling an MVP to production and in how RAITHub tests software.

How long does an inherited-SaaS audit take?

The first-week stabilisation above is roughly five working days for one engineer who knows the stack, assuming access is recoverable. A fuller diagnostic across a mid-sized SaaS, ending in a ranked risk register, is typically two weeks. The main risk of doing it yourself is skipping straight to features: the first feature change on an unmapped multi-tenant codebase is the usual way an inherited product loses data or leaks a tenant.

Buy, build or hire?

Option	What you get	Choose this when
Static analysis and audit tools	Automated scans for known-vulnerable dependencies and some code smells	You want a quick first signal; pair it with a human read of the write and auth paths
Rehire the original developer short-term	The knowledge that left, for a handover window	They are reachable and cooperative; capture it in writing and tests before it leaves again
Audit it in-house	Your own engineer works the first-week checklist above	Someone can read an unfamiliar codebase and has the time before features are due
Hire a fixed-scope rescue	A diagnostic, a ranked risk register and stabilisation of the critical paths	The product has paying customers and nobody in-house can safely map it in time

How RAITHub would help

Because taking over code someone else wrote, finding what is actually wrong, and stabilising the paths the business depends on is exactly what the Code Rescue service does.

• Scope: recover and verify account access; confirm and test a restore from backup; make the build reproducible; audit the money, data-loss and tenant-isolation paths; write characterisation tests around the critical journeys; and deliver a risk register ranked by likelihood, impact and cost to fix, before any change.
• Timeline: a Code Rescue runs 2–4 weeks and starts with a 2-week diagnostic; the rest of the work is scoped in writing before it begins. A single concrete problem can be handled as a fixed-quote fix a specific issue job.
• You receive: the audit memo and risk register, regression tests gated in your CI, a runbook for deploys and rollbacks, and full IP under NDA. The default is to keep your code, not rewrite it.
• Proof: this site has 400+ tests and a documented data-wiping bug found by tracing one admin action; Sundor Skin enforces tenant isolation across 146 tables (530+ tests); PropDesk has 1,024 tests. See the code rescue service.

When you don't need us

• The codebase is small and documented and you can run the first-week checklist yourself.
• You have the original developer for a proper handover. Capture their knowledge in tests and runbooks while you can.
• You want engineers placed in your team. RAITHub offers fixed-scope work and dedicated teams, not staff augmentation.

If you have just inherited a live SaaS and do not know where its biggest risks are, send RAITHub the repository and your stack, and book the free 15-minute technical audit.

Documentation checked on 11 October 2026.

Frequently asked questions

What should I do first with an inherited SaaS codebase?

Get and verify full account access (repositories, hosting, database, domain, email, payments, API keys) in your name, then confirm a backup restores. Only after you control the accounts and can rebuild the environment should you read the code. Do not ship features in week one.

Should I rewrite an inherited codebase?

Usually not. A rewrite throws away bugs already fixed and delays everything while customers wait. Stabilise the code you have: pin critical paths with tests, fix the highest data-loss and tenant-isolation risks, and replace a module only when it keeps failing.

How do I check for a cross-tenant data leak?

Log in as one customer and try to read and change another customer's records by changing the ID in the request. The authorization check must be on the server for every record. Back it with row-level security so a single missing check cannot leak data between tenants.

What are characterisation tests and why write them first?

They record what the system does today, including its quirks, so any later change in behaviour is deliberate rather than an accident. On an undocumented inherited codebase they act as your map and safety net before you refactor or add features.

How do I find silent data-loss bugs in code I did not write?

Trace each write path from the request to the database row and check that an update changes only what the user intended. Partial updates that fill in default values, and money or stock changes outside a transaction, are common causes. Green tests do not prove a write is correct.

How long does a safe first week on an inherited SaaS take?

About five working days for one engineer who knows the stack, assuming access is recoverable: access and backups, a reproducible build, the money and tenant-isolation audit, and characterisation tests on the critical paths. A fuller risk register across a mid-sized SaaS is typically two weeks.