Kevin Jun Lin, Corporate Lawyer

Preface: Research has found that, of 17 software companies invested in over the past five years, 4 have essentially “died,” and another 3 have seen their product direction become unrecognizable compared with the business plan at the time of investment. In-depth study revealed a common trait — the investment agreements of these companies almost all contained only standard financial terms (liquidation preference, anti-dilution, redemption rights, etc.), yet hardly touched upon the core value carriers of a software company: code quality, technology roadmap, team capability, and data security.

This lesson gave rise to a set of five special rights clauses for software-industry investors — these clauses are not written into the SPA (Share Subscription Agreement) or the SHA (Shareholders’ Agreement); investors are essentially using industrial-age legal tools to participate in a digital-age investment game.

First Right: Code Review Right

Why Is the Code Review Right Needed?

Financial investors are used to looking at the books — the balance sheet, income statement, and cash flow statement. But a software company’s core assets are not in those three statements. A SaaS company showing a book loss of RMB 5 million may be valued at RMB 500 million because it has 300 highly sticky enterprise customers, or it may have an actual value close to zero because its technology architecture has decayed to the point of being unable to scale. The two are barely distinguishable on the financial statements.

The code review right is the legal key for investors to open this “black box.” It empowers the investor, under specified conditions, to engage an independent technical team to review the company’s core code base.

Key Points of Clause Design

• Triggering Conditions: It is recommended to provide for periodic review (once every 6 or 12 months) + review upon major events (CTO departure, major product failure, security incident, etc.). Avoid ad hoc review — on the one hand, the founding team will resist the resulting work disruption; on the other hand, a court may find the clause overly harsh and thereby restrictive of the company’s normal operational autonomy.
• Scope of Review: Includes code quality (test coverage, technical debt, architectural soundness), security (dependency vulnerability scanning, handling of sensitive data), and scalability (performance benchmark results), among others. However, the implementation details of algorithms that constitute the company’s core trade secrets should be explicitly excluded — unless a specific triggering event occurs.
• Reviewing Party: The review is conducted by an independent third-party technical team designated by the investor; such team must sign a confidentiality agreement with the company and must not provide services to the investor’s or the company’s competitors.
• Cost Allocation: It is usually agreed that the investor bears the cost before the investment closing and the company bears it after closing (a single review generally costs between RMB 30,000 and 100,000).
  

Legal Boundaries

Statutory Link: The legal basis of the code review right lies in the right of inspection granted to shareholders by Article 57 of the newly revised Company Law — a shareholder has the right to consult and copy the articles of association, the register of shareholders, the minutes of shareholders’ meetings, the resolutions of the board of directors, the resolutions of the board of supervisors, and the financial and accounting reports, as well as to inspect the company’s accounting books and accounting vouchers. But for source code, a non-traditional form of company document, existing law lacks clear provisions, so it must be created through contractual agreement. This is also why the code review right needs to be specifically written into the investment agreement rather than relying on the law’s default protection.

Second Right: Product Roadmap Approval Right

The “Directional Risk” of Software Investment

The direction of capacity expansion in traditional manufacturing is relatively clear — with money, you build production lines, buy equipment, and hire workers. But what a software company does after receiving financing is a highly non-standardized decision. Build more functional modules? Rewrite the underlying architecture to support greater scale? Develop customized versions for vertical industries? Or expand into a platform product? Each choice corresponds to a completely different path of resource investment and return.

A more dangerous situation is that a founder may channel substantial resources into directions unrelated to business goals out of technical preference or personal interest. A typical scenario: the founder-CTO is obsessed with rewriting the entire code base in the latest programming language, devoting half a year and 60% of R&D resources to it, while the investor’s money was supposed to be used to expand the sales team and customer success function.

Key Points of Clause Design

• Scope of Approval: It is inadvisable to require investor approval for all product decisions — that would hollow out management’s operational autonomy. It is recommended to limit it to major matters such as “significant adjustments to the annual product roadmap,” “launch of a new business line,” “change of core technology stack (e.g., replacement of programming language or architecture pattern),” and “deviation of the annual R&D budget exceeding XX%.”
• Standard of Approval: The clause should state that the investor may not reject approval “without reason.” It is recommended to provide that a rejection of approval must be based on a “reasonable commercial judgment” and be supported by a written rationale. This is not only to avoid deadlock but also to ensure the clause withstands judicial review as “not constituting an abuse of rights.”
• Mechanism Design: A “deemed approval” clause may be set — if the investor does not raise a written objection within 30 days after receiving the product roadmap adjustment plan, it is deemed approved. This avoids business stagnation caused by the investor’s slow internal decision-making process.
  

