Technical Due Diligence for an AI-Powered LegalTech SaaS Acquisition

Executive overview

A pre-acquisition technical assessment of an AI-powered LegalTech SaaS platform serving UK law firms, covering whether the application can be rebuilt and deployed from the repository alone, its architecture and customer-data flows, security controls, software dependencies and licences, the third-party LLM layer, the measured cost of generating a report, backups and recovery, and a prioritized remediation plan split across pre-close, first thirty days and first ninety days.

Business challenge

A prospective buyer was in late-stage discussions to acquire a two-year-old, founder-built B2B LegalTech platform. Commercial diligence had gone well: the revenue was real, the customers were named UK law firms, and the product did something they valued — a solicitor uploads a PDF, the platform extracts and analyses it with a third-party large language model, and a structured Microsoft Word and Excel report comes back. What the buyer had no independent view of was the thing they would actually own on completion, which is a source-code repository, a DigitalOcean account, a set of API keys and a body of knowledge that lived in two founders' heads. Small founder-built SaaS platforms routinely deliver excellent customer value while carrying technical risk that commercial diligence never touches: undocumented architecture and data flows, critical knowledge concentrated in the people who are about to leave, outdated or vulnerable dependencies, restrictive open-source licences in a product being sold, weak authentication or tenant separation, secrets committed to source control or baked into deployment files, backups that have never been restored, customer documents flowing to an external AI provider under terms nobody has read, and unit economics that move with someone else's price list. For a product whose input is a law firm's client documents, the confidentiality, retention and third-party-processing questions are not general good practice — they are the questions the firms themselves would ask if they knew to. The buyer wanted to know, before signing, whether a new technical owner could safely operate this platform after the founders transitioned away, and what it would cost to put right whatever was wrong.

Environment and constraints

• Two-year-old founder-built B2B SaaS platform serving UK law firms, in market for approximately two years at the time of the review.
• Primary workflow: customer-supplied PDF in, AI-assisted analysis, Microsoft Word and Excel report out.
• Hosted on DigitalOcean, with a third-party large language model API and third-party document-processing services in the path.
• Fieldwork ran in May 2026 inside a fixed ten-to-twelve-hour assessment window, agreed deliberately: the buyer needed a decision-grade view before an exclusivity deadline, not an exhaustive audit delivered after it.
• Conducted under a non-disclosure agreement covering the target company, its customers and its source code. No client, customer, product, provider or repository is named here, and no finding, severity count, cost figure or recommendation from the engagement is reproduced.
• Read-only access to source code, configuration and infrastructure. No penetration testing, no active exploitation and no load testing were in scope, and no change was made to any production system.
• The assessment was point-in-time, based on the repository state and infrastructure configuration as provided during the window.
• This was a technical control assessment. It did not constitute legal, regulatory or financial advice, and open-source licence questions were escalated for specialist legal interpretation rather than resolved.

Objectives and success measures

• Establish whether the application can be built, deployed and operated from the repository and infrastructure accounts alone, without undocumented founder knowledge.
• Determine whether the architecture is understandable, supportable and reasonably secure for a new technical owner inheriting it.
• Identify every external service that receives, stores or processes customer information, and state it in a form the buyer can hand to a law-firm customer after completion.
• Identify the technical risks capable of affecting acquisition value, the warranties and disclosures, transition planning, or the future operating cost base.
• Establish what a single generated report actually costs to produce, and whether the platform's pricing survives volume growth and a change in the model provider's price list.
• Separate what must be corrected, funded or contractually addressed before closing from what can safely be absorbed into a post-close remediation plan.
• Give the buyer an evidence-backed recommendation they can act on, rather than a list of technical observations they would have to interpret themselves.

Role and responsibilities

Independent technical due-diligence assessor, engaged by the prospective buyer and reporting to them. Responsible for scoping the review against the acquisition decision rather than against a generic checklist, running the build and deployment reproduction, mapping the architecture and customer-data flows, assessing the security controls, auditing dependencies and their licences, reviewing the AI and model layer as both a technical component and a commercial dependency, building the cost-per-report model, writing and rating the risk register, and producing the executive recommendation and remediation plan. The engagement was conducted under a non-disclosure agreement covering the target, its customers and its source code. This was a technical control assessment. It did not constitute legal, regulatory, tax or financial advice, and the open-source licence findings were escalated for specialist legal interpretation rather than opined on.

