SaaS acquisition technical due diligence is the difference between buying a small, cash-flowing software business and buying a fragile code repository with recurring revenue temporarily attached. A recent discussion in r/SaaS put the issue bluntly: before accepting claims that an app “runs itself,” a buyer should ask the seller to deploy it cleanly on a new server while they watch.

That test is memorable because it targets a problem that financial screenshots cannot reveal: founder dependency. But it should be treated as the start of a disciplined diligence process—not as proof that every seller is hiding a disaster.

Why “Runs Itself” Is a Dangerous SaaS Acquisition Claim

“Runs itself” is one of the most attractive phrases in a marketplace listing. To a buyer, it suggests low owner involvement, predictable cash flow, and a business that can fit around a job, an agency, or another product. To a seller, it is a concise way to communicate that the company does not require a full-time operator.

The trouble is that the phrase is imprecise. A SaaS may need only two visible hours a week for support while relying on undocumented deployment steps, a founder-owned cloud account, a manually checked payment exception report, or a third-party integration no one has tested recently. In other words, low current effort is not necessarily low operational risk.

The original Reddit post, written by an agency owner who says buyers have sent roughly 40 acquisition targets for code review, argued that many buyers price a small SaaS almost entirely on revenue multiples. The author’s central warning was that an app can look passive until a new owner tries to release a feature, recover from an outage, or move infrastructure out of the seller’s personal accounts. (reddit.com)

That warning resonates because micro-SaaS businesses often have an unusual history. A solo developer may have moved quickly to validate a market, made sensible shortcuts to reach early revenue, and continued operating successfully because the same person understands every workaround. None of that makes the company fraudulent. It does mean that the buyer must distinguish between a business with manageable technical debt and one whose operations exist mostly in the founder’s memory.

The better question is not, “Does it run itself?” It is: Can the business continue serving customers, collecting revenue, recovering from incidents, and shipping necessary changes without the selling founder?

The Reddit Debate Got One Thing Exactly Right—and One Thing Wrong

The viral part of the discussion was the proposed fresh-deployment test. The oversimplification was the claim that nobody would sell a SaaS that truly requires little work.

Why sellers can have legitimate reasons to exit

Community responses correctly pointed out that owners sell healthy businesses for many reasons. They may want a lump sum to fund another project, have a cofounder conflict, need to reduce their workload, prefer building over marketing, or simply want to focus on a bigger opportunity. A founder who loves the zero-to-one phase may see operating, selling, and hiring as a distraction rather than a calling.

That distinction matters. Treating every exit as evidence of hidden tech debt can cause buyers to become cynical and miss good opportunities. A functioning SaaS with documented systems and stable customers may be especially sellable because it can be transferred with less founder involvement.

Why the warning still matters

A legitimate motive to sell does not eliminate operational risk. It simply means motive and quality are separate diligence questions. A buyer should investigate both without confusing one for the other:

Why is the owner selling now? This reveals incentives, opportunity cost, founder fatigue, partnership issues, and possible churn or competitive pressure.
What exactly is being transferred? This reveals whether the buyer receives a business system, a usable product, customer relationships, infrastructure access, and the knowledge required to operate all of them.

A seller can be honest about wanting liquidity while still underestimating how much of the company is dependent on their personal laptop, habits, credentials, or tribal knowledge. Conversely, a technically polished product can still be a bad acquisition if customers are leaving or the acquisition channel has dried up.

The lesson for buyers is balance: do not assume bad faith, but do not substitute optimism for evidence.

SaaS Acquisition Technical Due Diligence Starts With a Fresh Deployment

A clean deployment demonstration is a high-leverage first screen because it compresses several questions into one observable exercise. Can the application be built from source? Are environment variables documented? Do migrations work? Is the infrastructure reproducible? Does the seller know the actual path from code to production?

