Operational due diligence for a small SaaS before you buy

Why the mess hides outside the code

A neat codebase can give buyers false confidence. You open the repo, see tests, clean folders, recent commits, and assume the hard part is done. Then the service goes down because the weak spots sit outside the app: backups, email accounts, payment methods, server access, and scheduled tasks nobody wrote down.

That is why an operations review matters as much as reading the code. Most outages do not start with a dramatic bug. They start with something dull. A card expires. A domain renewal fails. A mail provider locks an account. A backup job has been failing for months and nobody noticed.

Scheduled jobs are a classic trap. A small script might send invoices, retry failed payments, clear stuck jobs, or generate reports. If that script stops running, the product can look fine for days while money, emails, or customer data slowly drift out of sync.

Access causes even more trouble. Many small SaaS products grow around founder habits, not clear ownership. The app may run under one cloud account, DNS under another, analytics in a personal login, and billing emails in an inbox only the seller controls. You can buy the product and still lack the accounts you need to keep it online.

A simple example shows the problem. Imagine a SaaS with solid code and stable uptime. After the sale, the new owner learns that the backup destination used an old credit card, the billing reminder job stopped weeks ago, the domain renewal notice went to a former contractor, and the seller signed up for a mail service with a personal account.

None of that appears in the repo. Yet any one of those issues can stop the business faster than a production bug. Buyers who skip the operational side rarely buy a clean SaaS. They buy a pile of small surprises.

Ask for the full operations map

A small SaaS can look tidy in the codebase and still be messy in daily operations. Ask for a plain list of everything the product touches in a normal month. If the seller cannot produce that list, slow down.

Start with every service the business depends on, even the boring ones people forget. That usually means hosting, email delivery, DNS, the domain registrar, analytics, support inboxes, error tracking, payment tools, cloud storage, SMS, app stores, and any third-party API that can stop the product if it fails.

One simple sheet works better than a long story. For each service, get four facts: what it does, who owns the account, who pays the bill, and what breaks if it stops.

Ownership matters more than buyers expect. Many small SaaS products run on accounts tied to a founder's personal email or credit card. That creates risk on day one. If billing stays on the seller's card, or recovery emails still go to an old inbox, you do not fully control the business.

Ask where the team keeps credentials today. You want the real answer, not the polished one. A password manager is fine. A shared spreadsheet, a Slack message, or one engineer's laptop is a different story.

Then split the work into two buckets: what runs on its own, and what still needs a person. A nightly backup script, a weekly invoice export, a manual fraud check, a hand-run deployment, or a cron job on an old server all belong on the map.

A good operations map is boring to read. That is the point. It turns hidden work into something you can verify before money changes hands.

Check backups by proving you can restore

A backup matters only if you can use it under stress. Ask what the seller backs up, how often they do it, and what they leave out. Many teams say "we back up everything" when they only mean the main database.

You want a plain inventory. Check whether they save database dumps, uploaded files, object storage, app and server config, environment variables, and any billing or email settings that would slow recovery if lost. Small SaaS products often break after a move because one of those pieces never made it into the backup plan.

Location and access matter just as much. Find out where backups live, who can reach them, and whether the seller controls the account personally. If backups sit in one cloud bucket tied to a founder's private login, that is a handover risk, not a safety net.

A quick review should answer five questions:

• What data gets backed up?
• How often does each backup run?
• Where are the copies stored?
• Who can restore them?
• How long do old backups stay available?

Do not stop at screenshots or a dashboard that says "success." Ask the team to run a small restore test. Restoring yesterday's database dump into a staging environment is usually enough to expose bad credentials, missing files, broken scripts, or backups that never worked in the first place.

Retention matters too. If they keep only the last one or two copies, a slow data corruption problem can wipe out your recovery options. I would rather see a simple backup setup with 30 days of history than a fancy one nobody has tested.

If the seller resists a restore drill, treat that as a warning. Backups are not proof. A working restore is proof.

Inspect scheduled jobs and other silent automations

Scheduled tasks keep a small SaaS alive long after the app code stops changing. They send invoices, sync data, rotate logs, clear queues, build reports, and retry failed jobs. This is often where the worst surprises sit.

Ask the seller to show every schedule live. Check server crontabs, system timers, container schedules, cloud functions, CI pipelines, database jobs, and any hosted automation tool the team uses. A spreadsheet is not enough. You want to see the actual job, where it runs, and who gets alerted when it fails.

Then match each job to a business task. If a job runs at 2:00 AM, what does it do? If nobody can answer in one sentence, that is a warning. Billing, trial expiry emails, analytics exports, backups, fraud checks, and daily reports often depend on scripts nobody thinks about until they stop.

For each scheduled task, confirm five things: where it runs, what data or service it touches, when it last ran successfully, who owns it now, and what breaks if it stops.

