A profitable SaaS business is easier to evaluate when a buyer can follow its recurring income, operating costs and delivery process without relying on the founder's memory. Sale preparation is the work of making that operating picture clear. It is not a reason to remove necessary expenses or promise that every customer will stay.
This guide is for an active software business with paying customers and positive earnings. If the business has stopped trading or is making a loss, use the separate inactive SaaS or unprofitable SaaS guide. Those situations need different assumptions.
Build a revenue bridge a buyer can repeat
Prepare monthly revenue, expenses and profit for the available history. State the currency, period and accounting basis. Separate subscriptions, usage fees, onboarding services, lifetime deals and one-off consulting. A software business with a recurring plan can still depend heavily on non-recurring work.
Show MRR as an as-of-date recurring measure, not total cash collected divided by twelve. An annual prepayment brings cash forward while leaving future service obligations. Record renewals, discounts, cancellations and failed collections consistently. Keep historical peaks separate from today's run rate.
If you use Stripe Billing, check its analytics definitions and export settings. Its MRR, churn and active-subscriber definitions can be configured, and report timezones can differ. Record the settings used so the next owner compares like with like. A billing dashboard is not a complete profit statement.
Hypothetical recurring-revenue example
Assume opening MRR of USD 10,000, $1,000 from new customers, $400 expansion, $300 contraction and $600 churn, with no reactivations or other changes. Closing MRR is $10,500. For the existing opening cohort, net revenue retention on these assumptions is ($10,000 + $400 − $300 − $600) / $10,000 = 95%. New-customer MRR is excluded from that cohort calculation. These are illustrative numbers, not observed BizAcquir results.
A higher closing MRR can therefore coexist with shrinking revenue from existing customers. Include the movement table and cohort definitions rather than presenting growth alone.
Explain retention and concentration
Group customers by starting month or another clearly stated cohort. Review renewals, product usage, support demand and cancellation reasons together. A paying account that has not used the product for months may carry a different renewal risk from an engaged customer.
- Show customer churn and revenue churn separately, with the opening population and measurement period.
- Identify large-customer concentration using anonymized aggregates before sharing sensitive records.
- Explain annual renewals, grandfathered prices and discounts that distort month-to-month comparisons.
- Separate self-serve users from contracts that require consent or a personal founder relationship.
Do not invent a retention benchmark for your business model. The useful question is whether the evidence supports the income the buyer expects to continue.
Reconcile profit with the cost of running the product
List hosting, databases, third-party APIs, payment fees, support, contractors, monitoring, software tools and marketing. Separate recurring costs from one-off projects, but keep a realistic maintenance allowance. Free credits, introductory discounts and the founder's unpaid labour need explicit treatment.
Hypothetical example: USD 15,000 monthly revenue less $3,000 infrastructure/API costs, $2,000 support and $1,000 other operating costs leaves $9,000 before unlisted expenses and taxes. If the buyer needs $3,000 of monthly development support to replace the founder, their planning figure is $6,000. That adjustment is an assumption to investigate, not a new reported profit figure or an automatic valuation.
Keep operating profit, seller discretionary earnings and cash available for distribution distinct. Explain every adjustment and retain the original figures. Use the valuation tool as an indicative starting point, with signup required to view private results; it does not set your asking price.
Prove code and asset ownership
Make an asset register for repositories, domains, trademarks, designs, documentation, datasets and customer contracts. Identify who created each asset and the written rights that allow its inclusion. A repository invitation does not establish ownership of contractor work or rights to redistribute a third-party dependency.
List open-source licences, commercial SDKs, stock assets and upstream data sources. Note assignment restrictions and permissions that need confirmation. Give buyers an appropriate technical review process without posting source code, keys or customer data in public listing fields.
For GitHub-hosted code, follow GitHub's repository-transfer requirements. Repository access, deployment credentials, package registries and hosting access need separate checks. GitHub notes that secrets and deploy keys remain associated after a transfer; plan secure rotation rather than assuming transfer removes old access.
Reduce founder dependence with a real operating test
Log a normal week: onboarding, support, deployments, billing issues, incident response and sales. Record hours and decisions that only you can make. Write short runbooks for repeatable tasks and have an authorized colleague follow one without live coaching.
Use a low-risk test such as resolving a synthetic support issue or deploying to a test environment. Record where the person got stuck, what access was missing and how long it took. Do not manufacture a production incident or expose customer information to demonstrate independence.
Agree a bounded transition: tasks, availability, training sessions and completion criteria. Avoid an undefined promise of unlimited founder support. The founder-independence worksheet can be adapted to software operations.
Prepare dependencies and handover tests
| Area | Prepare before agreement | Check during handover |
|---|---|---|
| Hosting and deployment | Architecture, costs, backups, deployment instructions and provider transfer conditions | Authorized operator can deploy and recover in an agreed safe environment |
| Billing and customers | Recurring obligations, renewal dates, contract restrictions and provider requirements | Agreed customer/service continuity without assuming a billing-account transfer |
| Code and dependencies | Rights register, licences, build instructions and known defects | Buyer can build and operate the agreed version |
| Support and knowledge | Runbooks, backlog, incident history and service commitments | Support routing and escalation responsibilities work |
Separate a change of service access from transfer of a legal contract. Ask each provider about the actual arrangement; do not promise that all accounts can be handed over unchanged. Share sensitive material only through the agreed protected process.
Assemble the sale pack and start a draft
- Financial history and recurring-revenue definitions, with a dated reconciliation.
- Retention, concentration and acquisition-channel summaries.
- Operating-cost schedule and a realistic owner-workload log.
- Asset ownership, dependency and transfer-condition registers.
- Known issues, obligations and a testable handover plan.
On BizAcquir, full SaaS businesses with genuine past revenue can qualify; profit is not an eligibility requirement. Save a draft while preparing. Before first submission, connect an available supported financial account that represents the business and complete its initial import. Provider availability is shown in the connection step.
Listing is free and published listings renew every thirty days until sold. Seller fees are 7% through USD 50,000 inclusive and 5% above that, applied to the whole agreed sale price; buyers pay 2% on top. See pricing and cancellation terms before agreement.
Next: prepare your SaaS listing, or review AI software dependencies if model or API access is central to your product.
