The assumption baked into traditional software is that the vendor knows what the customer needs. The product ships, the customer adapts, and customization means choosing from a list of options someone at the company pre-approved. What a customer cannot do is change how the software actually works.
Most software buyers have learned to live with that. The workaround is the spreadsheet. When the app does not compute something the right way, or does not connect to a data source the firm uses internally, someone exports the data and finishes the job in Excel. The software ran out of flexibility at the point where flexibility mattered, so the spreadsheet took over.
Microapps are an attempt to solve that at the architecture level rather than patch around it.
What a microapp is
A microapp is a full React application that runs locally on the user's machine, distributed through a plugin rather than deployed to a server. There is no hosted environment to operate, no separate login, and no infrastructure bill. The user installs the plugin, invokes it with a plain-language instruction, and the app starts up on their laptop.
The data layer works through MCP connectors. When the app needs data, it pulls it through whatever connectors the firm already has configured. Those connectors can point at the software vendor's data, the firm's internal warehouse, or any other source. The app does not need to know in advance where the data is coming from, and the vendor does not need to know what the firm tracks in other systems.
Our first microapp was Fund Modeling, a scenario planning console for venture capital fund managers. A fund manager types something like "fund modeling for Great Basin Capital" and the app starts: It resolves the firm, pulls fund holdings, valuations, cash flows, and benchmark data through the MCP, writes a local snapshot to disk, and opens in the browser. What the user gets is a working application, not a conversation.
What changes when the customer owns the code
The most immediate change is that business logic becomes adjustable. If the app computes something in a way that does not match how the firm actually operates, the user can open the file and change the function. No feature request, no roadmap conversation.
The second thing is data connectivity. A firm that tracks proprietary data in its own warehouse can connect that source through an MCP connector and put it on the same page as the vendor's data. In practice, this means a fund manager could put portfolio company data from their own internal system directly alongside their Carta marks in the same analysis. That is not something a vendor can typically build for a customer, because doing so would require knowing the data exists, agreeing to support the integration, and shipping it. With MCPs, the firm sets up the connector itself.
The third thing is data residency. The app runs locally. The snapshot sits on the user's laptop. The app stores any scenarios or analysis the user builds in a directory the firm controls. A plugin update can replace all the app code without touching that directory.
One detail worth calling out separately: There is no build step. The app's JSX transpiles in the browser via a service worker, so a user can edit a file, hit refresh, and see the change. The gap between "I wish this column showed something different" and seeing it change is short in a way that matters for whether customization happens.
Where microapps fit
Microapps work under a specific set of conditions. The data needs to refresh slowly, on a weekly or monthly cadence rather than in real time, because the architecture pulls once at launch into a local snapshot rather than maintaining a live connection. The use case needs to benefit from customization. And the output needs enough depth and visual complexity that a conversational interface would not serve it well.
Those conditions describe a large portion of financial services workflows: sensitive data, firm-specific analytical needs, and outputs that are charts and models rather than text. But they apply outside financial services too. Anywhere software has historically fit most firms adequately but no firm exactly, the microapp pattern has something to offer.
Microapps involve tradeoffs. You give up real-time data, live collaboration, and the ability to push updates to all users simultaneously through a server deployment. What you get is local ownership, the ability to connect to arbitrary data sources through MCPs, and an app you can modify without anyone's permission.
The plugin is the distribution mechanism. Updates ship through it. The user runs the latest version of what the plugin contains, and the vendor can iterate without asking anyone to reinstall or re-authenticate.
Why this matters now
The spreadsheet workaround has existed for decades because there was no better option. Software was rigid and external data was hard to bring in, so people exported and computed elsewhere. People filled the gap between "what the software does" and "what this firm needs."
MCPs change the data connectivity piece. Locally run apps change the ownership piece. Put those together and the gap the spreadsheet used to fill becomes addressable inside a proper interface, with versioning, business logic that can be audited, and calculations that produce the same answer every time.
Whether microapps become a standard delivery pattern for a broad class of use cases is an open question. For the narrow set of conditions where they fit, the structural advantages are real, and we have not found a better tool for those cases yet.
>> Read part 2 of this series: "Building a microapp inside a plugin: Architecture and tradeoffs"
DISCLOSURE: This communication is on behalf of eShares, Inc. dba Carta, Inc. ("Carta"). This communication is for informational purposes only, and contains general information only. Carta is not, by means of this communication, rendering accounting, business, financial, investment, legal, tax, or other professional advice or services. This publication is not a substitute for such professional advice or services nor should it be used as a basis for any decision or action that may affect your business or interests. Before making any decision or taking any action that may affect your business or interests, you should consult a qualified professional advisor. This communication is not intended as a recommendation, offer or solicitation for the purchase or sale of any security. Carta does not assume any liability for reliance on the information provided herein. ©2026 Carta. All rights reserved. Reproduction prohibited.