Architecture and design approach

• The review was designed backwards from the decision rather than forwards from a checklist. A due-diligence report that inventories everything and prioritizes nothing arrives after the buyer has already had to decide. So the scope was fixed to five questions a buyer can act on — can the application be built and deployed from the repository alone; is the architecture understandable, supportable and reasonably secure; which external services receive, store or process customer information; what technical risk could affect acquisition value or future operating cost; and what has to be corrected before signing rather than after — and every hour spent had to serve one of them.
• Build and deployment reproduction came first, because it is the cheapest test of the most expensive risk. The objective was not to see the application compile. It was to establish whether a new technical owner, holding only the repository and the infrastructure accounts, could stand the platform up, understand what it was doing, and troubleshoot it at two in the morning without calling a founder who no longer works there. That meant working through repository structure, build and runtime prerequisites, environment variables and configuration management, deployment procedure, infrastructure dependencies, database initialization and migrations, background workers, scheduled jobs and queues, error handling and logging, the differences between development, staging and production, and the completeness of whatever operational documentation existed. Anything that only worked because a founder was in the room was recorded as a knowledge-transfer dependency rather than as a passing test.
• Architecture was documented as a data flow, end to end, from authentication through PDF upload, file validation and extraction, application processing, the LLM API request, response validation, Word and Excel generation, and secure download or storage. Mapping it as a flow rather than as a component diagram is what surfaces the questions that matter to a buyer of a document-processing product: where the customer's file rests, for how long, in what form, under whose control, and which boundary it crosses next. The map covered frontend and backend components, application services and APIs, databases and object storage, the DigitalOcean footprint, document-processing libraries, authentication and identity, the third-party LLM provider, email, analytics, logging and monitoring platforms, backup locations, administrative interfaces and the trust boundaries between all of them.
• Every external service that could receive customer content, metadata, credentials, prompts, model responses or operational logs was enumerated separately and deliberately, because that list is the subprocessor list whether or not anyone has ever written it down. For a platform serving law firms it is also the list the buyer will have to be able to produce on request after completion, and assembling it during diligence is considerably cheaper than assembling it during a customer's security review.
• The security review was scoped to the risks that actually move a small SaaS acquisition rather than to a comprehensive control framework, and organized into four areas. Identity and access covered authentication, password storage and reset, session and token handling, multi-factor support, role-based access control, privileged and administrative access, account deactivation, tenant separation and protection against one customer reaching another's documents. Secrets and configuration covered whether API keys live outside the source code, whether they appear anywhere in repository history, whether production and development credentials are separated, how access keys are scoped, whether anything can be rotated, and how sensitive configuration is protected during deployment. Data protection covered encryption in transit and at rest, uploaded-document storage, temporary-file handling, retention and deletion, database access control, log sanitization, backup protection, third-party processing, and the generation and delivery of output documents. Resilience covered backup frequency and coverage, retention periods, restore procedures, evidence that a restore has ever actually been performed, infrastructure recovery requirements, monitoring and alerting, single points of failure, and operational dependency on the founders.
• Dependencies were audited both ways — for security and for licence. Direct and transitive packages were assessed for known vulnerabilities, unsupported or abandoned libraries, unnecessary inclusions, version conflicts, high-risk document-processing components, pinning and lock-file quality, provenance, and whether any automated update or vulnerability-monitoring capability existed at all. The licence audit ran alongside it, looking for terms that could create distribution, disclosure, attribution or commercial-use consequences for a product being sold. Document-processing libraries earned particular attention on both counts: they are the components most likely to be parsing untrusted input from a customer, and they are disproportionately represented among packages whose licensing is stricter than a founder assumed when they installed it in a hurry.
• The AI layer was reviewed as two things at once — a technical component with failure modes, and a commercial dependency on a third party with its own price list and its own terms. Technically: model and provider, prompt construction and version control, system instructions and processing stages, document chunking and context management, output validation, retry and timeout behaviour, rate limits, handling of malformed model responses, exposure to prompt injection through customer-supplied document content, and consistency of output across repeated runs. Commercially: token consumption, provider retention and training settings, what leaves the platform in a prompt, model portability and the depth of any lock-in, fallback behaviour during a provider outage, and what a provider price change or model deprecation would do to the product.
• The position taken throughout is that in a legal-document workflow, a model response is an input to be validated rather than an output to be trusted. The application around the model has to check that the response is structurally what was expected, behave sensibly when it is not, handle uncertainty rather than rendering it as confident prose in a Word document going to a solicitor, preserve traceability back to the source document where the workflow calls for it, and guarantee that one customer's content cannot surface in another's report. Those are properties of the application, not of the model, and they are assessable.
• A cost model was built for a single generated report, because a per-report gross margin is the number that determines whether the pricing survives growth. The build decomposed cost into input-token cost, output-token cost, document-processing cost, storage cost, compute cost and retry overhead, and drove it from the platform's actual shape rather than from a vendor pricing page: average PDF size and page count, tokens generated during extraction and prompting, the number of model calls a single report actually makes, model selection, the rate of failed calls and retries, Word and Excel generation overhead, temporary and permanent storage, DigitalOcean compute consumption and supporting third-party service charges. The model was built so the buyer could re-run it against their own assumptions rather than accept a single figure.
• Every observation was recorded in a structured risk register with a fixed set of fields — identifier, area, finding, evidence, likelihood, impact, severity, recommendation, estimated effort, priority, suggested owner and acquisition relevance — and nothing entered the register without evidence attached, meaning code, configuration, a test result or a document. The acquisition-relevance field is the one that distinguishes this from a security assessment: it records whether an item bears on valuation, on the warranties and disclosures, on transition planning, or on the conditions to closing, which is the language the buyer's own advisers were working in.

