Many buyers of small software and subscription businesses see underpriced products and plan to raise prices after completion. Sometimes that is the right call and a large part of the investment case. Sometimes it accelerates churn and damages the very revenue the buyer paid for. The difference usually shows up in diligence, if the buyer looks for it.

Understand current pricing history

• Ask when prices last changed, how customers were told, and what happened to churn and new sales afterwards.
• Check how many customers sit on legacy plans or grandfathered prices, and what their contracts say about increases.
• Look for discounting. Heavy discounting can mean list prices are already above what the market accepts.

Read the contracts

• Some agreements cap annual increases or fix prices for a term.
• Most favoured customer clauses can link one customer's price to everyone else's.
• Annual prepaid plans delay any increase until renewal.

Segment the customer base

• Separate customers by plan, size, tenure and usage. Low-usage, long-tenure customers are often the most sensitive to price changes.
• Identify the accounts that make up most of the revenue and consider how each would react.

Model it conservatively

• Build a simple model with a price change and a range of churn outcomes, rather than a single optimistic case.
• Do not pay the seller for a price rise you have not yet made. Value the business on its current, normalised earnings, then treat pricing upside as the buyer's return for doing the work.

Normalise earnings first with the free SDE and EBITDA calculator and compare against digital business valuation multiples. For how an acquisition runs from brief to completion, see the Acquiry M&A process and our digital M&A research, or start a confidential M&A mandate.

General information only, not legal, tax or financial advice.

Content sites, comparison sites and review publications often earn most of their revenue from affiliate commissions. Affiliate income can be attractive to a buyer because it needs little customer service and scales with traffic. It is also one of the easiest revenue lines to misread, because the business does not control the price, the commission rate or the merchant relationship.

Verify the income at the source

• Ask for read-only access, or screen-shared sessions, for each affiliate network and direct programme dashboard. Screenshots and spreadsheets are a starting point, not evidence.
• Reconcile network payouts with bank deposits for at least twelve months.
• Separate approved commissions from pending ones. Reversals for returns and cancellations can be large in some categories.

Understand concentration

• Rank revenue by merchant, by network and by page. A business where one merchant or a handful of pages drive most of the income carries risk that a headline multiple may hide.
• Ask whether any commission rates are negotiated personally by the owner, and whether those terms survive a change of owner.
• Check recent rate changes. Merchants and networks can cut commissions with little notice.

Check traffic quality

• Break traffic down by source. Search traffic tied to a few keywords is exposed to algorithm updates. Paid traffic arbitrage needs its own margin analysis.
• Look for sudden traffic spikes before a sale. Ask what caused them.
• Confirm disclosure practices and compliance with each programme's terms. A breach can lead to clawbacks or account closure.

Confirm the accounts can transfer

Many affiliate programmes do not allow accounts to be sold or reassigned. The buyer may need to open new accounts and be approved by each merchant. Plan for a gap between completion and the first payout under new ownership, and agree how commissions earned before completion but paid after it will be split.

Price the risk

Normalise earnings for owner labour, content costs and any one-off spikes, for example with the free SDE and EBITDA calculator, then compare against digital business valuation multiples. Where concentration or transfer risk is high, part of the price can be deferred and linked to revenue after completion.

For how a transaction runs from brief to completion, see the Acquiry M&A process and our digital M&A research, or start a confidential M&A mandate.

General information only, not legal, tax or financial advice.

This is the list I would send for a SaaS business with a small team and a single product. It assumes the buyer will run deeper testing later, and focuses on evidence the seller can produce quickly.

1. Architecture and hosting

• A one-page architecture diagram: main services, data stores, third-party APIs and where each runs
• Hosting accounts and who owns them: cloud provider, domain registrar, DNS, CDN and email sending
• Monthly infrastructure cost for the last twelve months, by provider
• Any single points of failure the team already knows about

The ownership question matters more than it looks. Accounts held in a founder's personal name are a transfer task, and sometimes a negotiation.

2. Code and delivery

• Repository list, with the hosting platform and who has admin access
• How code reaches production: build steps, automated tests and who can deploy
• Test coverage for the core billing and account logic, even if overall coverage is low
• Open-source dependencies and their licences, particularly any copyleft licences in shipped code

A buyer does not need perfect engineering. It needs to know whether a new team can make a safe change in the first month.

3. Security and access

• Who has production access today, and how it is granted and removed
• How secrets and API keys are stored
• Any security incidents or customer-reported vulnerabilities in the last three years
• Any recent penetration test or security questionnaire answered for a customer

Ask for summaries, not credentials. No buyer needs live keys before completion.

4. Data and privacy

• What personal data the product stores, where, and for how long
• Backup frequency and the date of the last successful restore test
• Customer contracts that impose data location or security obligations
• The privacy policy and any data-processing agreements in place

A backup that has never been restored is an assumption, not a control.

5. People and knowledge

• Who built and maintains each part of the system, including contractors
• Which parts only one person understands
• Existing documentation, runbooks and on-call arrangements

In small businesses, key-person risk is usually the largest technical risk. It belongs in the transition plan and, where needed, in the deal structure.

6. Product and platform dependencies

• Third-party APIs the product cannot function without, and their pricing and terms
• App store, marketplace or integration listings that drive acquisition
• Any deprecation notices or pricing changes announced by those providers

How to use the answers

Sort each answer into three groups: evidence provided, evidence promised, and claims without evidence. The first group supports the price. The second sets the diligence plan. The third should shape the terms, through specific warranties, a holdback, or conditions on completion.

The aim is not to fail a business on engineering quality. It is to know, before signing, what the new owner will have to fix and what that will cost.

For a fuller checklist with evidence requests and failure signals, see the SaaS technical diligence checklist. More research on software acquisitions is at Acquiry.