How software-as-a-service businesses are evaluated through recurring revenue, churn, retention, product economics, code ownership and technical dependency.
Profile updated
SaaS businesses can look simple in a financial summary because recurring billing produces a compact set of metrics. Underneath those metrics sits a software product that must remain useful, secure, available and maintainable. A buyer is therefore acquiring both a revenue stream and a technical operating system.
What is SaaS?
Software as a Service (SaaS) delivers software functionality on an ongoing basis, commonly through recurring subscriptions. Customers usually access a hosted product rather than purchasing a perpetual copy. SaaS can overlap with the broader Subscription model and with Application businesses, but a non-SaaS app can also earn through one-time purchases, advertising or in-app transactions.
Example: How this business works
Suppose a software company provides appointment scheduling for independent salons for $29 per month. A salon owner finds the product through Google, starts a trial, configures staff calendars and enters a card to continue. The customer uses the hosted software while billing recurs automatically.
No physical product is delivered each month, but the software must stay useful, secure and available. The team fixes bugs, maintains infrastructure and integrations, supports users, improves the product and acquires customers. Some customers cancel, so new sales alone do not describe the quality of the recurring revenue base.
Major costs include hosting, engineering, support, payment processing and marketing. Profit exists when recurring revenue exceeds the cost of operating, improving and selling the product.
Current marketplace snapshot
Current SaaS market context
Updated
Current listings
6
n=6
Median asking price
$300,881
n=6
Median monthly profit
$10,121
n=6
Median monthly revenue
$28,317
n=6
Median listing multiple
37.5× monthly
n=6
Median seller-reported workload
6 hrs / week
n=6
Median profit margin
70.0%
n=6
Live build-time aggregates over current public Empire Flippers For Sale listings mapped to SaaS. Cohorts overlap when a listing carries multiple monetizations. Missing values are excluded from each median, never counted as zero.
This block shows the current listings classified with this model in Digital Deal Research. It is a cross-sectional view of the marketplace inventory DDR analyzes, not an industry-wide benchmark. A listing can appear in more than one business-model cohort.
How money moves through the business
Customers discover the product, activate or trial it, convert to a paid plan, use the hosted software and renew or cancel over time. The operator maintains product development, hosting, security, billing, support, integrations and customer acquisition. Because customers can churn, new bookings alone do not describe health; retention and expansion matter.
Revenue commonly comes from monthly or annual subscriptions, sometimes combined with usage charges, onboarding, services or higher-tier features. MRR and ARR summarize recurring revenue, while churn and retention show how much of the starting customer base persists. Profit depends on infrastructure, support, development and acquisition cost as well as recurring revenue.
What does the owner actually do?
Ongoing: monitor support, outages, security issues and billing failures.
Regularly: prioritize bugs and features, review customer acquisition and work with developers or customers.
Periodically: make major releases, migrate infrastructure, change pricing or respond to security incidents.
What are you actually buying?
A SaaS acquisition may include source-code repositories, domain and brand, customer subscriptions and contracts where transferable, billing systems, databases subject to privacy obligations, cloud infrastructure, deployment systems, analytics, documentation, support history, integrations and intellectual-property rights.
Verify code ownership, contractor assignments and third-party licenses. Also establish who can operate production after the seller leaves. Access to a code repository is not the same as having a maintainable product.
Economics to understand
SaaS often has high gross margins, but the operating cost needed to keep the product viable can be understated when a founder performs development personally.
Cloud hosting, databases, storage, email and observability.
Engineering, product and design labor.
Customer support and success.
Payment processing and subscription billing.
Sales and marketing.
Third-party APIs and software dependencies.
Security, compliance and professional services where relevant.
Replacement cost for founder-performed technical work.
Metrics worth watching
MRR/ARR and recurring-revenue mix.
Logo/customer churn and revenue churn.
Gross and net revenue retention where available.
CAC, CAC payback and LTV where supportable.
Gross margin and infrastructure cost per customer/usage unit.
Customer concentration.
Trial-to-paid or activation conversion where relevant.
Support volume, uptime and incident history.
Engineering workload and technical-debt backlog.
Potential advantages
Recurring billing makes customer cohorts and revenue retention measurable.
Digital delivery can support high gross margins once the product is operating at scale.
A strong product can serve geographically dispersed customers without physical fulfillment.
Usage, billing and cohort data can provide detailed evidence for diligence.
What can go wrong
Software requires ongoing maintenance even when feature development slows.
Churn can erode the installed revenue base quickly.
Technical debt or weak documentation can create hidden post-acquisition cost.
Security incidents, uptime problems or broken integrations can damage retention.
A product can be highly dependent on one founder/developer or third-party platform.
A SaaS multiple should be read alongside revenue quality and technical transferability. A clean MRR chart is not enough if the codebase cannot be maintained.
High customer or revenue churn.
Customer concentration in a few accounts.
Founder/developer dependency and undocumented architecture.
Security vulnerabilities, poor credential management or weak backups.
Large infrastructure cost sensitivity as usage grows.
Dependency on third-party APIs, app stores or platforms.
Technical debt that requires material redevelopment.
Low product engagement that precedes future churn.
Buyer diligence questions
Who can deploy the product today if the seller is unavailable?
Which parts of the codebase or infrastructure are understood by only one person?
What percentage of customers or recurring revenue is lost each month?
Are newer customer cohorts retaining as well as older ones?
Which third-party APIs or platforms could materially break the product?
What security incidents, unresolved technical debt or deferred development work exists?
Evidence to request or reconcile
Reconcile billing-system MRR to accounting revenue and cash receipts.
Analyze customer and revenue churn by cohort; separate voluntary from failed-payment churn where possible.
Review concentration, contract terms and annual-versus-monthly billing.
Inspect source-code ownership, repositories, commit history and third-party/open-source licensing.
Commission technical review of architecture, deployment, security, backups and known technical debt.
Map infrastructure vendors, APIs and single points of failure.
Quantify founder-performed engineering/support and replacement cost.
Review product usage, activation and support trends for signals not visible in revenue alone.
What a seller should prepare
Export customer-level subscription and cohort history.
Document MRR/ARR definitions and reconcile them to financials.
Provide churn, retention, failed-payment and expansion analysis.
Clean up code ownership, repositories, credentials and deployment documentation.
Prepare architecture diagrams, infrastructure inventory, backup procedures and incident history.
Document third-party APIs, licenses and vendor costs.
List known technical debt rather than leaving it to be discovered in technical diligence.
Create runbooks for deployment, support escalation and security incidents.