Security and governance considerations

• Confidentiality was treated as the defining property of the product rather than as a control domain within it. The platform's input is a law firm's client material, so the review followed that material rather than the perimeter: where an uploaded document rests, in what form, for how long, under whose administrative control, and which boundary it crosses next — including the temporary files and intermediate extractions that a document-processing pipeline creates and that retention policies routinely fail to cover.
• Tenant separation was assessed as a question about whether one customer can reach another's documents, reports or job records, rather than as a question about whether the application has a tenant column. For a platform whose customers are firms that compete with one another, that boundary is the one a customer's own risk function will test first.
• Secrets were assessed in three places rather than one: in the working tree, in repository history, and in whatever deployment mechanism actually injects them into the running application. A credential removed from the current code but still present in history is still a disclosed credential, and it is disclosed to whoever receives the repository at completion.
• The third-party AI provider was treated as a subprocessor of client-confidential material, with the questions that follow from that framing: what leaves the platform in a prompt, whether the provider's retention and training settings are configured as the product's own representations imply, what contractual position exists, and whether the buyer could describe that position accurately to a law-firm customer after completion.
• Prompt injection through customer-supplied document content was treated as a design constraint rather than a pending fix. A PDF arriving from outside the organization is untrusted input that reaches a model, and the safety case has to rest on what the application does with the response — structural validation, bounded actions, no cross-tenant reach — rather than on the model declining to be misled.
• Recovery was assessed on evidence of restoration rather than evidence of backup. A backup job with a green status and no record of any restore having been performed is an assumption, and it is one the buyer would inherit unexamined.
• Founder dependency was recorded as an operational risk with named items, not as a general observation. The relevant question for an acquirer is not whether documentation exists; it is which specific operational tasks currently have exactly one person who can perform them, and what each of those costs to transfer.
• The report kept the four activities apart throughout: the platform's design supplies mechanisms, its operators run controls, evidence demonstrates them, and an accountable person accepts residual risk. No conformity claim with any regime was made anywhere in the deliverables, and no finding was inflated by presenting good practice as an obligation.

Implementation and migration approach