Logs matter more than promises. Open the last few runs and look for missed days, retries, timeouts, and silent failures. Some jobs fail for weeks because they write errors to a file nobody reads.

Watch for the messiest setup of all: a task that runs from one person's laptop or home machine. That can be a local script, a scheduled terminal command, or a desktop app left open overnight. If the seller goes on vacation, the business process goes with them.

Time zones cause quieter damage. A job that should run at midnight customer time may actually run on server time, after a daylight saving switch, or twice in one night. That can mean duplicate invoices, broken reports, or missed renewal emails.

Review access, ownership, and account recovery

A small SaaS can look tidy in the app and still fall apart on day one because the real control lives in accounts outside the product. If the seller keeps the domain, DNS, cloud billing, or payment processor under a personal login, you do not own the business yet.

Start with the accounts that can shut the service down fast: the domain registrar and DNS, cloud hosting and storage, business email and transactional email, the payment processor and payout settings, and any admin panel that can lock users out or change billing.

Admin access is not the same as owner access. Ask the seller to show the current owner role on each service and walk through the transfer steps live. An invite to join as admin helps, but it does not solve a blocked transfer later.

MFA and recovery details cause more trouble than most buyers expect. Check backup codes, recovery email addresses, phone numbers, and hardware keys. Then test the path you would use if the seller vanished tomorrow and you had to recover the account yourself.

A common mess is a founder who used a personal inbox for everything. The SaaS still runs, but password resets, invoices, and security alerts go to an address you do not control. Fix that before closing, not after.

Former staff accounts deserve a cleanup. Review every shared tool and remove old employees, contractors, and agencies from admin roles. Check support desks, analytics, email tools, hosting dashboards, and any shared password vault.

If even one account still depends on the seller's phone, email, or backup codes, the handover is incomplete. That usually shows up at the worst possible moment.

Find renewals, billing risks, and quiet dependencies

Annual renewals often reveal the costs nobody mentioned. A business can look fine on monthly profit, then take a hit when a forgotten yearly invoice lands for hosting, email delivery, monitoring, domains, or support.

Ask the seller for one export of every subscription, license, and renewal. It should show the vendor, amount, billing cycle, next renewal date, account owner, notification email, and payment method. If this takes days to assemble, operations are probably scattered.

Look for a few common problems: services paid with a personal card, notices sent to a founder's personal email, plans with usage caps that trigger a higher bill, and support plans that expire soon after the sale.

Personal accounts create messy handovers. If the database backup tool, domain registrar, or cloud account still depends on the seller's inbox or card, you do not fully control the business on day one.

Usage pricing needs a closer look than the invoice total. Some tools stay cheap until you cross a threshold for emails, API calls, storage, logs, or seats. A SaaS that is growing can hit that line fast, and your cost model changes overnight.

Quiet dependencies matter just as much. Teams often forget to mention the DNS provider, error tracking, SMS service, captcha, package registry, cron host, or a paid plugin that keeps admin work running. The app may still work today because those tools are already paid for.

Support plans deserve extra attention. If the seller has a grandfathered contract, a migration credit, or priority help that ends on transfer, you may inherit slower support and higher fees at the same time.

A clean renewal sheet is not busywork. It tells you what the SaaS actually needs to stay alive next month.

Run the handover test step by step

A handover is not a paperwork exercise. It is a live test of whether you can run the SaaS without the seller stepping in after closing.

Sit with the seller and log in to every service that matters: hosting, the domain registrar, DNS, email, analytics, payments, error tracking, the code repository, CI, databases, and support tools. Do not accept screenshots. Shared screen access tells you more than a folder full of notes.

A practical handover test usually has four steps:

1. Start with access. Sign in together, confirm the account owner, and check recovery email and 2FA settings. Change one low-risk password, store it in the buyer's password manager, and note who owns that account now.
2. Pick one background worker or queue consumer that is safe to touch. Restart it during the call and watch what happens. The app should recover cleanly, and alerting should still fire if something breaks.
3. Take a small backup copy and restore it into a test system. You are not checking backup files alone. You are checking whether the team can turn those files into a working database or app without guesswork.
4. Pause one scheduled job that will not hurt customers if it stops for a short time. Wait a bit, then resume it. If no alert appears, no dashboard moves, and no one notices, the business probably has silent failure points.

Keep notes as you go. Record the system name, who owned it before, who owns it now, what worked, and what needed manual help.

If one simple test turns into a 30-minute scavenger hunt, treat that as a real risk. Small SaaS deals often go wrong there, not in the code.

A simple example from a small SaaS takeover

One buyer looked at a small B2B SaaS that seemed healthy on paper. The codebase was tidy, tests passed, and the app loaded fast. In a two-hour operations review, the real risk showed up somewhere else.

