Most deals look similar: a product, a codebase, customers, a roadmap, and a team that claims it can execute. Standard diligence playbooks assume the company produces enough “signal” to validate those claims—usage telemetry, churn cohorts, incident logs, security evidence, and delivery metrics. Special situations break that assumption. The company may be early and thin on instrumentation. It may be service-heavy, where delivery heroics hide product gaps. It may have open-source exposure that stays invisible until procurement demands an SBOM. Or it may sell into regulated verticals where documentation and audit evidence matter as much as features.
17.1 Early-stage or Pre-telemetry Businesses: Alternate Evidence Sources
Early-stage and pre-telemetry businesses are often compelling precisely because they are not fully mature. The diligence challenge is that the usual “hard” evidence is missing or unreliable: event tracking is partial, cohorts are small, renewal history is thin, and operational tooling is lightweight. Your goal is not to penalize immaturity; it is to underwrite whether the company is building toward a scalable system or improvising in ways that will later become binding constraints.
Shift the lens from “what has been measured” to “what can be proven.” In mature SaaS, you prove product reality through telemetry and retention curves. In the early-stage, you prove it through customer behavior, workflow depth, and repeatability of delivery. That requires a different evidence stack and an explicit confidence label.
First principle: do not let missing metrics become an excuse to accept narrative. Replace them with proofs that are harder to curate: customer artifacts, implementation trails, usage proxies, and code-level signals. You are looking for evidence that customers use the product for real work, that the problem is repeatable (not a one-off), and that the team can deliver without permanent heroics.
A practical way to organize early-stage evidence is a three-layer stack:
- Customer layer: what customers do, say, and pay for, captured through interviews, renewal artifacts, and implementation footprints.
- Product layer: what the product does in core workflows, validated through demos, hands-on testing, and configuration review.
- Engineering layer: how safely the product changes and runs, validated through repo, CI/CD, and operational traces (even informal).
Customer layer: Treat customer interviews like a measurement tool. Avoid “do you like it?” and instead focus on behavioral change: what they did before, what they do now, what breaks, who uses it daily, and what would cause churn. Because early customers often tolerate rough edges, probe whether the pain is superficial (UI friction) or structural (missing controls, brittle data flows, unreliable outputs). Structural pain scales into churn and discounting as cohorts grow.
When cohorts are small, prioritize depth over breadth. Choose customers that represent the intended segment and the edge cases: the largest account, the most demanding buyer, the fastest implementation, and the slowest. Ask for artifacts when possible: onboarding checklists, integration mappings, internal rollout communications, and renewal notes. Artifacts often reveal true time-to-value and the hidden work required to reach it.
Use commercial behavior as a proxy for value. If renewals are limited, look for leading indicators: conversion from pilot to paid, willingness to standardize on the tool, reduction of parallel systems, and expansion intent tied to specific workflows. If customers keep “shadow processes” (spreadsheets, manual reconciliations) because outputs cannot be trusted, flag it as a product maturity risk that will later become a core retention mechanism.
Product layer: In early-stage diligence, the demo is not a tour; it is a test. Run it around two or three real workflows with realistic roles and data. Include the admin surface: permissions, auditability, integrations, and error handling. Early products often look strong in the happy path and weak in governance paths. That may be acceptable in SMB, but it becomes binding as the segment moves upmarket.
Hands-on testing, even brief, is high yield. Focus on what creates support burden and slows scaling: confusing setup, brittle imports, unclear failure messages, and reliance on vendor intervention for routine tasks. Many early-stage teams hide support loads because founders personally rescue customers. Diligence should make that load visible and estimate how it scales as headcount and customer count grow.
Engineering layer: When telemetry is weak, engineering artifacts carry more weight. A guided repo walkthrough and CI/CD review can reveal whether the team is building toward operability: tests, feature flags, logging conventions, safe releases, and basic access discipline. You are not looking for perfection; you are looking for direction of travel. A team that is adding instrumentation intentionally and enforcing minimum gates is a different risk profile than a team that ships by bypassing controls.
Use evidence substitution deliberately. If there is no formal incident log, ask for incident Slack channels, on-call notes, or status page history. If telemetry is absent, ask for usage proxies: active accounts, records created, jobs processed, integrations enabled, or API call counts. If churn analysis is absent, ask for cancellation emails and renewal notes. Imperfect substitutes still anchor conclusions in observable reality.
To keep early-stage evidence collection crisp, request a small “proof pack” that is easy for the company to assemble but hard to fake:
- Implementation trail: one end-to-end onboarding plan for a recent customer, including integration mapping and acceptance criteria.
- Customer outcomes: two examples of measurable before/after impact (even if the measurement is customer-provided).
- Operational trace: one recent production issue with timeline, mitigation steps, and what was changed to prevent recurrence.
- Delivery proof: one meaningful PR and the associated CI checks and rollout approach.
Be explicit about what you cannot underwrite yet, and convert it into a plan. An early-stage company may not be able to prove durable retention, true cost-to-serve at scale, or a complete security posture. Treat these as uncertainties with a first-100-day uplift plan: instrument core workflows, define metric definitions, establish basic incident discipline, and implement minimum security controls for the target segment.
In particular, insist on a “telemetry bootstrap” plan if the thesis depends on data-driven growth or enterprise readiness. The minimum is not a sophisticated analytics program; it is a handful of events and health signals tied to core workflows, plus ownership for dashboards and definitions. Without that foundation, every post-close decision becomes a debate, and value creation initiatives become harder to size and verify.
17.2 Services-heavy Software: Separating Product Value from Delivery Heroics
Services-heavy software businesses are common in vertical markets and complex workflows where customer data, integrations, and change management drive implementation work. They can be attractive because services accelerate adoption and create stickiness. They can also be dangerous because services can mask product gaps, inflate cost-to-serve, and create an illusion of scalability that breaks when the company tries to grow.
The diligence job is to separate what the product does from what people do. When a customer says the product “works,” determine whether it works out of the box or whether a services team wrote scripts, cleaned data, built bespoke reports, and runs ongoing operations. Those heroics create hidden liabilities: margin pressure, key-person risk, and a roadmap filled with customer-specific work.
Start with a clear decomposition of revenue and effort. Services-heavy companies often have subscription plus implementation, managed services, and custom development. Underwrite not only revenue mix, but effort mix: hours to onboard and sustain a customer, engineering time pulled into services, and how effort varies by segment. If the company cannot quantify, use proxies: staffing levels, utilization, backlog, and how often senior engineers are required on customer projects.
First principle: treat implementation work as a product signal. Recurring steps across customers are productization candidates. One-off steps are either true customization (acceptable at high price points) or symptoms of product immaturity. The difference is revealed by pattern frequency and by whether the company learns—does it reduce effort over time or repeat the same work indefinitely?
Build a services-to-product map. Identify the top recurring services activities and, for each, answer: how often it occurs, why it occurs (product gap versus customer variability), and what would reduce it (product capability, tooling, template, or scoping change). This converts services reality into an investable backlog and prevents the common mistake of assuming margin expansion without productization.
Implementation and time-to-value are the core measures. Ask for the distribution, not the average. A handful of smooth projects can hide a long tail of painful implementations that consume disproportionate effort and create churn risk. Diagnose what drives the tail: integrations, data quality, permissions, reporting definitions, or customer readiness. Some drivers are product work; others require better qualification, scoping, and pricing discipline.
Test whether the company has a repeatable implementation playbook. A real playbook includes steps, templates, and acceptance criteria that can be executed by trained staff. Ask to see actual artifacts: onboarding checklists, data mapping templates, integration runbooks, and standard configurations by segment. Repeatable artifacts reduce key-person risk and indicate services can scale without linearly scaling headcount.
Then test the configuration versus customization boundary. Healthy products are configurable within supported boundaries. Unhealthy ones drift into customization: custom code per customer, bespoke data models, or unique reporting logic. Customization can be valid, but it must be priced, tracked, and isolated so it does not contaminate the core platform. Ask how customizations are tracked, how upgrades are handled, and whether custom work blocks releases. If upgrades are routinely delayed by a handful of accounts, your platform roadmap is hostage to those customers.
Evaluate ongoing services, not just onboarding. Managed services can improve retention, but they also turn the business into an operations provider. Ask what fraction of customers require recurring intervention and whether those interventions are repeatable and productizable. If a large share of “support” is routed through services teams, require an end-to-end view of customer issues (tickets, implementation issues, ad hoc requests) so product gaps do not remain hidden.
Quantify “services drag” with a few simple ratios. Compare services headcount to active customers, compare recurring services hours to subscription ARR, and compare escalations to engineering capacity. These ratios do not need to be perfect; they tell you whether the model scales linearly with headcount or whether productization is already bending the curve.
To validate what is truly a product, run a “clean-room implementation” thought experiment in the room. Ask: if you had to onboard a new customer next week without custom code and with minimal senior engineering involvement, what would break first? The answers usually reveal where heroics are hiding and which product capabilities, templates, or guardrails would have the highest ROI.
Request a small evidence set that makes the model legible:
- SOW sample: three recent statements of work, including what was promised and what actually shipped.
- Services utilization: utilization and backlog by role, plus the top drivers of overruns.
- Customization inventory: a list of customer-specific code, rules, or report logic and how upgrades are handled.
- Escalation flow: how often services issues require engineering and why.
Close by stating what kind of business this is today and what it can become. Some companies are defensible because they have the best product; others because they have the best delivery capability in a complex domain. Both can be viable. The underwriting question is what must be invested to scale the moat. If delivery is the moat, invest in playbooks, training, and tooling. If the product is the moat, protect engineering capacity from one-off work and fund productization that reduces delivery dependence over time.
17.3 Open-source and License Risk: Practical Diligence Steps
Open-source is foundational to modern software. The diligence risk is unmanaged obligations: licenses that impose disclosure or distribution requirements, missing attribution, unclear provenance of copied code, and an absence of processes that prevent future exposure. These risks often surface late—during enterprise procurement, during an acquisition, or after a security incident—when remediation is expensive and time is short.
Open-source diligence should be practical. You are not producing legal advice; you are underwriting whether the company has a manageable license posture and whether any specific exposures could constrain commercialization or trigger costly refactors.
Start with the distribution model because it changes the obligation surface. Determine whether the company is pure SaaS, ships on-prem, distributes agents/SDKs, or embeds components in customer environments. Also clarify whether the company publishes open-source projects and how those relate to the commercial product.
Then build an inventory. The gold standard is an SBOM: a software bill of materials with dependency names, versions, and licenses. Many companies will not have a complete SBOM; in that case, request dependency scanning outputs and confirm coverage of production runtime and any distributed components. If no scanning exists, treat inventory creation as a priority initiative because you cannot manage what you cannot enumerate.
Prioritize the “top risk” subset rather than attempting a manual review of everything. Focus on dependencies in the production runtime, libraries shipped to customers, and components known to have restrictive obligations. Also prioritize critical components that would be expensive to replace if exposure is discovered.
Review license posture at a business level. The diligence goal is to identify whether the product includes strong or network copyleft components in ways that could force source disclosure or constrain the model. Then assess process maturity: policy, engineer guidance, approvals for high-risk licenses, and a repeatable way to generate notices and attributions. The absence of process is often the most important risk because exposure can grow silently as the team scales.
Also examine provenance. Ask how the company ensures code added by employees and contractors is owned and properly licensed, whether external contributions are accepted, and how third-party code is introduced. Provenance risk is common in fast-moving teams that copy snippets, vendor libraries, or legacy codebases without tracking origin.
Include vulnerability posture alongside licensing. Ask how critical dependency vulnerabilities are tracked and patched, whether versions are pinned, and whether there is an upgrade cadence. Procurement and auditors increasingly treat vulnerability response as part of trust readiness.
Common signals that warrant deeper review include: a refusal or inability to produce scanning outputs, customer-delivered code mixed into the product, or distributed agents that embed libraries without clear notices. These are not automatically fatal, but they can change remediation cost and sales friction.
Use a practical checklist:
- Inventory: SBOM or scanning outputs exist and cover production and distributed components.
- High-risk licenses: identified, reviewed, and governed through approvals.
- Attribution: notices and acknowledgments are generated and shipped where required.
- Provenance: IP assignment and contribution controls are clear for employees and contractors.
- Upgrade cadence: critical vulnerabilities are remediated on a defined timeline.
When gaps exist, translate them into a manageable uplift: implement scanning, classify licenses, establish approvals, automate notices, and formalize upgrade ownership. Escalate only when a specific high-risk usage conflicts with the business model and replacement cost or deal terms may change.
17.4 Highly Regulated Verticals: Documentation, Controls, Audit Readiness
Regulated verticals change the diligence equation because buyers evaluate trust evidence, not only features. The company’s ability to win and retain depends on documentation, control operation, and auditability. In these markets, compliance is not a binder; it is a product capability and an operating discipline.
Begin with scope. “Regulated” can mean very different obligations depending on data types, geography, and customer requirements. Underwrite the specific obligations that matter to the target customer set and the deal thesis, and treat them as market access requirements with distinct evidence needs.
Separate external requirements: what customers and regulators require, from internal capability: what the company can operate consistently. Missing evidence is often equivalent to missing controls because procurement and audits depend on proof.
Assess the audit surface across technical and operational controls. Technical controls include access control, encryption, logging, vulnerability management, change management, backups, and incident response. Operational controls include training, vendor management, risk assessments, and documented procedures. Identify which controls operate reliably and which are aspirational.
Documentation: Evaluate documentation as an operating artifact. The best documents answer real questions: how changes are approved, how incidents are handled, how access is reviewed, how data is deleted, and how vendors are assessed. A fast assessment focuses on five items: security policies, incident response plan, change management procedure, access review procedure, and retention/deletion policy. Then request evidence that they are followed: a recent access review, a recent postmortem, a recent change record, and a recent vendor review. Evidence beats prose.
Control ownership: Controls must be sustainable. Confirm who owns each control domain and whether ownership is distributed across system owners, not concentrated in a single compliance person. If ownership is unclear, the program will fail during growth or during an incident.
Watch for control seams that create recurring risk: support access to production data, exception handling for urgent customer requests, and bespoke customer controls that cannot be replicated. Regulated customers often request bespoke terms; underwrite whether the company can meet them without creating a one-off operating model that destroys margin.
Regulated selling also requires an “evidence pack” that can be reused repeatedly: standard questionnaire answers tied to control evidence, a subprocessor list, data flow summaries, and clear descriptions of support access and incident communication. When this pack does not exist, sales cycles lengthen and deals become dependent on a few individuals who can answer questions from memory.
Audit readiness: Audit readiness means the company can pass repeatedly while shipping changes. Ask whether evidence is collected continuously, whether control failures are tracked and remediated, and whether there is an internal review cadence. If evidence is collected in a panic before audits, the control system is not embedded and will remain a recurring distraction.
Also account for timeline reality. Many attestations require an operating period, which cannot be compressed by adding engineers. If the thesis relies on regulated expansion, align the model to gating milestones: implement controls early, start evidence capture, and use interim milestones to reduce sales friction while the observation window runs.
Regulated readiness includes product capabilities customers expect: audit logs, role-based access controls, configurable retention, data export and deletion tools, and sometimes residency. In many verticals, these are core buying criteria. Underwrite whether they exist, are usable by customer admins, and are supported by documentation and evidence. Missing capabilities should be treated as revenue blockers and prioritized in the value creation plan.
At a minimum, regulated buyers expect a small set of operating controls to be real and provable:
- Privileged access: MFA, least privilege, and logged administrative actions.
- Change control: reviewed changes with rollback discipline and environment separation.
- Vulnerability response: scanning plus a defined remediation cadence for critical findings.
- Incident response: practiced response and customer communication procedures.
- Data handling: clear retention/deletion behavior aligned to contracts.
Close with a pragmatic path: scope and map data flows, implement minimum controls, embed evidence collection, and then pursue the needed attestations. Prioritize the controls that reduce acute downside and unlock pipeline first—privileged access, logging, incident response, and change management—then layer on documentation rigor, vendor management, and certification work. Throughout, keep the linkage to commercial impact explicit: which deals are gated by which evidence milestones.
Special situations require a mindset shift. You are still underwriting risk, value creation, and readiness, but you are doing it with different evidence and different bars. When standard playbooks fail, replace them with structured skepticism, alternate proofs, explicit confidence statements, and a funded plan to close the gaps that matter.