• The window was sequenced so that the findings capable of stopping a transaction surfaced first. Build and deployment reproduction, secrets exposure and the customer-data flow map were run before the detailed control review, on the reasoning that a buyer who cannot deploy what they are buying, or who is about to inherit a disclosed production credential, needs to know that on day one of the review rather than in the final report.
• Nothing entered the risk register without evidence attached — a file and line, a configuration value, a command output, a test result or a document reference. Observations that could not be evidenced inside the window were recorded as open questions for the target's founders rather than promoted into findings, which keeps the register defensible when the seller's side reads it.
• Severity was rated for the buyer's position rather than in the abstract. The same technical weakness carries a different rating depending on whether it affects valuation, sits in the warranties, complicates transition, or is simply an item of post-close engineering work, and the register records that judgement explicitly instead of leaving the buyer to infer it.
• Remediation was estimated in engineering effort and mapped to one of four decision periods, because a recommendation without an effort estimate is not actionable during a negotiation. Pre-close items were the ones capable of affecting whether or on what terms the transaction should proceed at all; the thirty-day set was credential rotation, access tightening, critical patching, backup coverage, centralized logging and alerting, deployment documentation, retention settings and an incident-response contact path; the thirty-one-to-ninety-day set was the structural work — infrastructure as code, automated security testing, dependency-update automation, stronger tenant isolation, formal role-based access control, environment separation, LLM abstraction and fallback, cost and usage dashboards, disaster-recovery testing and secure release procedures.
• The executive summary terminated in one of four stated positions rather than in a summary of observations, because the buyer's question was a decision and a report that declines to answer it transfers the work back to them. The categories were fixed in advance: proceed; proceed with remediation; proceed with conditions to be resolved, funded or contractually addressed before closing; or pause where a risk could materially affect security, continuity, ownership or commercial viability.
• The engagement closed with a forty-five-minute findings and questions session, held after the buyer had read the report rather than instead of them reading it. That session is where a diligence report earns its value, because it is where the buyer's own commercial and legal advisers ask what a finding means for the terms they are drafting.
• A lightweight monthly advisory retainer was offered for the post-close period, covering production alerts and incidents, security patch advice, dependency monitoring, release and infrastructure change support, review of LLM usage and operating cost, maintenance of the architecture and operational documentation, support for vendor or contractor discussions, and tracking of the remediation actions. The reasoning is specific to this class of acquisition: a founder-built platform loses its entire engineering capability on completion day, and the alternative to continuity of some kind is an immediate full-time hire made under time pressure.

Key decisions and trade-offs

• Time-box the review and scope it to the decision. Ten to twelve hours cannot produce an exhaustive audit, and pretending otherwise would have produced a thinner version of everything rather than a usable version of the things that mattered. The window was fixed and the five questions were fixed with it, so what got cut was cut deliberately and named in the report as out of scope rather than quietly omitted.
• Reproduce the build before reviewing anything else. It is the single highest-information test available in a founder-built acquisition, because it tests documentation, architecture, configuration management and knowledge concentration simultaneously, and it fails loudly.
• Map data flows rather than components. A component diagram tells a buyer what they are acquiring. A data-flow map tells them what they are becoming responsible for, and for a product processing law-firm documents those are different documents with different consequences.
• Treat the AI provider as a subprocessor rather than as a library. Framing it as a dependency invites a technical answer about API stability. Framing it as a third party receiving client-confidential material invites the questions the target's own customers would ask, which is the standard the buyer will be held to after completion.
• Build the cost model from the platform's measured behaviour rather than from published pricing. The number that matters is what a report actually costs including the retries, the failed calls and the second model invocation nobody remembers, and that number is only visible from the application's own behaviour.
• Add an acquisition-relevance field to the risk register. Without it a due-diligence register is a security assessment with a different cover page. With it, each finding states whether it bears on valuation, warranties, transition or closing conditions, which is what makes the document usable by people who are not engineers.
• Escalate licence questions rather than answer them. Identifying a restrictive or incompatible licence in a product being sold is a technical task. Deciding what it means for the transaction is not, and a technical adviser who opines on it is creating a risk rather than reporting one.
• Report no active testing, and say so prominently. Read-only scope was the right choice for a live platform serving law firms during a live transaction, but it bounds what the assessment can claim, and a diligence report that does not state its own limits invites the buyer to over-read it.
• Answer the question with a category. Four named positions, chosen in advance, with the evidence behind the choice — because the alternative is a report that lists risks and leaves the buyer to decide how worried to be, which is the work they engaged someone else to do.

Results and outcomes