The first problem was a nightly import that pulled customer data from another system. The code for it still sat in the repo, but the job had stopped running months earlier after a credential change. Support had patched a few accounts by hand, so the seller did not feel the break every day.

The second problem was billing. The email delivery tool still charged a personal card owned by the founder, not the company. If that card failed or the founder canceled it after the sale, password resets, invoices, and product emails could stop the same day.

The third problem was the domain registrar. The only admin login used an old contractor's email address. He had left, nobody had updated account recovery, and the team could not say for sure who could move or renew the domain.

None of this required fancy forensics. The buyer asked four plain questions: what runs every night, who pays for each service, who owns the domain, and who can recover each account.

That short review changed the deal. The buyer did not walk away, but they did pause signing. They asked the seller to restart the import, move the email tool to a company card, and transfer the registrar to an account with shared ownership and current recovery details.

The code was fine. The operation around it was not. That gap is where many small SaaS handovers go wrong.

Mistakes buyers make during review

Many buyers inspect the app, like the demo, and stop too early. The trouble often sits in the boring parts: backup storage, DNS, email routing, renewals, and scheduled tasks that nobody documented.

One common mistake is trusting screenshots instead of live access. A screenshot can show a cloud account, a backup folder, or a billing page. It cannot show whether the buyer can log in, whether recovery codes still work, or whether the seller still depends on a former employee's inbox.

Backups fool people all the time. Buyers ask, "Do you have backups?" and get a quick yes. Then they move on. A backup matters only if someone can restore it into a working environment and prove the data is usable. I would rather see one messy restore test than ten neat screenshots.

Another blind spot is scope. Buyers review servers and databases, but miss the domain registrar, DNS records, support email, payment webhooks, and third-party login settings. The SaaS may run fine on its cloud instance while the domain expires next month or the support mailbox still forwards to a contractor.

Renewals also slip past review because monthly spend looks normal. The ugly surprises are often yearly: SSL certificates bought outside the main account, plugins, monitoring tools, app store fees, and a domain that renews once a year on someone's personal card.

Scheduled work causes its own mess. Teams often assume every cron job lives on one server. In small SaaS setups, jobs can hide in system cron on old machines, platform schedulers inside cloud services, CI pipelines that run on a timer, serverless functions triggered by schedules, or scripts started by third-party automation tools.

One buyer I know checked the production server, found no cron entries, and felt safe. A week later, invoice emails stopped because the real schedule lived in a forgotten CI runner. That is the kind of miss that turns a calm handover into a repair job on day one.

Quick checks before you close

Right before signing, reduce the review to a short pass-or-fail list. This stage is less about architecture and more about whether you can run the business on day one.

Make sure you can answer these questions clearly:

• Can you name the owner of every account that matters?
• Can you restore recent data into a test environment?
• Can you see every scheduled job and its latest run?
• Can you list the next 12 months of renewals?
• Can you take over alerts, invoices, and the main admin email?

If one of those checks fails, the risk is usually bigger than it looks. A missing owner can lock you out for days. An untested backup can turn a small outage into lost customer data. One forgotten renewal can take the whole app offline.

Do not accept vague answers like "we usually handle that manually" or "it should be in someone's inbox." Before you close, you want names, login paths, and one person who can show each step live.

Next steps after the review

The review matters only if you turn it into a clean handoff. Before money changes hands, move every domain, cloud account, payment profile, support inbox, and analytics tool from the seller's personal identity to a company-owned account that you control.

Do not wait a week to rotate secrets. Change API keys, server passwords, SSH keys, database credentials, and email recovery settings, then write down where each secret lives and who can reach it. A shared password manager and a simple ops document are usually enough for a small SaaS.

Keep the closeout list short:

• Transfer ownership for all accounts, not just admin access.
• Rotate credentials and record them in one place.
• Add alerts for backup failures, billing changes, certificate expiry, and downtime.
• Ask the seller to list every manual task they still do each week or month.
• Run one dry handover where your team handles those tasks without help.

That last step saves buyers a lot of pain. Many small SaaS products still depend on quiet human work, like restarting a stuck import, topping up a third-party balance, or clearing a failed job queue every Friday. If the seller does any of that from memory, write it down now and turn it into a checklist.

You should also decide what happens on day one after closing. Pick one person who owns operations, one place for incident notes, and one simple dashboard for uptime, backups, and spend. Small teams do better with a few clear rules than with a pile of tools nobody checks.

If the handoff still feels messy, get a second technical review before you close. Oleg Sotnikov at oleg.is works with startups and small businesses as a fractional CTO and advisor, and this kind of ownership, infrastructure, and automation review is often where an outside pair of eyes pays for itself.

A buyer who controls the accounts, knows the manual work, and gets alerts early starts with fewer surprises.