Governance That Survives Its Platform

On January 11, 2024, Mint.com shut down. Twenty million users who had tracked their finances through Intuit’s platform for sixteen years were given ninety days to export their data and find an alternative. Some exported successfully. Many lost years of financial history. Everyone learned the same lesson: data that lives only on a platform lives only as long as the platform does.

Corporate governance platforms have not yet had their Mint moment. But the structural conditions are identical.

The platform lifecycle

Every SaaS platform follows a predictable lifecycle. It launches. It grows. It raises prices. It gets acquired or it runs out of funding. If acquired, the new owner extracts value: features are removed, prices increase, the product is merged into a larger suite, or it’s shut down entirely. If funding runs out, the platform enters a death spiral — reduced investment, degraded service, eventual shutdown.

This lifecycle takes five to fifteen years. Corporations last longer.

A founder who incorporates in 2026 and manages their corporate records through a SaaS platform will almost certainly outlive that platform. When the platform shuts down, the founder faces the same question the Mint users faced: can I get my data out, and will it be usable when I do?

For most governance platforms, the answer is: partially, and no.

The export is a CSV or a PDF bundle. The structure is gone. The signatures are gone. The history is gone. The relationship between documents — which resolution authorized which equity issuance, which board vote preceded which bylaw amendment — is gone. What remains is a pile of files that a lawyer must reassemble into a coherent narrative, at significant expense.

Protocol versus platform

The distinction between protocol-native and platform-dependent governance is fundamental.

A platform is a product. It has a company behind it, a pricing model, a terms of service, and a lifespan. When you build on a platform, you inherit its constraints and its mortality.

A protocol is a specification. Git is a protocol. HTTP is a protocol. SMTP is a protocol. Protocols don’t have companies. They don’t have pricing models. They don’t shut down. They exist as long as there are implementations, and there are always implementations because the specification is open.

When your corporate governance is protocol-native — when it lives in git, structured as files, signed with standard cryptographic tools — it is decoupled from any platform’s lifecycle. TheCorporation provides tooling, hosting, and coordination services. But the governance state itself is a git repository. If TheCorporation were to disappear tomorrow, every customer would retain a complete, functional, independently verifiable copy of their corporate records.

This is not a disaster recovery plan. This is the architecture.

The three platform risks

Platform-dependent governance exposes corporations to three specific risks that protocol-native governance eliminates.

Pricing risk. When your governance data lives in a platform’s database, the platform sets the price of access. The initial price is an acquisition strategy. The long-term price is a retention strategy. These are different numbers. Carta’s pricing has increased substantially since its founding, and customers have limited leverage because switching costs are high — their entire corporate history lives in Carta’s infrastructure.

In a protocol-native model, the data is portable by construction. Switching coordination providers means pointing your git remote at a different URL. Your history, your signatures, your complete corporate record comes with you. The switching cost approaches zero, which means the pricing pressure works in your favor rather than against it.

Acquisition risk. When your governance platform gets acquired, the acquirer’s incentives may not align with yours. The acquirer might discontinue the product. They might merge it into an enterprise suite you don’t need or can’t afford. They might change the data model in ways that lose information. They might simply raise prices because they’ve calculated that the switching costs trap enough customers to make it profitable.

In a protocol-native model, the acquisition of a tooling provider has no effect on the data. The repository doesn’t know or care who hosts the remote. The signatures don’t reference the platform. The history is self-contained.

Legal risk. When your governance data lives in a platform’s infrastructure, it’s subject to the platform’s legal obligations. A subpoena served on the platform can compel disclosure of your corporate records. A legal dispute between the platform and a third party can result in your data being frozen as part of discovery. The platform’s compliance obligations — which may differ from yours — can affect how your data is stored, retained, or deleted.

In a protocol-native model, your corporate records live on your infrastructure. Legal process must be directed at you, not at a third-party platform that happens to hold your data. You maintain direct control over custody, retention, and disclosure.

What portability actually means

Portability is a word that every SaaS platform claims and few deliver. True portability requires four properties:

Completeness. The export includes every record, every version, every signature, every historical state. Not a current snapshot — the full history.

Structure. The exported data retains its relationships and its schema. A board resolution remains linked to the equity issuance it authorized. A signature remains bound to the specific content it signed.

Independence. The exported data is usable without the exporting platform’s software. It can be read, verified, and operated on using open tools.

Continuity. The exported data can be imported into an alternative system and used to continue operations without reconstruction or re-authorization.

Git repositories satisfy all four properties by default. git clone produces a complete, structured, independent, continuable copy of the repository. This is not a feature of TheCorporation — it’s a property of the protocol.

A concrete scenario

Your governance platform sends an email: they’ve been acquired. The new owner is sunsetting the product in six months. You need to migrate.

Platform-dependent: You download a ZIP file of PDFs and CSVs. You hire a lawyer to review the export for completeness. You discover that signature metadata wasn’t included. You request it separately. The platform’s support team, now reduced during the transition, takes three weeks to respond. You manually reconstruct the chain of authorizations in your new system. The process takes two months and costs five figures.

Protocol-native: You update your git remote URL to point to a new host. You run git push. The migration is complete. Time elapsed: thirty seconds. Cost: zero. Every signature, every commit, every branch, every historical state transferred intact.

This is not an optimization. It’s a different category of thing.

Build on protocols, not platforms

The lesson of the last thirty years of technology is clear: platforms come and go, protocols endure. Email outlived AOL. The web outlived Netscape. Git outlived every proprietary version control system. TCP/IP will outlive all of us.

Corporate governance is infrastructure. It must be durable, portable, and independent. Building it on a platform — any platform, including ours — is an architectural mistake if the platform owns the data.

Building it on a protocol means the data is yours. The history is yours. The signatures are yours. The governance survives the platform because the governance was never in the platform. It was in the protocol. The platform is a service layer, useful but replaceable.

Your corporation should outlive its tools. Build on protocols. Everything else is a lease.