Micro-SaaS acquisition due diligence for solo products

A one-developer Micro-SaaS can be a good acquisition precisely because it is small. The codebase may be understandable, the customer promise may be narrow, and the operating costs may be visible. The same concentration creates the main risk: the product, production system, support queue, billing account, and customer memory may all exist inside one person's head and personal accounts.

The buyer should not ask whether the code looks like a larger company's code. That test rejects profitable simplicity and still misses the dangerous parts. Ask whether another competent person can operate the business without the seller's memory, credentials, or daily judgment. Price the gap between today's answer and a proven yes.

Good Micro-SaaS acquisition due diligence separates defects that can be fixed after closing from dependencies that block control on closing day. Untidy modules are usually fixable. An untransferable domain, an undocumented data restore, or a seller whose personal identity owns the payment flow can stop the business. That distinction should drive the review, the purchase agreement, and the transition calendar.

You are buying a control system, not a repository

The acquisition includes every asset and permission needed to accept money, deliver the promised result, recover from failure, and answer customers. Source code is only one part of that system. I have seen buyers spend days debating framework choices while nobody checked who owned the domain registrar or whether the production database had ever been restored.

Build an asset map before reviewing implementation details. For each item, record the current owner, the proposed owner after closing, the transfer method, the person who can approve that transfer, and evidence that the transfer works. Cover at least these groups:

• Company, domain, trademarks, and customer contracts
• Source repositories, package registries, build systems, and deployment accounts
• Cloud, database, storage, email delivery, monitoring, and support access
• Payment processor, bank payout settings, tax records, and subscription data
• Analytics, documentation, design files, marketing channels, and third-party licenses

Ownership and access are different. A seller can add you as a repository administrator without transferring the organization that owns the repository. They can share a cloud login while the recovery email still points to a personal inbox. They can export customer rows while subscription tokens, dispute history, and tax settings stay in the seller's payment account. Mark each asset as transferred only when the buyer controls billing, recovery, and administrator changes.

Use a fresh buyer-controlled identity for every transfer. Do not accept a folder of the seller's passwords as the final state. Shared credentials hide attribution, complicate revocation, and often violate a provider's account rules. The seller can use a temporary named account during transition, then the buyer can revoke it after the last accepted handover task.

The first diligence output should be a control ledger, not a prose report. A spreadsheet is enough if every row has an owner, evidence, due date, and blocking status. Anything marked "seller personal account" deserves an explicit transfer test before money moves.

Continuity risk lives in decisions the code never recorded

Continuity risk measures how much recurring judgment disappears when the developer leaves. It is related to the familiar bus factor, but the usual commit-count calculation is too narrow for a one-person company. A repository may be easy to understand while production still depends on the seller remembering which customer import needs a manual cleanup every Friday.

Start with the Git history because it gives you a cheap baseline. Run these commands in a full clone, not a source archive:

git shortlog -sne HEAD
git log -n 500 | sed -n 's/^Author: //p' | sort | uniq -c | sort -nr
git log -1

The first command returns commit counts beside author names and emails. The second shows author concentration across the latest 500 commits. The third prints the latest commit with its author, date, and message. These outputs can reveal abandoned work, contractor involvement, or multiple identities for one person, but they cannot tell you who deploys, approves refunds, renews certificates, or calms an angry customer.

Map recurring decisions next. Ask the seller to narrate the last deployment, outage, refund, failed payment, backup check, dependency update, and difficult support case. Request the actual ticket, command history, log event, or provider record for each story. A polished operating manual written for the sale tells you less than a messy ticket that shows what happened under pressure.

Score each recurring activity on two axes: frequency and seller judgment. A yearly domain renewal is infrequent but fatal if missed. A daily support reply is frequent but easy to delegate if the answer follows a written rule. The dangerous activities combine material consequences with a decision that no one else can reproduce.

Then make a second person perform one real cycle in a safe environment. They should deploy a harmless change, restore a backup into an isolated database, answer a representative support ticket, and trace one subscription from checkout to payout. Observation is not transfer. Continuity improves only when someone other than the seller completes the task and leaves evidence.

A fast code review should follow failure paths

The best code review shortcut is to trace the product's money path and its worst credible failure, then verify the boundaries around both. Reading files in directory order wastes time. Style consistency matters far less than whether a failed webhook loses an order or whether a retry bills a customer twice.

Begin at the public request that creates value: signup, upload, scheduled job, API call, or purchase. Follow it through authentication, validation, database writes, background work, third-party calls, customer notification, and billing state. At each boundary, ask what happens on timeout, duplicate delivery, partial success, and malformed input. You want explicit answers in code or tests, not the seller's confidence.