Third Right: Technical Executive Appointment Right

CTO Departure — A “Heart Attack” for a Software Company

At any software company, the departure of the CTO (or technical VP, or chief architect) is an earthquake severe enough to be fatal. Unlike a sales VP or marketing VP, the departure of a CTO means not only the loss of a manager but also the loss of the “living documentation” of the entire product architecture — the key design decisions and tacit knowledge that are written nowhere in any design document.

The technical executive appointment right gives the investor a veto right or nomination right over candidates for the company’s core technical positions. This is not to interfere with day-to-day management, but to ensure “the right person is not chosen wrongly” at critical moments.

Key Points of Clause Design

• Coverage: Generally limited to three positions — CTO, technical VP, and chief architect. It should not be extended to all technical management positions.
• Type of Right: It is recommended to adopt a “veto right” rather than a “nomination right” — let the founding team find and recommend candidates, with the investor retaining only the veto right. This accords with the basic principle under the newly revised Company Law of balancing shareholder rights with the company’s operational autonomy.
• Succession Mechanism: Require core technical personnel to sign a “technology handover commitment” upon joining — the handover period shall be no less than 3 months, and all technical documentation must be updated and archived before departure.
• Transparency Requirement: Require the company to report to the investor each quarter the personnel stability metrics of the core technical team (voluntary turnover rate, retention rate of key positions, etc.) and to set early-warning thresholds.
  

Practical Point: The technical executive appointment right falls within the category of protective provisions in law; its validity derives from Article 59 of the newly revised Company Law on the powers of the shareholders’ meeting and Article 67 on the powers of the board of directors — shareholders may agree through the articles of association or a shareholders’ agreement that certain matters require the consent of a specific shareholder. The key is that this right should not “substantively replace” the board’s statutory powers, but should be positioned as “a special arrangement among shareholders regarding corporate governance.”

Fourth Right: Open-Source Decision Right

The “Angel” and “Devil” of Open Source

Open source is a “double-edged sword” for software companies. On the one hand, a sound open-source strategy can bring community contributions, brand recognition, and ecosystem lock-in effects — the success of Redis, MongoDB, and Elasticsearch is largely attributable to open-source strategy. On the other hand, an improper open-source decision may directly destroy the company’s commercial value — open-sourcing a core profit-generating module under a “copyleft” license such as GPL may reduce the investor’s investment value to zero.

A landmark case in 2021: an enterprise software company open-sourced its core analytics engine under the AGPL license, severely undermining the value of its commercial edition; the company, originally valued at RMB 800 million, was eventually acquired for less than RMB 200 million. When the investors received the liquidation proceeds, they discovered that this open-source decision had been made unilaterally by the founder after their investment — the investment agreement contained no clause whatsoever concerning open source.

Key Points of Clause Design

• Tiered Approval Mechanism: Tier the approval according to the commercial impact of the open-source act — non-core tool libraries/components (MIT/BSD/Apache) are approved by the CTO; open-sourcing of core functional modules requires board approval; open-sourcing of modules involving the company’s main revenue source requires investor approval.
• License Selection Constraints: Explicitly restrict the scenarios and conditions for using “copyleft” licenses (GPL/AGPL) — limited to auxiliary components that do not constitute the company’s core commercial value, and subject to the investor’s written consent.
• Post-Open-Source Commercialization Path: If a decision is made to open-source certain modules, the post-open-source commercialization plan should be agreed at the same time — whether to follow the Open Core model (closed core + surrounding open source) or the Cloud Hosting model (open-source code + monetization through cloud services).
• Compliance Audit: Periodically (every six months or every year) scan the company’s code base for open-source license compliance, to ensure no employee has inadvertently introduced code under a restrictive license such as GPL.
  

Fifth Right: Data Security Audit Right

Data Security — The “Achilles’ Heel” of SaaS Companies

For software companies, especially SaaS businesses, data security is not a technical issue but a matter of survival. A single serious data breach can directly bring down a star company that has already reached Series C.

Between 2023 and 2025, at least 3 SaaS companies in China valued above RMB 1 billion suffered massive customer attrition due to data security incidents, one of which went directly into bankruptcy liquidation. Post-mortem review found that these companies had long-standing deficiencies in data security governance — no dedicated security engineers, plaintext password storage, and API interfaces lacking access control — yet investors were completely unaware of these issues in post-investment management, because the financial statements showed no anomaly.

Key Points of Clause Design