Ask the seller to deploy a copy of the application to a new, isolated environment—not necessarily the production account—using written documentation and without relying on files, secrets, or shell history stored only on their machine. The goal is not to embarrass them over a minor typo. The goal is to learn whether the business has a repeatable operating system.

What a successful demo should include

A useful demo should be scoped and time-boxed. For many small SaaS deals, 45 to 90 minutes is more realistic than demanding a full infrastructure rebuild on the first call. The seller can prepare a sandbox account, but the buyer should choose the environment and ask questions as the process unfolds.

A credible clean-deployment demonstration generally includes:

Cloning the intended repository and checking out the correct branch or release tag.
Creating a new environment from documented configuration instructions.
Provisioning or connecting the required database, object storage, queue, cache, and third-party services.
Running database migrations and any seed steps needed for a test environment.
Building and launching the app through the documented release process.
Verifying login, a core customer workflow, background jobs, emails, and a billing-related test flow.
Showing logs, error tracking, uptime monitoring, backups, and rollback procedures.

A failure during this process is not automatically a deal-breaker. Startups are messy, and a missing variable name can be fixed quickly. What matters is the nature of the failure. Does the seller explain the dependency and repair it transparently? Or do they discover that no one knows where a credential lives, a database schema cannot be recreated, or the deployment depends on their personal computer?

What a fresh deploy does not prove

A green deployment proves that the application can boot in a fresh environment. It does not prove that the business is resilient, secure, profitable, or transferable. A buyer can still inherit poor retention, a vulnerable dependency tree, unreconciled refunds, an inaccessible domain account, or a support burden hidden behind low ticket volume.

Treat the fresh deploy as a gate, not a finish line. It is a fast way to determine whether deeper diligence is worth the time and legal expense.

Go Beyond the Deploy: Test Restore, Billing, and Secrets

One commenter added an important improvement to the fresh-deploy idea: test whether the business can recover from an incident. That is the correct second step. A production service is not operational merely because it can be launched; it is operational when it can fail and be restored without guessing.

The restore test

Ask for evidence that backups exist, are recent, and can be restored. Depending on the company’s architecture, that can include a database restore to a sandbox, restoration of uploaded customer files, or validation that infrastructure configuration can be recreated.

The key question is not whether the seller pays for backups. Many platforms enable snapshots automatically. The question is whether anyone has successfully restored one and whether the restored system is usable. A backup that has never been tested is a hopeful assumption, not a recovery plan.

The billing and webhook test

Billing deserves special attention because recurring revenue can look reliable until an integration fails silently. Stripe, for example, uses webhook endpoints to notify applications about events such as successful recurring payments, disputes, and subscription changes. Stripe documents that undelivered webhook events are retried for up to three days and can be manually processed within its available event-history window, but a SaaS must still correctly receive, verify, store, and act on those events. (docs.stripe.com)

For a subscription SaaS, ask the seller to demonstrate a sandbox payment event and show how it changes the application’s internal state. Then examine a recent sample of real production events: successful renewals, failed payments, cancellations, refunds, upgrades, and chargebacks. If billing reconciliation runs through a cron job, identify where it runs, what alerts exist, and what happens if it fails.

A reasonable operational test can include:

Replaying or generating a test billing event in a sandbox.
Confirming that the app records the correct entitlement or subscription state.
Showing the error-handling and alerting path for a failed background job.
Checking that webhook signatures are verified and duplicate events are handled safely.
Comparing payment-processor subscription records with the application’s active-user records.

The secrets-rotation test

Finally, ask how production secrets are stored and rotated. The seller does not need to reveal secrets during diligence, but they should be able to explain their inventory: database credentials, payment keys, email credentials, OAuth applications, API tokens, encryption keys, and webhook signing secrets.

A transfer plan should specify which credentials will be revoked, recreated, or rotated at closing. This prevents a common mistake in small acquisitions: leaving the former owner with continuing access simply because moving credentials was never planned.

Audit the Codebase for Transferability, Not Perfection

