Sell a software company

Sell a software company: prepare a clear listing on company.ch with location, guide price, revenue and handover. Choose open, discreet or anonymous visibility while private seller data stays protected.

Single listing

For one business with a selectable duration.

CHF99per listing

1 month

Excl. VAT.

  • Publish 1 listing
  • Anonymous or visible contact details
  • Save as draft possible
Register free

No payment before publication.

Subscription

For regular sellers with several listings.

CHF99per month

3 active listings

Billed yearly. Excl. VAT.

  • 3 active listings at the same time
  • Anonymous or visible contact details
  • Change package before publication
Register free

No payment before publication.

Sell a software company: licence or subscription revenue, retention, product rights, code quality, infrastructure, roadmap, support and key-developer dependence

To sell a software company, make licence or subscription revenue, retention, product rights, code quality, infrastructure, roadmap, support and key-developer dependence verifiable and show what a buyer can continue after completion. The offer should connect commercial performance with the contracts, people, assets and permissions that produce it.

Show the transferable value of a software company

Explain licence or subscription revenue, retention, product rights, code quality, infrastructure, roadmap, support and key-developer dependence, the owner's current duties and the exact transaction perimeter. Historic results, current pipeline and forecasts should be separated so buyers can test what is recurring rather than relying on a headline turnover figure.

Prepare industry-specific records and evidence

Prepare revenue cohorts and contracts, licence terms, code and IP ownership, repositories, architecture, dependencies, cloud cost, security, support metrics, roadmap and team roles. Mark ownership, term, notice, transfer restrictions and any consent required; financial data and operating records should cover comparable periods.

Qualify buyers for the operating requirements

Software groups and technical buyers may fit when they can maintain product, security, customer support and development velocity. Screen for the capabilities that protect continuity as well as available capital, and explain which skills can be transferred during an agreed induction. Do not publish source code, vulnerabilities, credentials, customer data, contracts, licence keys and unpublished roadmap. Use anonymised segments, ranges and aggregate performance to support initial evaluation, then open identifying information only for a justified review step.

Transfer work, relationships and access safely

Transfer repositories, build and deployment, domains, cloud, vendors, secrets, support, release plans and technical decisions with credentials rotated. Build a handover list for open work, responsible people, access, deadlines and introductions before the seller's availability reduces.

Related seller guidance for a software company

Compare the broader category or return to the main seller page: sell a company and IT & software.

Questions to resolve before selling a software company

Which licence or subscription revenues and support margins should I evidence for buyers?

Show several comparable periods and evidence for licence or subscription revenue, retention, product rights, code quality, infrastructure, roadmap, support and key-developer dependence. Reconcile financial claims with revenue cohorts and contracts, licence terms, code and IP ownership, repositories, architecture, dependencies, cloud cost, security, support metrics, roadmap and team roles and distinguish transferable performance from work or relationships that depend on the seller.

What code, IP, architecture, dependency, security and roadmap records should be ready?

A focused file should include revenue cohorts and contracts, licence terms, code and IP ownership, repositories, architecture, dependencies, cloud cost, security, support metrics, roadmap and team roles. Explain gaps and exceptions before they affect valuation, warranties or the timetable.

How must I disclose technical debt and reliance on founders or key developers?

Identify which parts of licence or subscription revenue, retention, product rights, code quality, infrastructure, roadmap, support and key-developer dependence depend on the seller, individual employees, major customers, suppliers, premises or permissions. Quantify concentrations and explain which safeguards or transition steps can make the operation less dependent on them.

How can repositories, infrastructure, releases and support responsibility transfer safely?

Transfer repositories, build and deployment, domains, cloud, vendors, secrets, support, release plans and technical decisions with credentials rotated. Test the transfer on real open work and record who owns every remaining exception after completion.