# How technical preparation helps when selling your SaaS > Technical preparation for selling your SaaS makes documentation, ownership, recovery evidence, and clean metrics easier for buyers to trust. A buyer does not pay extra because your architecture diagram looks polished. A buyer pays more when the evidence makes future cash flow easier to trust and the company easier to operate after you leave. Technical preparation raises the price by removing uncertainty that would otherwise become a discount, an escrow demand, a long transition obligation, or a reason to walk away. Founders often start this work after receiving a letter of intent. That is late. Once exclusivity begins, the buyer controls the clock, every missing answer looks suspicious, and your senior engineers lose productive weeks to hurried archaeology. Prepare while you can still fix what the documents reveal. The goal is not a perfect codebase. It is a business whose technical claims can be checked without relying on the founder's memory. ## Buyers price uncertainty before they price code quality Technical diligence answers a financial question: how much money and management attention will the buyer need after closing? Clean code helps, but predictable operations, transferable knowledge, defensible ownership, and reconciled metrics affect that answer more directly. A plain monolith with tested recovery and clear ownership can be safer to acquire than an elegant distributed system understood by one person. Expect the buyer to sort findings into four buckets. A defect that can stop revenue creates remediation cost. Missing evidence creates uncertainty, which buyers usually price more harshly because they must assume an ugly case. Dependence on a founder or one engineer creates retention and transition risk. A mismatch between product activity, billing, and reported revenue undermines confidence in every management number. Do not hide ordinary technical debt. Label it, bound its impact, and show the decision behind it. If a service needs replacement within eighteen months, explain its current load, failure mode, estimated work, and why replacement has not yet earned priority. A buyer can model a known project. A vague assurance that the system has always worked gives them nothing to model. The same rule applies to incidents. A short incident register with dates, customer impact, cause, corrective action, and verification is better than claiming that outages are rare. Never invent a service level from memory. Calculate it from monitoring data and state what the measurement excludes. If older data is unavailable, identify the first reliable date. A bounded gap hurts less than a number that falls apart under sampling. Your preparation should therefore optimize for verification time. Ask how quickly a technically competent outsider can trace a claim to evidence, reproduce a routine operation, and find the responsible person. That time becomes a useful internal measure: if an engineer needs two days and six private messages to explain how invoices map to tenants, the buyer has found integration risk even if the final answer is correct. ## A diligence room must answer questions without you A useful technical diligence room is an indexed body of evidence, not a folder full of screenshots. Give every claim an owner, a source, a date, and a clear status. Keep live documents separate from frozen deal evidence so a buyer knows whether a number changed after you supplied it. Start with an index that can be reviewed in minutes. A simple fragment is enough: ```yaml item: DR-07 question: Can production be restored from backup? owner: platform-team evidence: recovery/2026-06-restore-test.md as_of: 2026-06-18 status: verified exception: search index rebuilt after database restore ``` The exact folders matter less than coverage. Before opening the room, test every index entry against four questions. Can the reviewer open the evidence with the granted role? Does the evidence support the exact claim rather than a neighboring claim? Is the observation recent enough for the decision? Can another employee reproduce it? Mark an item pending when any answer is no. A smaller room with honest status labels is stronger than a large room padded with policies nobody follows. Treat generated exports as repeatable products. Store the query, source system, parameters, timezone, extraction date, row count, and person who reviewed the result. If a spreadsheet contains manual adjustments, keep the original export and add a separate adjustments table with reason codes. This lets a buyer distinguish source records from management judgment. It also lets your team regenerate the evidence when diligence runs longer than expected. Access should expand in stages. Early reviewers may need redacted architecture, policy, and aggregate operating evidence. Later specialists may need controlled access to sampled contracts, security reports, or repository history. Match each stage to the transaction process and legal advice, and record downloads where the room supports it. The point is not to obstruct a serious buyer. It is to avoid scattering sensitive customer and employee information across personal inboxes. Check internal consistency before polishing prose. Service names must match across diagrams, cloud bills, incident reports, and deployment jobs. Employee counts must match the access matrix date. The metric period in a chart must match the underlying export. If two terms refer to the same service, choose one current name and document the old alias. Small naming conflicts force reviewers to ask whether they found two systems or one, and each clarification consumes deal time. Keep a written question log beside the room. Link each buyer request to the supplied items, responsible owner, clarification, and final response. When a question reveals a real gap, update the underlying document for all authorized reviewers rather than sending a private explanation that future reviewers cannot see. Preserve the former version when the correction changes a material fact. A clean correction with an audit trail builds more confidence than quietly replacing a file. Include the current architecture and data flows, repository and deployment inventory, infrastructure accounts, third party services, security controls, incident history, recovery evidence, software licenses, IP assignments, product metrics definitions, and known technical debt. Add an access matrix that identifies who can administer source control, cloud accounts, DNS, billing, monitoring, and customer support. Never place secrets, recovery codes, or raw customer data in the room. Record where those assets are controlled and demonstrate the transfer process later through a secure channel. Use evidence that the buyer can sample. An architecture document should link each production service name to its repository, deployment job, dashboard, data store, and owner. An uptime table should point to the monitor definition and raw export. A dependency inventory should state which scanner produced it and when. A screenshot can support a claim, but it rarely proves the calculation or operating process behind the screen. Version the index and keep a disclosure log. Record what you shared, with whom, on what date, under which request, and whether you later replaced it. This protects both sides from answering different versions of the same question. It also stops the frantic pattern in which a founder uploads `final_metrics_v7.xlsx` and nobody knows whether the buyer reviewed version five or seven. Assign one person to manage requests and one technical lead to approve answers. Engineers should provide evidence, not negotiate wording directly in a dozen email threads. Consistent routing limits interruptions and prevents two well meaning employees from giving incompatible explanations of the same system. ## Founder dependency is visible in routine work Bus factor is not a headcount calculation. It is the set of business operations that fail when a particular person becomes unavailable. Buyers find it by asking who can deploy, restore data, approve cloud access, explain billing exceptions, renew certificates, answer a serious customer escalation, and make architecture decisions. If the honest answer keeps returning to the founder, a large team does not remove the dependency. Map ownership by operational capability rather than job title. For each revenue sensitive capability, name a primary owner, a second person who has performed it, the runbook, required access, and the last successful execution. `Knows about payments` is not ownership. `Reconciled failed renewals last month using the documented query` is evidence. Repository history can expose concentrated knowledge. Run this per active repository and review the result with the team: ```text git shortlog -sne HEAD 418 Ana Patel 63 Rui Chen 11 Dev Bot ``` The output does not prove that Ana alone understands the system. It tells you where to ask harder questions. Compare contribution concentration with code review history, recent incident responders, deployment permissions, and time away from work. Generated commits and repository migrations can distort counts, so never turn this command into a fake bus factor score. GitHub's CODEOWNERS documentation explains that the file can live in `.github`, the repository root, or `docs`, and can request reviews from designated owners. Use that mechanism to make current ownership visible, but do not confuse a review request with transferred knowledge. Pair ownership rules with observed drills: the second owner deploys a release, handles an alert, restores a sample, and updates the runbook while the primary owner stays silent. Pay down the highest consequence dependencies first. Transfer control of the root cloud account and domain registrar through documented company owned identities. Add a second trained operator for payment recovery and production deployment. Record architectural decisions that only exist in private messages. If a founder still needs to support a specialized area after closing, define the time, availability, and scope as a transition service. Hidden dependence depresses price; an explicit temporary service can be valued and negotiated. ## Recovery evidence beats a backup policy A backup that nobody has restored is an intention, not evidence. Buyers care whether the company can recover customer service within a believable time and whether the team understands what will be missing. The distinction between backup completion and recoverability gets blurred constantly, usually until the first failed restore. GitLab's published disaster recovery material describes regular restoration testing for application databases. The lesson is broader than its particular system: test the recovery path, not the existence of archived files. Your test should start with a selected backup, create an isolated target, restore data, start the application, verify tenant boundaries and critical records, and record every manual intervention. For each important store, document the recovery point objective you can actually meet and the recovery time observed in a test. Do not copy objectives from a policy written for an enterprise customer if your tooling cannot meet them. State dependencies such as encryption keys, exact software versions, object storage, DNS, queues, search indexes, and external identity providers. Buyers will notice if your database returns but authentication, file uploads, or scheduled jobs do not. A compact test record should contain enough detail for another engineer to challenge it: ```text Test ID: RT-2026-06-18 Backup selected: db-prod-2026-06-18T0200Z Target: isolated recovery account Restore started: 09:14 UTC Application checks passed: 10:02 UTC Data boundary checked: tenant rows and object paths Known gap: search index required rebuild, completed 10:27 UTC Operator: secondary owner Reviewer: platform lead ``` Run the test with the person who will remain after the transaction. Capture terminal output or job logs, but redact credentials and personal customer data. Open remediation tickets for gaps and link them from the record. A successful test with a documented 25 minute search rebuild is more credible than a policy claiming instant recovery. Recovery also includes control plane access. Verify that company controlled identities can reach the cloud account, source repositories, DNS, certificates, monitoring, status communications, and payment systems when the founder's personal account is disabled. Perform that test before diligence. Discovering a personal phone number as the only recovery factor during a transaction creates an avoidable negotiation problem. ## Security and IP should be boring to inspect Buyers do not expect a small SaaS company to have every enterprise certification. They do expect the seller to know what data it holds, who can access production, how vulnerabilities are handled, and whether the company owns the code it is selling. Confident but unsupported answers turn a normal gap into a trust problem. Prepare a current data flow that marks customer inputs, subprocessors, storage locations, retention paths, logs, analytics, and deletion behavior. Reconcile it against the application and vendor invoices. Old integrations often survive in code or cloud projects after everyone assumes they were removed. Sample production access against the employee and contractor roster, then remove stale identities through the normal audited process. Do not stage a mass cleanup without preserving the evidence of what changed and why. For security work, show the control and its operating history. A policy that says critical vulnerabilities receive immediate attention means little without scan results, issue records, exceptions, and closure evidence. If you accept a risk, name the affected component, the reason, the compensating control, the owner, and the review date. Keep penetration test reports and customer security questionnaires organized, including unresolved findings and the answer versions that customers received. IP diligence deserves its own chain of evidence. Match employees and contractors to signed invention assignment and confidentiality agreements. Identify code written before incorporation, acquired repositories, open source dependencies, commercial libraries, fonts, datasets, and model providers. Flag reciprocal license obligations and packages whose license cannot be identified. Do not ask an engineer to remove a dependency merely because its name looks unfamiliar; establish how the product uses and distributes it first. AI assisted development adds a practical question: what data and source code did the team send to model providers, under which accounts and settings? Document the approved tools, contractual account owner, repository policy, and review controls that actually exist. Do not manufacture a retroactive policy. If practice was informal, state the period, inspect the highest risk repositories, change the process, and preserve the remediation record. Keep customer contracts and promises aligned with technical reality. If sales promised data residency, deletion timing, dedicated environments, or special recovery terms, build a contract exception table and map each promise to implementation evidence. One forgotten side letter can matter more to a buyer than a hundred lint warnings. ## Clean SaaS metrics reconcile to transactions A clean dashboard is not a clean metric. Buyers pay for recurring revenue, retention, growth, and efficient service delivery, so they will test whether management metrics reconcile to contracts, invoices, payment events, credits, and product accounts. Definitions that change silently from one board deck to the next make the whole revenue story less credible. Create a metric dictionary before exporting charts. For monthly recurring revenue, state how you treat annual prepayments, usage charges, setup fees, taxes, discounts, credits, pauses, delinquent subscriptions, currency conversion, and contracted revenue that has not started. Stripe's Billing analytics documentation allows users to configure how it calculates metrics such as MRR and churn. That convenience is exactly why a screenshot is insufficient: the buyer needs the configuration and your independent reconciliation, not just the displayed total. Build a monthly bridge from opening MRR to closing MRR with explicit categories for new, expansion, contraction, churn, and reactivation. Each movement should trace to a stable customer identifier and source event. Keep customer names in a restricted mapping; the diligence model can use anonymized IDs until disclosure is appropriate. The arithmetic should satisfy this check: ```text opening_mrr + new + expansion + reactivation - contraction - churn = closing_mrr ``` Then reconcile closing MRR to the billing system and recurring revenue recognized or deferred in the finance records. The figures may differ for legitimate reasons, but the difference needs a named rule and a reproducible adjustment. Annual cash collected is not annual recurring revenue. Booked contract value is not MRR. An active workspace is not necessarily a paying customer. Keeping these distinctions explicit prevents the common failure in which three teams report three correct numbers that answer different questions. Test cohorts at the customer and revenue level. Customer retention can look healthy while large accounts shrink, and revenue retention can hide a growing count of failed small customers. Separate voluntary cancellation from failed payment when the evidence permits it. Exclude test, internal, partner, and comped accounts by written rules rather than ad hoc filters. Record timezone, period close, and late arriving event treatment so a buyer can rerun the export. Give the buyer raw, minimally transformed tables plus the query or model that produces the headline numbers. Remove unnecessary personal data. A beautiful spreadsheet with pasted values invites suspicion; a plain model with lineage, tests, and a tie out earns confidence. ## Infrastructure cost must explain gross margin Technical diligence connects architecture to unit economics. A buyer wants to know which costs rise with usage, which costs are fixed, what has been deferred, and whether gross margin claims include the services required to deliver the product. Hiding support tooling or production labor outside cost of revenue may improve a slide, but it creates a reconciliation issue later. Map each material infrastructure invoice to a product capability and cost driver. Compute cost by tenant, active user, transaction, stored unit, or model request where the allocation is defensible. If shared resources prevent exact attribution, state the allocation rule and test it against a high usage account. Keep negotiated credits and temporary startup grants separate from steady operating cost. Buyers will normalize them. Inspect concentration as well as totals. One customer may create unusual storage, support, or model inference cost while paying a flat fee. One legacy job may hold enough excess capacity for peak load but run at five percent most days. Explain why the capacity exists, what changes safely, and which customer or reliability promise constrains it. Do not make a last minute cost cut that weakens service during diligence. Produce twelve to eighteen months of invoices and usage exports under consistent categories. Note accounting changes and provider migrations. Reconcile the total to finance, then show the engineering view that separates production, development, security, observability, backups, support, and experiments. Buyers can accept imperfect tagging when the seller discloses the allocation method. They distrust totals assembled from whichever dashboard was easiest to open. Technical debt should enter the same model. List deferred version upgrades, end of life dependencies, manual operations, scaling limits, and reliability work with a consequence and rough effort range. Avoid turning every improvement idea into acquisition debt. A missing dark mode is not a liability. An unsupported database version that blocks security updates is. The distinction tells the buyer whether your backlog is managed or merely large. A Team & AI Audit from oleg.is can identify engineering cost and ownership gaps before they harden into a buyer's discount. The fixed engagement costs $5,000, takes five business days, and carries the stated guarantee of at least $50,000 per year in identified savings or it is free. ## Transition obligations need explicit boundaries A technically prepared sale defines what transfers on closing day and what still needs human continuity. Without that boundary, buyers often convert uncertainty into long founder availability, retention packages for people who were never consulted, or broad warranties about systems the seller cannot fully control. Create a transfer register for source repositories, cloud organizations, domains, certificates, mobile publishing accounts, vendor contracts, monitoring, support systems, data warehouses, payment accounts, and communication channels. For each asset, record the legal owner, administrative identity, billing owner, transfer restriction, planned recipient, and test. Some accounts cannot be assigned and require a new contract or migration. Discover that before the purchase agreement assumes a simple handoff. Separate three kinds of work. Closing transfer moves control of assets and credentials. Knowledge transfer teaches the buyer's operators how the current system works. Post closing development changes the product or integrates it into the buyer's environment. Mixing them creates unlimited obligations. Put dates, hours, response expectations, named people, deliverables, and exclusions around any transition service. Plan access changes as a controlled event. Do not dump passwords into a spreadsheet. Use company controlled identities, buyer approved secure exchange, role based invitations, and a jointly checked runbook. Rotate sensitive credentials after the buyer confirms control, preserving break glass access until the agreed checkpoint. Record who accepted each asset. Retention deserves direct discussion with the team. Identify employees and contractors whose knowledge or relationships matter, verify their agreements, and understand whether they intend to stay. Never promise the buyer that a person will remain without speaking to that person. If the company relies on a small number of people, a credible succession and incentive plan is more useful than pretending everyone is interchangeable. Define unresolved risks rather than hiding them inside transition. If a legacy customer requires a unique deployment, assign its documentation and remediation plan to the disclosure schedule. If the founder must approve one vendor payment for thirty days because account transfer is pending, say exactly that. Narrow, truthful obligations are negotiable. Vague assurances tend to expand when lawyers translate them into contract language. ## Rehearse diligence before the buyer controls the clock A seller should run a hostile but fair rehearsal several months before a transaction. Give an experienced outsider read access to the prepared room and ask them to verify claims without conversational rescue. The exercise should measure missing evidence, contradictory definitions, excessive response time, and operations that still depend on one person. Use a sample request set that crosses functions: trace a reported MRR total to invoices, select an incident and verify its corrective action, restore a backup in isolation, identify every administrator for a production account, follow one customer deletion request through the data flow, locate IP assignments for recent contributors, and deploy a low risk change with the secondary owner. These tests expose gaps that document review alone will miss. Score findings by deal effect, not engineering taste. A missing access log for a production system deserves urgent work. An unpopular framework choice usually does not. For each material finding, decide whether to remediate, disclose, quantify, insure, or accept it. Assign an owner and evidence required for closure. Do not mark a risk complete because a ticket moved columns. Freeze metric definitions before management presentations and have finance, product, and engineering sign off on the bridge. Sample several customers with different billing patterns. Check that the contract, billing record, entitlement, product activity, support tier, and revenue treatment describe the same commercial relationship. Buyers often start with the largest and strangest accounts, so average behavior will not save a weak exception process. Run a management question session with no slides. Ask the CTO or lead engineer to explain the largest operational risk, the last serious incident, the recovery gap, the highest cost driver, and what would fail if the founder disappeared for ninety days. A polished answer is less important than agreement between the answer and the room. If two leaders disagree, resolve the underlying ownership or definition rather than scripting a common phrase. Finally, keep operating the system normally. Buyers examine change history during the process. A sudden burst of closed security tickets, renamed dashboards, and newly signed documents invites reasonable questions. Preparation raises the price when it proves that the company already works in a controlled way. The strongest closing position is simple: the buyer can inspect the evidence, reproduce the important claims, and see exactly which bounded issues remain.