A focused review can use five passes:

1. Reproduce the build and tests from a clean machine or disposable environment using only checked-in instructions.
2. Trace one successful customer action and one failed action across logs, database records, queues, and notifications.
3. Inspect authentication, administrator functions, tenant separation, input validation, secret loading, and data export or deletion.
4. List direct and transitive dependencies, their versions, licenses, update state, and any packages fetched outside the normal package manager.
5. Compare the deployed artifact and configuration with the reviewed commit.

The fifth pass catches a common acquisition failure. The seller sends a clean repository, but production contains a manual patch, an uncommitted environment value, or an old worker image. Ask the current deployment to expose a commit identifier or artifact digest. If it cannot, record that as a control gap and rebuild a staging copy from the repository.

Do not turn dependency age into a score by itself. An old, stable library behind a narrow boundary may cost less to own than a current framework with frequent breaking changes. The useful questions are whether the version has known exposure in this product, whether the team can rebuild it, and how much work an urgent update would require.

OWASP's Software Component Verification Standard makes a sharper demand than "run a vulnerability scanner." Its inventory requirements call for direct and transitive components and versions to be known at build completion, with an accurate machine-readable inventory. I agree with that standard for acquisitions, but I would apply it proportionally: a small product needs a reproducible dependency inventory and ownership of private packages, not a week of ceremonial security paperwork.

Reject the popular recommendation to rewrite unfamiliar code immediately after closing. Buyers like the idea because a new stack feels controllable. A rewrite removes the production behavior you just bought, creates months of parallel systems, and asks a new team to rediscover edge cases while customers keep paying. Stabilize, add characterization tests around revenue and data paths, then replace only the parts whose measured cost or risk justifies it.

Operations must work without the seller's laptop

An operable product can be deployed, observed, restored, and supported from buyer-controlled systems. If any routine action requires the seller's laptop, phone, home IP address, or personal inbox, the acquisition has an unresolved dependency even when the source code is excellent.

Walk through production as a sequence. A customer request reaches DNS and a front door, application code runs, data moves through stores and queues, outside providers respond, logs and alerts record the result, and a human handles exceptions. Name the account, region, service, configuration source, and alert recipient at each step. Screenshots are weak evidence because they age quickly; exported configuration, infrastructure definitions, and a successful test are stronger.

Backups deserve a live restore, not a green status badge. Create an isolated destination owned by the buyer, restore the latest backup, and run checks that matter to the product: row counts, attachment access, tenant boundaries, subscription references, and a sample login. Record the recovery point and elapsed recovery time you actually observed. Do not accept targets copied from a policy that nobody has tested.

Consider a failure I have encountered in several forms. The application database backs up every night, so the dashboard looks healthy. Customer uploads live in object storage under a different personal cloud account, and the database stores only object paths. The buyer restores the database successfully, sees thousands of valid records, and discovers that every customer document is missing. A service inventory would have exposed the second store; a restore drill would have proved the loss before closing.

Monitoring also needs an owner. List the conditions that wake a person, the channel that receives them, and the action expected. An alert routed to the seller's muted phone is not monitoring. During transition, trigger a safe synthetic failure and watch the buyer receive, diagnose, and close it.

Support is part of operations. Export open conversations, canned replies, refund rules, known product limitations, promised exceptions, and the identities of customers who require manual handling. Read a sample of resolved tickets beside the related code changes. This connects customer language to technical behavior and exposes commitments that never reached a contract or backlog.

Security review should prove containment and recovery

Security diligence should determine what an attacker or operator mistake can reach, how the buyer would detect it, and whether the business can recover. A long scanner report without product context creates negotiation noise. A short proof that one customer can read another customer's data should stop the deal until the seller fixes or prices the exposure.

Start with trust boundaries. Identify public endpoints, administrative paths, worker inputs, file processing, outbound webhooks, and every place customer-controlled data becomes a command, query, template, or URL. Verify authorization at the server-side resource boundary, not only in the interface. For a multi-tenant product, test two ordinary accounts and attempt to cross tenant identifiers in requests, exports, attachments, and background jobs.

Search the full Git history for secrets with a purpose-built scanner, then rotate anything that ever reached the repository. Deleting the current line does not remove earlier commits or copies. Inventory production secrets by service and owner, move them into buyer-controlled storage, change them during a planned window, and prove the old values fail. Rotation is complete only after jobs, webhooks, and disaster recovery use the new values.