Buyers often approach technical diligence as a hunt for “good code.” That framing is too subjective and too expensive. Almost every bootstrapped product has shortcuts, old libraries, inconsistent naming, and features that should be rewritten eventually. The acquisition question is not whether the code would win an engineering style review.

The question is whether a competent developer can understand, operate, secure, and change it at a predictable cost.

A practical codebase review checklist

A technical reviewer should inspect the repository with the business model in mind. A lightweight landing-page generator has different risks from a healthcare workflow system, a multi-tenant analytics platform, or a product that processes financial data.

At minimum, review these areas:

Architecture: Is the application a comprehensible monolith, or a collection of undocumented services and scripts? A straightforward monolith can be much safer than unnecessary microservices.
Dependencies: Are package versions locked? Are major frameworks or runtimes obsolete? Is there a clear process for vulnerability updates?
Configuration: Are environment variables documented? Are development, staging, and production environments meaningfully separated?
Database: Is the schema under migration control? Are data exports and restores practical? Are there dangerous manual database steps?
Background work: Where do queues, scheduled jobs, imports, notifications, and reconciliation tasks run? What monitoring exists?
Tests and releases: Is there any automated test coverage for core workflows? Can a release be made without manually editing production files?
Observability: Are errors captured? Can an operator find logs, diagnose a slow job, and see whether uptime or payment workflows are failing?
Access: Which accounts, repositories, domains, cloud organizations, app stores, and vendor dashboards must transfer?

A software bill of materials, or SBOM, is useful here even for a small deal. CISA describes an SBOM as an inventory of the components that make up software and positions it as a building block for software supply-chain risk management. For an acquisition buyer, it is not bureaucratic theater: it creates a concrete starting point for identifying outdated frameworks, unmaintained packages, licensing concerns, and exposure to known vulnerable components. (cisa.gov)

Technical debt should be priced, not moralized

Technical debt is not a character flaw. It is a financing decision made with engineering time instead of cash. The seller may have chosen speed over automation because early customer feedback mattered more than a polished deployment pipeline. That can be rational.

But the buyer should turn material debt into a written remediation plan with a cost range, timeline, owner, and effect on roadmap capacity. A $20,000 modernization project is manageable if the acquisition price and post-close budget acknowledge it. It becomes dangerous when it appears three months after closing and consumes all available cash.

Revenue Quality Matters More Than a Clean Repository

The Reddit thread also produced an equally valuable counterpoint: the hardest dollar in a new business is often the first one. Revenue at $3,000 or $4,000 MRR is evidence that some customers have a problem, found a solution, and were willing to pay for it.

That customer proof can be more valuable than elegant code. A buyer can refactor technology; they cannot easily manufacture a segment with genuine demand. Still, revenue quality needs its own diligence process.

What to inspect in the numbers

Ask for read-only access or exports from the payment processor, analytics platform, support tool, and bank statements where appropriate. Do not rely solely on screenshots or a seller-created spreadsheet. Reconcile customer counts, subscriptions, refunds, fees, and net revenue across systems.

Focus on the economic behavior beneath headline MRR:

Is revenue concentrated in one or two customers?
How long have customers remained subscribed?
What are gross and net revenue retention trends?
Is growth coming from new customers, price increases, expansion, or a one-time promotional spike?
What percentage of customers pay monthly versus annually?
How many subscriptions are past due, discounted, grandfathered, or receiving manual support?
What acquisition channels produce paying customers, and are they owned, rented, or founder-dependent?

A product with 80 customers, low churn, and a repeatable inbound channel can justify a meaningful premium even if the interface needs work. A polished app with one large customer, falling organic traffic, and founder-led sales may be much riskier despite better-looking software.

Separate product-market proof from founder labor

A business can report low support volume because the founder answers every high-value customer in private messages. It can claim organic traffic while the seller’s personal reputation, newsletter, or community presence generates most of the leads. It can look automated while refunds, onboarding, and enterprise exceptions are manually handled off-platform.