• Periodic Security Audit: Conduct at least one penetration test and security audit by an independent third-party security institution each year, with the results submitted to the investor in report form (it may be agreed that the technical details be submitted after desensitization).
• Security Incident Notification Obligation: Any leak involving customer data or personal information, any unauthorized access, or any major system security vulnerability must be reported to the investor within 24 hours.
• Data Compliance Milestones: Make key data security certifications (such as ISO 27001 and the Class III Multi-Level Protection Scheme) KPIs of post-investment management and include them in the assessment of management.
• Data Export Controls: If the company’s business involves data export (e.g., use of overseas cloud services), it must be reviewed by the investor and meet the compliance requirements of the Personal Information Protection Law, the Data Security Law, and the Cybersecurity Law.
  

Statutory Link: The legal basis for the data security audit right includes Article 27 of the Data Security Law (data processors shall establish and improve data security management systems), Article 54 of the Personal Information Protection Law (personal information processors shall regularly conduct compliance audits of their personal information processing activities), and Article 67 of the newly revised Company Law on the board’s supervisory functions. As shareholders, investors have a legitimate interest in supervising the company’s performance of its legal data protection obligations — this concerns not only the company’s value but also the investors’ own compliance risks.

The Implementation Framework for the Five Rights: From Clause to Execution

The five rights above are not as simple as adding a paragraph to the SPA. Effective implementation requires a complete execution system:

VII. Risk Warnings

1. Risk of Excessive Control: The combined use of the five rights above may be deemed the investor’s “substantive control” of the company’s daily operations, thereby affecting the protection of limited liability of shareholders under company law. It is recommended to attach objective standards such as “reasonable commercial judgment” to the rights clauses.
2. Balance in Negotiation with the Founder: At the seed or Series A round, the founder may not accept all five rights. It is recommended to pursue them in stages by round — at the seed round, secure at least the code review right and the data security audit right; from Series B onward, pursue the full set of rights.
3. Enforceability under Chinese Law: Some rights clauses (such as the code review right) are “unnamed rights” under Chinese law, requiring special attention to enforceability in judicial practice. It is recommended to provide an arbitration clause in the agreement, with disputes resolved by arbitrators with a technology-industry background.
4. Special Considerations for International Investment: If the investor involves foreign capital, the exercise of some rights (especially in the data security area) requires extra attention to the compliance requirements of the Cybersecurity Review Measures and the negative list for foreign investment.
   

VIII. Recommended Actions

1. Immediately Review Existing Investment Agreements: Open all SPAs and SHAs signed in the past two years and check item by item whether they contain the five software-industry special rights clauses above. If not, assess the feasibility of supplementing them in the next financing round or board resolution.
2. Build Post-Investment Technical Management Capability: Legal clauses alone are insufficient to guarantee effective exercise of the rights. Investors should form or engage an external technical advisory team responsible for code review, security audit, and other work requiring professional judgment.
3. Standardize Clause Templates: Incorporate the five rights above into the investment team’s standard clause library as the “default configuration” for software-industry investments, and present them as industry practice when negotiating with founders.
4. Prioritize Securing the Code Review Right: Among the five rights, the code review right is the information gateway — it helps investors detect early signals of other problems. If only one right can be secured in negotiation, this one is recommended as the priority.
5. Communicate Well with the Founder: Proactively explain to the founder that these rights are not “distrust” but a “shared moat” — they help the company avoid fatal mistakes in technology roadmap, talent strategy, and data compliance, and ultimately benefit all shareholders.
   

Disclaimer

This article is for general reference only and does not constitute legal opinion or advice. For specific legal issues, please consult a professional lawyer. The cases in this article are adapted from real events, and the company names and details involved have been anonymized.

Lawyer Kevin Jun Lin

Senior Corporate Lawyer – Industry Legal Practice Expert

💬 Feel free to share your views and reasons in the comments section

Further Reading

• Technical Debt Disclosure: When Due Diligence Reveals Your ‘Perfect System’ Is Actually Legacy Code
• Key Personnel Lock-Up Clauses: The CTO Leaves and Valuation Halves — How to Bind Core Team Members
• ESOP Design for Software Companies: Why Give Programmers 10% Equity? Talent Is Productivity
• Source Code Escrow: What If Investors Fear Being Held Hostage When the Founder Controls All the Code?
• IP Contribution in the Software Industry: A Founder Contributes Code at a 10 Million Valuation? Investors Go Silent After Due Diligence
• When a Founder Suddenly Dies, Who Gets the Equity? Without This Clause in the Charter, Everything Changes

If you need professional support in shareholders’ agreements, investment term review, or equity disputes, please contact Lawyer Kevin Jun Lin (Shenzhen Corporate Lawyer) for one-on-one consultation.