An AI product can have recurring customers while its costs vary sharply with usage. A buyer needs to understand the service delivered, the rights being sold and what happens when customers use more of it. A repository and an attractive revenue chart are only parts of that picture.
Separate the product business from the API account
List the application, code, domain, documentation, customer obligations and permitted data included in the sale. Then map the external services it depends on. Access to a provider account is not proof that its contract, credits, model access or negotiated pricing can be assigned.
Review each dependency’s current terms and the supported change-of-control or account process. Do not assume an API key is a transferable business asset. Plan appropriate invitations, new credentials and service continuity rather than putting secrets in a sale pack.
Reconcile billed revenue with the cost of serving customers
Start with completed periods and consistent currency. Record successful collections, refunds and the operating costs for that same service window. Distinguish recurring plans from one-off purchases. Annual cash collections are not all current-month recurring revenue.
For model costs, use actual billing and usage records where available. For example, Claude provides usage and cost reporting; a token count or an estimate is not automatically the same as a final invoice. Keep credits, discounts and minimum commitments visible rather than assuming temporary pricing continues forever.
| Cost or dependency | Useful test | Common blind spot |
|---|---|---|
| Model usage | Cost by workload or customer cohort where permitted | Average cost hides a few heavy users |
| Hosting and storage | Normal load plus plausible higher usage | Free credits hide ongoing costs |
| Retrieval and third-party APIs | Requests, storage and separate vendor bills | Only the headline model fee is counted |
| Support and maintenance | Actual work needed to operate the product | Founder time is treated as free |
| Rights and access | Code ownership, licences and supported transfer path | Repository control is mistaken for legal ownership |
Hypothetical example: test the margin under heavier usage
Assume monthly customer revenue of USD $4,000, model costs of $1,000, hosting and other API costs of $400, and support/maintenance cost of $800. On those assumptions the remainder is $1,800 before any other expenses. This is not an actual business and is not a valuation multiple.
If model cost rises 50% with no price change and other assumptions remain fixed, the remainder falls to $1,300. If usage doubles, it falls to $800. These are sensitivity cases, not predictions. A buyer should check whether usage limits, product design and customer terms support the response being proposed. Do not assume an immediate price rise is permitted or customers will accept it.
Inspect the technical asset without collecting secrets
- Confirm the seller’s rights to sell the code and identify contractors, open-source components and proprietary third-party material.
- Review deployment and recovery documentation in an appropriately protected environment. Use synthetic data for demonstrations.
- Check how the application handles provider outages, spending limits and failed requests.
- Identify unsupported dependencies, overdue maintenance and any work needed to restart an inactive product.
- Map customer-data retention and permitted transfer obligations. Do not request raw customer prompts or private records merely to demonstrate revenue.
- Plan the supported repository and service-access changes, followed by access review and credential rotation.
A repository transfer is a technical event, not the whole agreement
GitHub documents repository transfer behavior, including the possibility that integrations and secrets remain associated. That makes an access review important. It does not establish the intellectual-property rights being sold or resolve every external service contract.
Keep an asset schedule and a separate dependency schedule. The first says what the parties intend to transfer; the second records which third parties must permit or support it. Unresolved rights should be a visible diligence item, not hidden inside a broad “all assets included” phrase.
Inactive and unprofitable AI businesses need different explanations
For a currently operating loss-making product, show why costs exceed revenue and the evidence behind any proposed improvement. Do not classify it as inactive just to use another valuation method.
For an inactive business with genuine past revenue, separate the historical earning period from current customers and current running costs. Identify what would need repair, renewal or reactivation. Past peak collections are not current MRR. Never-revenue source-code projects remain outside BizAcquir’s present whole-business scope.
Find businesses to compare thoughtfully
On Browse Businesses, select SaaS and use the category, budget and operating-status filters to narrow your shortlist. A listing summary is the start of diligence, not a substitute for the checks above.
Actual public BizAcquir filter interface, captured October 23, 2026. No seller identity or private financial data is shown. Open the image larger to read the controls.
Turn the findings into a clear offer and handover
Summarize the main risks, evidence still needed and tasks that must happen before completion. Compare the whole offer, including included assets, agreed fees, obligations and any installments. Do not assume a price adjustment can cure an untransferable dependency.
Read the unprofitable SaaS guide and the software maintenance handover guide. Buyers can browse SaaS businesses; sellers can prepare a full-business listing.
Sources and further reading
Sources checked on October 23, 2026. Provider features and account eligibility can change; confirm the current options in your own account.