Review data promises against behavior. Compare the privacy notice, customer contracts, and support answers with collected fields, log contents, backups, analytics, deletion jobs, and third-party processors. The issue is often not exotic exploitation. It is a product that says it deletes an account while backups, file storage, or an analytics export retain identifiable data with no defined expiration.

Licenses and ownership belong in this review because they affect the right to operate the code. Get written assignments from employees and contractors, identify copied commercial components, and verify the terms for fonts, templates, datasets, model outputs, and private packages. Counsel should confirm the final structure. The technical reviewer should still trace each questionable asset to the shipped product rather than handing legal a raw dependency list.

Customer promises can outweigh the public roadmap

The buyer inherits the product customers believe they purchased, including specific exceptions the seller granted in email or support. A tidy feature list does not show renewal promises, custom retention periods, grandfathered prices, or workflows that depend on a manual favor. These commitments turn into engineering work after closing whether or not they appear in the repository.

Build a promise register from contracts, order forms, support conversations, sales email, product copy, invoices, and the seller's calendar. Record the customer, promise, source, expiration or renewal date, operational owner, and product behavior that satisfies it. Do not copy every friendly sentence. Capture commitments that change access, price, data handling, response time, or required functionality.

Test entitlements against billing rather than trusting plan names. Solo products often accumulate overlapping states: a current monthly plan, an older annual plan, a lifetime purchase, an account the seller comped, and a canceled customer who still has access after a support exception. Export active billing records and compare them with application permissions. Investigate both directions, paid customers without access and active accounts without an explainable payment or grant.

Grandfathered behavior needs an explicit decision. Keeping an old plan may be cheap if the same code path serves everyone. It may be expensive if one customer pins an obsolete integration or requires a manual monthly job. Calculate the cost to honor the promise through the next decision point, then choose whether to retain it, renegotiate it with the customer, or make the liability part of the transaction terms. Do not silently remove it after closing and call the resulting churn unexpected.

Ask the seller to onboard a representative new customer while the buyer observes. Start before payment and continue until the customer receives the promised result. Record every copied value, private script, manual approval, data correction, and follow-up message. Then let the buyer repeat the onboarding in a test account. This exercise finds work that neither code review nor financial statements reveal.

Review recent cancellations and refund conversations as product evidence. Customers often describe the actual limitation more clearly than the backlog does. Separate acquisition fit issues from defects, confusing setup, missing outcomes, and support dependence. You do not need to accept every request as a roadmap item, but you do need to know which limitations drive refunds and which customers were promised a fix.

Treat the published roadmap as an intention unless a contract makes it an obligation. Estimate committed work from artifacts such as designs, partial branches, provider approvals, and acceptance notes. A seller saying a feature is "almost done" has little value when the remaining work includes migration, billing changes, documentation, and support. Price completed, testable capability differently from optimistic progress.

The business model sets the engineering budget

Technical debt matters when it changes cash flow, support load, security exposure, or the cost of a planned change. Buyers often label every untidy function as debt, add imaginary rewrite estimates, and think they negotiated intelligently. That approach ignores the product's margins and directs attention away from seller dependence.

Normalize revenue at the customer level. Reconcile the billing export, bank payouts, refunds, disputes, credits, taxes, and manually granted access. Separate recurring subscriptions from setup work, consulting, lifetime deals, and revenue that requires the seller's personal service. A product with steady subscription receipts can still be a disguised job if the seller manually prepares each customer's result.

Measure concentration in work as well as revenue. One customer may account for a modest share of receipts but most support time because of a custom import or undocumented feature. Pull ticket counts, response time, manual database changes, and customer-specific branches or flags. Interview evidence matters, but system records show the cost more reliably.

Convert diligence findings into annual ownership cost. Use ranges for uncertain work and state the assumption behind each one. Include at least:

• Seller tasks that require a replacement operator
• Hosting and provider costs at current and expected usage
• Immediate security or reliability fixes needed to keep operating
• Contracted support, license, tax, and compliance obligations
• Product changes already promised to retained customers

Do not claim savings from automation until you have run the automated path on actual work. A support classifier may draft answers, but a person still owns refunds and unusual account states. An AI coding tool may make a new engineer faster, but it does not supply missing production credentials or explain an unwritten pricing exception.

Value the product on transferable cash flow after those costs, not on the seller's claimed hours. If the owner says the business takes two hours a week, compare that statement with deployments, tickets, provider dashboards, and manual jobs over several months. Low recorded activity can mean good automation. It can also mean deferred maintenance.

The transition agreement needs observable acceptance