During diligence, identify each recurring activity and write down who does it, how often, what tools it uses, and whether a new owner can reproduce it. If the company’s essential work happens in a founder’s inbox, head, or personal social account, the buyer is purchasing a job with uncertain documentation—not a passive asset.

How to Price a SaaS When a Rebuild May Be Needed

Revenue multiples are useful shorthand, but they are not valuation logic by themselves. A multiple assumes that revenue will continue, costs are understood, and the buyer can operate the asset after closing. Technical and operational risk affects every one of those assumptions.

Instead of pretending the codebase is either “good” or “bad,” model three scenarios.

The base case

The product transfers cleanly, churn remains broadly stable, the buyer handles routine operations, and only normal maintenance is required. This is the scenario sellers usually emphasize.

The remediation case

The buyer must spend money and attention on deployment automation, dependency upgrades, security fixes, billing reconciliation, documentation, or a partial redesign. Revenue continues, but growth slows while the team pays down operational debt.

The downside case

A key integration fails, a major customer churns, an account cannot be transferred, a security issue requires emergency work, or the codebase proves too brittle to change economically. The buyer may need to rebuild a core workflow while preserving existing customers.

The acquisition price should leave room for the expected cost of remediation and the risk that the downside occurs. That does not mean mechanically subtracting the maximum possible rebuild quote from the asking price. It means negotiating from a view of total capital required: purchase price, legal and accounting costs, migration work, contractor time, cloud costs, post-close support, and working capital.

Deal structure can also reduce the gap between a seller’s optimistic valuation and a buyer’s uncertainty. Consider a transition period, seller-financed portion, holdback, or earnout tied to customer retention. These arrangements require appropriate legal and tax advice, but the underlying principle is simple: when future transferability is uncertain, do not pay every dollar as if it were already proven.

A Better Buyer Workflow for Small SaaS Deals

The fastest way to waste time is to start with a detailed code review before confirming that the business and the seller can pass basic evidence checks. A staged process protects both parties and reduces needless disclosure.

Stage 1: Screen the listing

Review the product, niche, revenue history, customer concentration, traffic sources, expenses, founder involvement, and stated reason for selling. Ask for clarification where claims are vague. “Mostly passive” should trigger a request for a task log, not an argument.

Stage 2: Verify commercial evidence

Sign an NDA where appropriate, then verify revenue and customer data using source systems rather than screenshots. Study retention, refunds, support patterns, and channel dependency. Speak to a limited number of customers only with seller consent and a carefully planned process so that diligence does not create unnecessary churn.

Stage 3: Run operational demonstrations

Request the clean-deploy walkthrough, access-transfer inventory, backup-and-restore evidence, billing/webhook test, monitoring overview, and incident history. These are often more revealing than a week spent debating framework choices.

Stage 4: Conduct focused technical review

Have a qualified reviewer inspect architecture, deployment, dependencies, tests, security posture, data handling, and known backlog. The output should be a prioritized risk register, not an aesthetic verdict on the code.

Stage 5: Price and contract around reality

Translate findings into a 90-day operating plan, a budget, a transition schedule, and a deal structure. Put post-close assistance in writing. Define which accounts transfer, who rotates credentials, what happens to domains and email, and how customer support handoff will work.

This workflow also helps sellers. A founder who can present documentation, automation, account ownership, backup tests, and a clear transition plan sends a stronger signal than someone relying on a revenue chart and a claim that the app needs no work.

What Sellers Should Prepare Before Listing a Micro-SaaS

The best response to buyer skepticism is not a more polished listing. It is operational evidence.

Before going to market, a seller should create a simple transfer package. It does not need to be an enterprise-scale data room. For a small SaaS, even a well-organized folder and a concise operating manual can dramatically improve buyer confidence and reduce diligence friction.

A credible package should include a product overview, architecture diagram, repository access plan, deployment instructions, infrastructure inventory, vendor list, domain and account ownership records, recent backup evidence, monitoring links, recurring task checklist, top support issues, and a roadmap of known technical debt. It should also explain which systems are personal accounts that must be migrated before or at closing.