• A build and deployment validation result stating, from a standing start against the repository and the infrastructure accounts alone, what a new technical owner could reproduce, what required founder knowledge, and what was undocumented — recorded as named knowledge-transfer dependencies rather than as a single pass or fail.
• A high-level system architecture for a platform that had never had one written down, documented as the end-to-end path a customer document actually takes from upload to delivered report, with trust boundaries marked.
• A customer-data and third-party service map naming every external service that receives, stores or processes customer content, metadata, credentials, prompts, model responses or operational logs — which is the subprocessor position the buyer would own on completion and would have to be able to state to a law-firm customer on request.
• An external dependency inventory covering direct and transitive packages, with vulnerability status, support status, provenance and pinning quality recorded per component.
• A software licence position for the dependency set, with any term capable of creating distribution, disclosure, attribution or commercial-use consequences for the acquired product flagged and escalated for specialist legal interpretation rather than opined on.
• A security-control assessment across identity and access, secrets and configuration, data protection, and resilience and recovery, written against the platform's real design rather than against a framework it was never built to.
• An AI and model-layer review covering provider dependency, prompt and context handling, output validation, injection exposure through customer-supplied document content, retention and training settings, portability and outage behaviour.
• An estimated LLM cost per generated report, decomposed into input tokens, output tokens, document processing, storage, compute and retry overhead, and delivered as a model the buyer can re-run against their own volume and pricing assumptions rather than as a single figure.
• A prioritized technical risk register in which every entry carries evidence, a likelihood and impact rating, a severity, a recommendation, an estimated engineering effort and an explicit acquisition-relevance note covering valuation, warranties, transition or closing conditions.
• A remediation plan split into four decision periods — before close, first thirty days, thirty-one to ninety days, and backlog — so the buyer could separate what had to be resolved, funded or contractually addressed before signing from what could be absorbed into a post-close plan.
• An executive recommendation placing the platform into one of four categories — proceed, proceed with remediation, proceed with conditions, or pause — supported by the evidence behind it, followed by a forty-five-minute findings and questions session with the buyer.

Lessons learned

• The most valuable hour in a founder-built acquisition is the one spent trying to deploy the platform from scratch. It tests the documentation, the configuration management, the architecture and the concentration of knowledge at the same time, and it produces a result nobody can talk their way around.
• In a small SaaS acquisition the technical risks that move the transaction are rarely exotic. They are secrets in repository history, a backup that has never been restored, a tenant boundary that was never designed, a dependency whose licence nobody read, and a founder who is the only person who has ever deployed to production. All five are findable in a day.
• The subprocessor list is almost never written down at this size, and it is almost always longer than the founders believe. Assembling it during diligence costs a couple of hours; assembling it after completion, in response to a law firm's security questionnaire, costs considerably more and happens under time pressure with the founders gone.
• Cost per unit of output is a technical finding, not a commercial one. Token consumption, retry behaviour, model selection and chunking strategy are engineering decisions, and they set the gross margin. A platform can have healthy pricing and unhealthy unit economics at the same time, and only the code shows which.
• A model response arriving as a well-formed Word document is the most persuasive form an unvalidated output can take. The confidence of the artifact is a property of the document generator, not of the analysis, and in a legal workflow that gap is the risk worth naming.
• Rating severity without reference to the buyer's position makes a report harder to use, not more objective. The same weakness is a valuation item, a warranty item, a transition item or a backlog item depending on where it sits, and the assessor is better placed to make that call than the reader is.
• A due-diligence report that will not answer the question has failed, however thorough it is. The buyer is not commissioning an inventory of technical observations; they are commissioning a position they can act on, with the evidence attached so they can disagree with it.
• The risk that survives completion is continuity. On the day the founders leave, a platform like this loses its entire engineering capability at once, and every technical finding in the register gets harder to fix. Planning that transition is part of the diligence, not something that follows it.

Related technologies

• DigitalOcean
• Third-party large language model APIs
• PDF text extraction and document parsing libraries
• Microsoft Word and Excel document generation
• Object storage and managed database services
• Background job queues and scheduled workers
• Application authentication and session management
• Role-based access control and tenant isolation
• Secrets management and credential rotation
• Software composition analysis and dependency auditing
• Open-source licence review
• Vulnerability management
• Backup and restore validation
• Logging, monitoring and alerting
• Prompt engineering and prompt version control
• LLM output validation and structured response handling
• Prompt-injection threat modelling
• Token accounting and unit-cost modelling
• OWASP Top 10 for LLM Applications
• Technical due-diligence risk register and remediation planning

Related projects