A transition works when the buyer can demonstrate control and the seller has a bounded obligation to fix transfer gaps. An agreement that promises "reasonable assistance" for a few weeks leaves both sides arguing about whether a broken deployment is training, a defect, or new work.

Define acceptance tests before closing. Attach a transition schedule with the asset, test, evidence, owner, due date, and consequence of failure. Keep business terms in the agreement and operational detail in an editable schedule that both parties approve. The seller should know exactly what counts as done.

A compact acceptance file can look like this:

asset: production_deployment
buyer_owner: [email protected]
seller_access: temporary_named_user
acceptance:
  - buyer deploys reviewed commit to staging
  - buyer promotes release to production
  - buyer rolls back release
evidence:
  - pipeline run identifiers
  - deployed commit identifier
  - rollback timestamp
deadline: before_closing
blocking: true

The file is not the contract. It forces a precise conversation and gives the technical team a repeatable test. Use equivalent records for the domain, payment account, backup restore, support inbox, signing certificates, package registry, analytics, and any mobile store or marketplace account.

Match payment structure to unresolved risk. Assets that must exist for control should transfer before closing or sit behind a closing condition. Gaps that are fixable but uncertain can support a holdback or escrow released against named acceptance tests. An earnout can keep a seller interested in retained revenue, but it should not substitute for transferring control. If the seller must continue running production to earn the purchase price, the buyer has not completed a transition.

Use a paid, time-bounded support arrangement for post-close help. State availability windows, response expectations, included hours, hourly rates beyond them, and the difference between explaining existing behavior and building new features. Unlimited chat access sounds friendly during negotiation and becomes resentment on both sides.

Plan credential rotation as a sequence, not one dramatic reset. Transfer recovery channels first, add buyer administrators, test access, rotate low-risk credentials, then handle payment, production, signing, and root credentials during observed windows. Keep the seller's named temporary account until the agreed tests pass. Revoke it at the end and preserve audit records.

If the seller resists observable tests because "this is a tiny product," reduce the purchase complexity, not the evidence. Small systems are easier to test. Their concentrated ownership makes the tests more necessary.

The first month should reduce unknowns

The first month after closing should preserve customer behavior while removing seller-only dependencies. Do not launch a redesign, framework migration, pricing overhaul, and infrastructure move together. Every simultaneous change destroys evidence about the cause of a failure.

Freeze avoidable changes for the first operating cycle. Keep a decision log for incidents, refunds, manual fixes, and customer exceptions. Turn each new seller question into a durable artifact: a runbook entry, test, alert, script, or product rule. Record the answer once, then prove another person can use it.

Add characterization tests around the paths already producing money. Capture current behavior for signup, entitlement, renewal, cancellation, export, and deletion before "cleaning up" the implementation. These tests do not declare the behavior ideal. They tell you when a change alters what customers receive.

Move provider billing and recovery to the buyer, then inspect the first complete billing and payout cycle. Reconcile new subscriptions, renewals, failures, refunds, disputes, fees, taxes, and bank deposits. This catches transfer damage that application monitoring cannot see.

Set a short weekly operating review with one page of evidence: revenue exceptions, support outliers, failed jobs, security events, deployment results, and open transfer items. End the meeting by assigning an owner and acceptance test to each gap. Remove the meeting when the evidence becomes routine and the seller is no longer a hidden participant.

Some deals should stop before closing

Walk away, delay closing, or change the structure when the seller cannot prove control of a material asset, reproduce production, or explain what customers were promised. A discount does not cure the absence of the legal right or technical ability to operate the product.

Treat a refused production walkthrough as more serious than ugly code. Treat an untested backup as unknown recoverability. Treat revenue that cannot be reconciled to payouts as unverified. Treat a contractor-owned repository or personal payment account as a closing problem, not post-close cleanup.

Seller behavior supplies evidence too. A capable solo developer may have sparse documentation because time was scarce, yet they can usually demonstrate the system, admit weak spots, and help design a test. Evasion, constantly changing explanations, or pressure to skip provider-level evidence suggests that the unknowns are not random.

Do not demand enterprise ceremony from a small product. Demand control proportional to the harm: ownership records, a clean build, tested recovery, traceable revenue, explicit customer obligations, and a transition another operator can complete. Those proofs fit a lean business and protect both parties from arguments after the money moves.

For a buyer without an experienced technical operator, the Team & AI Audit from oleg.is can turn the repository, workflows, and staffing assumptions into a five-business-day cost and risk assessment before a larger transformation. Whether you use outside help or your own engineer, require evidence tied to acceptance. The deal becomes manageable when every material dependency has an owner, a test, and a consequence.