Sellers should avoid making absolute claims. “Low-touch operations with approximately two to four hours of weekly support, plus a documented monthly billing review” is more believable and useful than “runs itself.” Sophisticated buyers are not looking for perfection; they are looking for honest boundaries around the work they are buying.

AI Makes Some Repairs Cheaper, Not Risk-Free

Several commenters noted that AI coding tools can now help developers understand legacy code, generate deployment scripts, update dependencies, write tests, and document infrastructure faster than before. That is true, and it changes the economics of some small acquisitions.

A buyer may no longer need a large agency engagement to make an undocumented application deployable. An experienced operator can use AI-assisted tooling to map a repository, draft runbooks, identify configuration gaps, and accelerate routine modernization. This can make a formerly unattractive codebase worth considering at the right price.

But AI does not make unknown production behavior disappear. It cannot infer missing customer agreements, recreate a lost secret, validate that a backup restores correctly, or guarantee that a payment edge case will not affect live subscriptions. It may accelerate implementation, but the buyer still owns the consequence of deploying an incorrect change.

The practical implication is not “skip diligence because AI can fix it.” It is “use diligence to estimate what AI can realistically help fix, what requires human domain knowledge, and what is fundamentally untransferable.”

The Real Asset Is Operational Proof

The strongest insight from the community discussion is that code and revenue are both incomplete proxies for what a buyer actually wants. The real asset is repeatable delivery of value to customers.

That includes a product customers use, a clear path by which they discover and buy it, billing that records what happened, systems that keep it available, and enough documentation that another capable person can operate it. If those pieces work without the founder in the room, the buyer may be acquiring a real business. If they disappear when the founder logs off, the buyer is acquiring a project with revenue and a potentially expensive handover.

A clean deployment is therefore an excellent first question. It turns a marketing claim into an observable test. But a responsible SaaS acquisition technical due diligence process goes further: verify commercial quality, restore data, test billing flows, inventory access, inspect dependencies, document the operating model, and price uncertainty honestly.

The goal is not to avoid every imperfect SaaS. That would eliminate many worthwhile deals. The goal is to know whether the imperfections are visible, solvable, funded, and reflected in the contract before the buyer becomes the next owner discovering them.

FAQ

What is SaaS acquisition technical due diligence?

SaaS acquisition technical due diligence is the process of evaluating whether a software product can be securely operated, maintained, transferred, and improved after an acquisition. It typically covers infrastructure, code, deployments, dependencies, backups, billing integrations, security, access controls, documentation, and founder dependency.

Is a fresh deployment test enough before buying a SaaS?

No. It is a powerful early filter because it reveals whether the app can be recreated outside the founder’s existing environment. Buyers should also test backup restoration, billing workflows, access transfer, monitoring, customer retention, revenue quality, and the cost of known technical debt.

Why would someone sell a SaaS that needs little work?

There are many legitimate reasons: liquidity needs, a desire to start another product, cofounder issues, limited interest in marketing, lifestyle changes, or a preference for building rather than operating. A seller’s reason for exiting should be investigated, but it should not be treated as automatic proof of a hidden technical problem.

How should technical debt affect a SaaS acquisition price?

Estimate the cost, timeline, and business impact of necessary remediation, then incorporate those factors into your valuation and deal structure. Technical debt can justify a lower price, a transition period, a holdback, seller financing, or a retention-based earnout—especially when the buyer cannot fully verify risk before closing.

What documents should a SaaS seller provide during diligence?

At minimum, request operating documentation, architecture and infrastructure details, a vendor and account inventory, deployment instructions, backup evidence, access-transfer plan, dependency list or SBOM, financial exports, customer and churn data, support records, and a list of known technical or operational issues.

SaaS Acquisition Technical Due Diligence: How to Avoid Buying a Rebuild