What a diligence checklist actually contains for a micro AI SaaS

The companion editorial to the Passport thread: everything else a buyer checks. Sellers who read this list twelve months early (the exit-ready thread's argument) assemble it for free; sellers who meet it for the first time inside a deal assemble it under deadline, with leverage draining per week. The checklist, organized as buyers organize it:

Financial

• Revenue verification — the Passport where it exists; reconciled processor exports against bank statements for everything else (screenshots satisfy no one, per the line this platform was founded on). Trailing 24 months or life-of-app.
• The quality reads — cohort retention, churn, concentration, margin honestly computed: the Investors category's revenue-quality and margin worksheets are literally the buyer's workpapers; run them on yourself first.
• Expenses, complete — every API, tool, and contractor serving the app, including the under-your-personal-card ones (the classic omission: the app's true margin includes the subscriptions you forgot you pay).
• Tax posture — returns filed reflecting the app's income, sales-tax exposure assessed (US state economic nexus catches SaaS sellers by surprise; buyers' counsel checks).

Technical

• The fact sheet and its trail — stack, dependencies, AI-authorship and review discipline (the disclosure thread's three questions, answered in writing), audit reports with re-tests where they exist.
• Transferability mechanics — can the buyer actually receive and run this: accounts transferable (some provider agreements aren't — check yours now), infrastructure documented, the runbook real (the continuity checklist from the co-founder category's solo thread).
• The provenance set — dependency licenses scanned, IP assignments complete (yours included, solo founders), no copyleft surprises.

Legal & structural

• Entity and cap table — the solo package from the Investors category's cap-table thread; every financing instrument; the ghost-clearance warranty you'll sign meaning it.
• Contracts inventory — customer terms (what did you actually promise, especially on data and uptime), vendor agreements, anything with change-of-control clauses (they hide in enterprise customer contracts and occasionally in provider terms).
• Data & privacy reality — the flow map from the Auditors category's data thread; policy-versus-practice alignment; what the buyer inherits (retained data is inherited liability — the map prices it).

Operational

• Owner-hours honestly logged — the number buyers triangulate hardest, because it prices their post-close reality; "4 hours a week" claims get tested against support volume and shipping cadence.
• The support record — response patterns, refund history, the complaint file (buyers read your support inbox's shape even when they can't read the inbox).
• Key-person exposure and its mitigations — the runbook, the credentials architecture, the one-outside-person test (same category, same thread).

What's deliberately absent

Growth projections (buyers build their own or don't; yours are read as marketing), valuation argument (the multiple emerges from the above — the 3-5x thread), and anything aspirational: diligence is a past-tense exercise, which is exactly why it can be pre-completed by operating legibly in the past tense all along — the entire forum's recurring thesis, and the reason this checklist cross-references half of it.

Sellers who've been through it: what did a buyer check that this list misses? Additions from the field keep the reference honest.

AXIS Editorial

Follow-up from maker intake: "The change-of-control line scared me — I've never read my provider agreements for it. What am I looking for, and what if I find it?"

The clause shapes: assignment restrictions ('this agreement may not be assigned without consent' — standard boilerplate, matters intensely in asset sales because the agreement is one of the assets), termination-on-change-of-control (rarer, worse), and pricing tied to your identity (partner rates, startup-program discounts that don't transfer). Where they hide at micro-SaaS scale: model-provider terms (check your tier's assignability), app-store developer agreements, enterprise-customer MSAs (the customer's lawyers put it there), and occasionally payment-processor terms. If you find one: don't panic and don't ignore — consent-to-assign is routinely granted for standard vendors (the ask is administrative), enterprise-customer consent is a negotiation input you want to know about a year early rather than mid-close (a customer holding consent leverage over your sale is a discount you can pre-negotiate away), and structure sometimes routes around it (the asset-vs-stock thread's mechanics — one form triggers assignment clauses, the other often doesn't). The finding costs an afternoon of reading; each surprise avoided is measured in closing weeks.

AXIS Editorial

Follow-up from maker intake: "Owner-hours 'tested against support volume and shipping cadence' — I claim low hours honestly, but how does a buyer actually verify that, and how do I evidence it?"

The triangulation buyers run: support-ticket timestamps and response-time distributions (a '4 hours weekly' owner answering tickets at 2am Tuesday through Sunday is self-refuting), commit and deploy frequency against those hours, infrastructure alerting history (how often does something require intervention), and the direct question asked three ways across calls to check consistency. Evidencing it proactively — the same dated-artifact discipline as everything: a maintenance log (even a simple monthly line: hours, what they went to) started now, support metrics exported from whatever tool you use, and automation receipts (the cron jobs, the auto-recovery, the things that don't page you — documented absence of toil is the strongest low-hours evidence there is). The deeper point buyers are pricing: not your hours but the transferability of your hours — 10 honest weekly hours of documented, learnable routine beats 4 mysterious hours of founder-intuition firefighting, because the buyer can hire the first and can't hire the second.

Jonathan (AXIS Launch)

Field addition to the list, from watching processes here: the seller's own diligence on the buyer — absent from every checklist because checklists are written from the buyer's side, and its absence produces the failure mode I've now seen twice: sellers deep in a process discovering late that the buyer can't close (financing not actually committed) or shouldn't (post-close plans the seller finds unconscionable for their customers, with no contractual protection). The reciprocal checks that belong in your process: proof of funds before bidder-room depth (our bidder application requires a funds range for exactly this reason), the buyer's track record with previous acquisitions (ask to talk to a founder they've bought from — the reference call works both directions), and post-close intentions in writing where they matter to you (customer treatment, team, brand) — unenforceable intentions are still dated evidence of what was said. The auction structure handles some of this (bid-binding, vetted bidders), but direct sales especially: diligence is a two-way exercise, and the party doing it in only one direction is the amateur at the table.

AXIS Editorial

Follow-up from maker intake: "How much of this applies below, say, $500 MRR? A full diligence checklist for a $15k asset sale feels like cosplay."

Right instinct, wrong conclusion — the checklist scales down in depth, not in category: a $15k buyer still checks every section, in hours instead of weeks, and the sub-$1k-MRR deals that fall apart do so on exactly the same items (unverifiable revenue, untransferable accounts, a surprise collaborator claim) as the six-figure ones — smaller stakes make buyers less tolerant of friction, not more, because the deal isn't worth much hassle. The micro-scale version of each section: financial = Passport-or-reconciled-exports plus the expense list (an afternoon); technical = the fact sheet and a transfer test (can you actually hand over every account — try it mentally, account by account); legal = the solo cap-table package and IP self-assignment; operational = the runbook at whatever length is true. Call it the one-week version of the twelve-month program — and note the compounding argument inverts at your scale: at $15k, diligence friction is a larger fraction of deal value, so legibility moves your realized price proportionally more, not less.