Vertical software origination playbook

A research template, not investment advice. Figures are not stated where the public record does not support them.

Sector

Vertical software

2022 U.S. NAICS

513210 · Software Publishers

Classification limits

Starting points for discovery, not a complete niche definition. Classify the actual activity and verify scope against the U.S. Census NAICS reference.

Understand the operating model

Vertical software serves workflows within a defined industry or profession. A genuine product may sit alongside implementation, payments, support and custom development. Origination should identify the workflow and customer type first, then determine whether customers use a common product or separately built systems.

Revenue can include subscriptions, term or perpetual licences, maintenance, implementation and transaction-linked fees. Public pricing establishes an offer, not realized revenue or retention. Workflow knowledge and established customer systems can sustain specialist vendors, but shared ownership, discontinued products and reseller brands can distort a directory-based list.

A software hypothesis asks whether the product solves a recurring customer need with support and development obligations the business can sustain. Test that with product usage, contracts and cohort evidence. It weakens where bespoke projects dominate, a single customer funds the roadmap, or the seller lacks clear rights to the code and embedded components.

What makes a target worth investigating?

These are fit hypotheses to test against your mandate. They are not verified attributes of any company or a prediction of acquisition performance.

• An identifiable product, defined industry workflow and repeatable deployment model.
• Clear separation of product fees, implementation services and third-party pass-through charges.
• Product ownership and technical maintenance responsibilities that can be examined without relying entirely on one developer.

Tailor these questions before collection. Each accepted answer needs a supporting verbatim excerpt from a retained page. Options describe permitted answers, not default assumptions. When no source supports an answer, leave it unanswered; absence from a website is not a “no.” See screening criteria for defining gates and weights.

Four questions apply to every playbook (ownership category, locations, sale process, exclusions) and are listed once on the playbooks overview.

Match every source to the correct entity, location and collection date. Use the data-source directory to choose discovery paths, and evidence standards to decide what an excerpt actually supports.

Ownership and succession signals

• A technical principal who controls architecture and customer commitments may be a continuity dependency. Confirm documentation and development responsibility rather than inferring readiness to sell from product age.
• Compare dated leadership pages with entity records and transaction announcements. A missing management biography is an evidence gap, not proof that the owner lacks a successor.
• These are research signals, not proof of intent to sell. Confirm control, decision rights and succession preferences directly through an approved conversation before treating them as transaction facts.

Read succession and ownership before turning a continuity question into an ownership claim.

Reasons to stop or separate the record

Apply a disqualifier only when supported by evidence and your written mandate. Unresolved facts stay open for review; they do not become negative findings.

• An agency or custom-development practice outside a product-software mandate.
• A reseller brand without ownership or durable distribution rights to the underlying product.
• A workflow, customer setting or deployment model incompatible with the mandate's written scope.

Approach with context and approval

• Reference the actual workflow and customer setting; do not flatter the owner with unsupported claims about market leadership.
• Avoid requesting customer data or source code before appropriate process and confidentiality arrangements.
• The client approves each target and the messaging before contact. Check suppression records and applicable channel requirements; coordinate email, LinkedIn and phone so the business receives one coherent approach.

Use the outreach compliance guide to define channel requirements and suppression handling before optional outreach begins.

Questions for later diligence

These require direct records, management access and appropriate specialist review. Public screening identifies the questions; it cannot settle them.

• Reconcile subscription and licence cohorts, churn, expansion and implementation revenue to contracts and collections.
• Review code ownership, third-party licences, architecture, security practices and technical debt.
• Assess roadmap concentration, support effort, integration dependencies and retention of product knowledge.