Engagement: Post-Acquisition Tech Audit & IP Review  |  Sector: EdTech / Learning Platform  |  Duration: 22 Days

The Setup

An Asset Reconstruction Company (ARC) based in India, with a portfolio that included distressed technology assets across South and Southeast Asia, had acquired a stressed EdTech platform through a CIRP resolution. The platform was a B2B2C learning management system (LMS) that served coaching institutes, corporate training departments and government upskilling programmes. At its peak, it had over 200,000 active learners and partnerships with roughly 40 institutional clients across India, the UAE and Singapore.

The ARC had acquired the asset primarily for its technology and client relationships. The financial diligence had been thorough. The legal team had reviewed the resolution plan. But nobody had looked under the hood of the technology itself.

Three months post-acquisition, problems started surfacing. A former co-founder of the EdTech company, who had exited during a dispute two years before the insolvency, sent a legal notice claiming joint ownership of the platform’s core adaptive learning algorithm. Two institutional clients raised concerns about the platform’s data handling practices, citing contractual commitments that the previous management had made but never implemented. And the engineering team, reduced to four developers from an original team of sixteen, reported that they couldn’t confidently ship updates because large sections of the codebase were undocumented and untested.

The ARC’s portfolio manager called us. He was direct: “We bought what we thought was a working platform. Now I’m not sure we own all of it and I’m not sure what we own actually works.”

What We Found?

We deployed a four-person team for a 22-day engagement, a senior architect, an IP and open source compliance specialist, a security analyst and a technical project manager who coordinated with the ARC’s legal counsel throughout.

Finding 1: The IP Ownership Dispute Was Legitimate and More Complex Than Anyone Realised

The former co-founder’s claim wasn’t frivolous. Here’s what the technical and documentary evidence showed:

The adaptive learning algorithm, the most commercially valuable piece of the platform and the primary differentiator cited in client proposals, had been originally developed as part of the co-founder’s academic research at a university in Singapore. He had subsequently brought it into the company. But the IP assignment was incomplete.

There was a founders’ agreement, signed at incorporation. It included a broad IP assignment clause. However, the clause referenced only “work created after the date of this agreement.” The algorithm’s foundational code had been written before the agreement was signed. The co-founder had contributed refinements and extensions after incorporation, but the core IP, the mathematical models, the initial training data set, the base architecture, predated the founders’ agreement.

To make matters worse, the university where the research was conducted had its own IP policy. Under Singapore’s standard university IP frameworks, the institution could potentially claim rights to research-derived IP if it was developed using university resources, unless a formal waiver or licence had been executed. We found no evidence that such a waiver existed.

So the ARC wasn’t dealing with a two-party dispute. It was potentially a three-party dispute: the company, the co-founder and the university. Over the single most valuable piece of technology in the asset.

🚨 Risk QuantificationIf the co-founder’s claim was upheld: The ARC would either need to licence the algorithm from the co-founder, negotiate a buyout, or replace the core technology entirely, a 12–18 month engineering effort. If the university asserted rights: The situation could escalate further, potentially requiring a three-way licensing agreement or limiting the ARC’s ability to commercialise the platform in Singapore and other markets where the university had partnerships.

Finding 2: Open Source Contamination in the Content Delivery Engine

The platform’s content delivery module, which handled video streaming, document rendering and interactive assessments, incorporated a media processing library licensed under the AGPL (Affero General Public Licence). This is the most restrictive copyleft licence in common use: it requires that any application that interacts with AGPL-licensed code over a network must make its entire source code publicly available.

The library had been integrated directly into the platform’s backend, not as an isolated microservice, but embedded within the monolithic application. Under the AGPL’s terms, this meant the entire backend codebase was technically required to be open-sourced if the platform was made available to users over the internet, which, as a cloud-hosted LMS, it obviously was.

Nobody at the company had flagged this. There was no Software Bill of Materials. No licence compliance process. The library had been pulled in by a developer who left eighteen months ago and no one had reviewed its licence terms since.

🚨 Risk Quantification Remediation options: Either replace the AGPL library with a permissively licensed alternative (estimated 6–8 weeks of engineering) or restructure the architecture to isolate the library as a separate service (estimated 10–12 weeks). Both options required the already-stretched four-person engineering team to halt other work.

Finding 3: Client Data Handling Commitments That Were Never Implemented

Two of the platform’s largest institutional clients, a UAE-based corporate training provider and an Indian government skills programme, had contractual clauses requiring data isolation (dedicated database schemas for each client’s learner data), data residency within specific geographies and annual security audits conducted by an independent third party.

None of these had been implemented. All client data sat in a single, shared database with no logical separation. The UAE client’s learner data was being stored and processed in an Indian cloud region, which may have been acceptable for the Indian government programme, but potentially violated the UAE client’s data residency requirements. And the annual security audits? They had never been conducted. Not once.

This wasn’t just a technical gap. It was a contractual breach that both clients could use to terminate their agreements. Given that these two clients represented roughly 60% of the platform’s recurring revenue, losing them would have made the asset commercially unviable.

🚨 Risk Quantification Revenue at risk: Approximately 60% of recurring revenue if either or both clients exercised termination rights due to unimplemented contractual commitments. Remediation cost: Data isolation and multi-tenancy implementation estimated at 12–16 weeks of engineering work. First independent security audit: ₹15–25 lakhs, plus remediation costs for whatever the audit uncovered.

What We Recommended and What the ARC Did?

We presented our findings to the ARC’s portfolio manager and legal counsel in a structured RCOI-mapped risk register, with each finding linked to a specific financial impact and remediation pathway:

Risk	Severity	Recommended Action	Outcome
IP ownership dispute (co-founder + potential university claim)	Critical	Engage IP counsel to negotiate a structured IP buyout or licence agreement with the co-founder before any further commercialisation. Simultaneously, investigate the university’s IP policy and determine if a waiver exists.	ARC’s legal team opened direct negotiations with the co-founder. Dextra provided the technical evidence mapping showing which portions of the algorithm predated the founders’ agreement versus which were developed after.
AGPL contamination in content delivery module	High	Replace the AGPL library with a permissively licensed alternative as the first engineering priority. Implement a Software Bill of Materials (SBOM) process to prevent future licence compliance gaps.	Engineering team began library replacement. Dextra provided a shortlist of MIT/Apache-licensed alternatives that met the functional requirements.
Unimplemented client data handling commitments	High	Prioritise data isolation and multi-tenancy for the two at-risk clients. Proactively disclose the gap to both clients and present a time-bound remediation plan before they discovered it themselves.	ARC chose proactive disclosure. Both clients agreed to a 120-day remediation window rather than termination, after the ARC presented a credible technical plan.

The Renegotiation

The most consequential outcome of our engagement was what happened with the resolution professional.

The IP ownership dispute had not been disclosed in the information memorandum. The ARC’s legal counsel, armed with Dextra’s technical evidence and risk quantification, went back to the resolution professional and argued that the asset had been materially misrepresented. The IP that was described as “fully owned” was, in fact, subject to a legitimate third-party claim, one that could significantly diminish the asset’s commercial value.

This gave the ARC leverage to renegotiate the terms of the acquisition. The specific terms are confidential, but the renegotiation resulted in a material adjustment that accounted for the IP risk and the cost of the remediation work required to bring the platform to a defensible, operational state.

Impact Summary Three-party IP dispute identified and mapped (company, co-founder, university) with technical evidence showing exactly which code was in dispute AGPL licence contamination discovered and remediation started before any enforcement action could be triggered 60% of recurring revenue protected through proactive disclosure and a credible technical remediation plan for at-risk clients Acquisition terms renegotiated with the resolution professional based on material misrepresentation of IP ownership status SBOM process and licence compliance framework implemented to prevent future open source governance gaps

Also Explore:

• Is the IP Actually Theirs? The IP Ownership Audit Every Acquirer Must Run on a Stressed Tech Asset
• 5 Red Flags in a Distressed Tech Company’s Codebase That Can Kill Your ROI
• Technical Due Diligence in NCLT Proceedings: What Resolution Applicants Are Missing