Macro: A Rust and SolidJS Workspace That Tries to Replace Five Tools at Once

What Macro Actually Solves

The README is explicit about the problem: "The company was not computable. It was chaotic." That is a strong statement, and it frames Macro as a redesign of work software from the ground up, not just another integration layer. The value proposition is coherence: because every object lives in the same backend, you do not need to copy data between tools or maintain fragile automation. If you have ever lost context because an email thread, a task, and a channel message lived in separate silos, Macro is aimed directly at you.

The Bidirectional Graph as the Core Mechanism

The graph is also what enables the unified search tool for agents. The README says agents can search all file attachment PDFs directly, parsed out of email, without first pulling email threads and then attachments. That is a practical benefit of having files stored in the same graph as the emails they came from. The bidirectional nature means that when a CRM record is updated because of a discussion in a channel, the channel message can also show the CRM update. This is the kind of cross-referencing that typically requires custom scripting or manual copy-paste in a multi-tool setup.

The Block-Based Feature Set and What It Covers

That is a wide surface area, and the README claims each block studies the best prior art and tries to improve it. For example, Macro Mail is inspired by Superhuman's keyboard-first interface, and Chat is designed to be more focused than Slack: the first few replies show inline, the rest collapse into a thread, and threads are permissioned severally so they can be shared across channels by copying links. This is not a thin wrapper around existing tools; it is a native implementation of each surface. The trade-off is that you are betting on the quality of all these implementations rather than relying on mature, battle-tested products. The README admits the team has dogfooded it for two years with about 15 people, but that is a small sample size compared to the user bases of the tools it aims to replace.

Getting It Running: Commands and Config

The absence of quick-start commands in the README is a gap. A typical open-source project includes a "Getting Started" section with cargo run or docker-compose up. Here, the README is mostly marketing and feature lists, with links to external docs. That means the first step for any adopter is to read the docs site, not the repo. The daily release pattern also means you should pin a specific version rather than tracking main, because the API or data model could change between releases. The repo has a default branch of main and is not archived, so it is actively maintained, but the maintenance cost is on you to keep up with the pace.

Real Limitations and Failure Modes

Another failure mode is the reliance on a single vendor for the hosted version. The README links to macro.com for sign-up, which suggests a commercial cloud offering, but the open-source repo is self-hostable. If the company changes direction or the hosted service shuts down, self-hosters are on their own. The daily releases also imply rapid iteration, which can introduce regressions. The README's claim that the company was "not computable" before Macro is a strong narrative, but it is also a warning: Macro is designed for a specific philosophy of work, and if your team does not adopt that philosophy, the tool will not fix your processes. The bidirectional graph is powerful, but it only works if your team actually uses @links consistently. Without that discipline, you are just using another chat app.

Alternatives and the Graph Difference

The README mentions MCP as part of the founders' previous glue, and Macro itself exposes a tools/MCP surface for AI agents. That is an interesting contrast: instead of using MCP to connect separate tools, Macro embeds the MCP surface into its own graph. For teams that already use MCP to connect their existing stack, Macro might be redundant. But for teams that want to reduce the number of moving parts, Macro consolidates the connectors into one system. The choice comes down to whether you prefer a best-of-breed stack with integration glue or a single system with a unified data model.

Maintenance, Licensing, and Upgrade Cost

The upgrade cost is high because of the release frequency. With releases every day or two, you will need to track changes and test upgrades frequently. The README does not mention a migration guide or changelog, so you may need to read the source diffs to understand breaking changes. The project is written in Rust and SolidJS, which are not the most common stacks, so hiring developers who can contribute to the codebase may be harder than with TypeScript or Python. However, the use of CRDTs for docs suggests a sophisticated implementation, and the daily releases indicate an active team. The maintenance burden is on you to stay current, or you can rely on the hosted version and avoid self-hosting entirely. The README's emphasis on speed and reliability is a promise, but you should verify that with your own load testing before committing.

Editorial conclusion

Adopt Macro if you run a small team that is tired of gluing Slack, Linear, Notion, and Gmail together and you are willing to accept AGPL-3.0 and a young codebase. Do not adopt it if you need a mature, plugin-rich ecosystem or if your compliance team rejects AGPL for internal tools. Before committing, verify that the bidirectional graph actually meets your cross-referencing needs, test the self-hosting path with a real deployment, and check the current state of the GitHub integration and agent memory features, since the README promises more than the truncated docs confirm.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes