Primary question: Can one unified workspace backed by a bidirectional graph replace your entire SaaS stack?
RepoDaily adoption score
RepoDaily rates this as 86/100 (strong) for adoption: evidence, installation path, production risk, differentiation, license clarity, and AI/agent fit are scored from the article sources and adoption notes.
4 source(s) across 2 source category/categories, plus a RepoDaily-specific evidence module when available.
6 workflow step(s), 6 next-action step(s), and 3 command/install signal(s) were detected.
Trending momentum is +1,180 stars, with maintenance/release/issue signals counted when present.
Risk is marked high, with 7 security note(s) and 4 explicit skip condition(s).
3 opportunity lens item(s), 5 alternative(s), and 4 type-specific section(s) support differentiation.
License source or license wording is present.
7 AI/agent-related signal(s) were detected in the article text and metadata.
Project overview
Macro is an all-in-one team workspace that collapses email, chat, documents, tasks, AI agents, calls, and CRM into a single application. The README states the founding team built Macro because their previous venture reached ~20 people and the patchwork of Slack, Linear, Notion, HubSpot, and Superhuman — glued together with MCP and Zapier — became chaotic and what they call 'not computable.' Macro is a from-scratch redesign where every surface shares one backend and cross-references between a doc and a task, or a channel message and an email, are stored natively as a bidirectional graph.
The frontend is built in SolidJS and the backend in Rust, chosen for speed and reliability. Real-time collaborative documents use CRDTs — specifically loro-crdt 1.13.7, visible in the package.json catalog — and the text editor runs on Lexical 0.45.0 with multiple Lexical sub-packages pinned via overrides. The package manager is Bun 1.3.5. The team, based in NYC and Toronto, has dogfooded Macro internally with approximately 15 people for two years before this open-source release.
The codebase is substantial. The Cargo.toml workspace defines over 90 members spanning domain crates (agent, crm, memory, email_api_client, gmail_client, search_service), GraphQL layers (graphql_email, graphql_channel, graphql_permission), client cache variants (cache-core, cache-idb, cache-sqlite, cache-wasm), and dozens of services (email_service, sync-service, mcp_service, document_cognition_service, call_recording_preview_handler). On the TypeScript side, package.json workspaces include apps/web, packages/observability, packages/collaboration, packages/loro-mirror, packages/lexical-core, and bot services for Anthropic status and Stripe payments. This is not a weekend project — it is a full platform with the operational complexity that implies.
Each functional surface in Macro is called a 'block.' The README describes nine blocks: Email (multi-account unified inbox with Gmail support, keyboard shortcuts, shared inboxes), Messages (channels and DMs for focused technical discussions), Tasks (Linear-inspired, integrated with channels and email), Docs (real-time collaborative, markdown-native, CRDT-backed), Canvas (2D board with embedded @links), Agents (team-level memory, can take action), Calls (recorded, transcribed, logged to team memory), File storage (auto-imported from email and channels, searchable), and Pull requests (linked to tasks, embeddable in channels, available to agents via GitHub integration).
Why it is trending now
- 1180 period stars at trending rank 2, driven by the appeal of an AGPLv3 open-source alternative to a multi-billion-dollar SaaS stack.
- Full source release of a production workspace product dogfooded by ~15 people for two years — not a proof-of-concept.
- Rust + SolidJS stack with CRDT collaboration (loro-crdt 1.13.7) appeals to developers seeking performance-oriented alternatives to Electron-based tools.
- Shared team-level AI memory across all blocks is a differentiator that no single incumbent (Slack, Linear, Notion, HubSpot) offers natively.
- Bidirectional graph linking means agents traverse relationships between emails, tasks, docs, and CRM records without external glue code.
Problem it solves
- Teams juggle 5+ disconnected tools — Slack, Linear, Notion, HubSpot, Superhuman — that do not share data models or context.
- Glue infrastructure built on MCP and Zapier breaks as headcount grows past ~20, making the company 'not computable' per the README.
- Context switching between tools fragments attention and forces manual cross-referencing (copying a Slack message into a Linear ticket, linking a Notion doc in an email).
- AI agents operating within a single tool cannot access data locked in other tools, limiting automation potential.
- Each separate tool charges per-seat, inflating software spend for small companies.
How it works
- The application is organized into modular 'blocks' — Email, Messages, Tasks, Docs, Canvas, Agents, Calls, File storage, Pull requests — each with a purpose-built UI surface.
- All blocks share a single Rust backend. Cross-references between any two entities (a doc and a task, a channel message and an email) are stored as edges in a bidirectional graph, not as foreign keys in isolated tables.
- Users @link any entity to any other entity, creating traversable relationships that agents and search follow. A PR can be linked to a task, embedded in a channel, and visible to an agent simultaneously.
- Real-time document collaboration runs on CRDTs (loro-crdt 1.13.7) with a Lexical 0.45.0 editor, enabling conflict-free concurrent editing across users.
- Agents access a unified team-level memory layer backed by the memory and embedding crates, plus an MCP service for tool integration. Calls are recorded, transcribed, and logged to this same memory.
- The backend communicates via Apollo/GraphQL (async-graphql 7.2.1) with Bebop serialization for the sync service, deployed across AWS Lambda functions and long-running services.
Product demo and interface preview
Architecture: 90+ Rust Workspace Members and a SolidJS Frontend
- Cargo.toml defines 90+ workspace members including domain crates (agent, crm, memory, embedding, search_service), GraphQL layers (graphql_email, graphql_channel, graphql_permission, graphql_properties), and infrastructure services (mcp_service, mcp_auth_proxy, sync-service, email_service, document_cognition_service).
- Frontend is SolidJS with Bun 1.3.5 as package manager. The editor stack pins Lexical 0.45.0 across 20+ sub-packages via overrides, and CRDT collaboration uses loro-crdt 1.13.7.
- Client cache has four variants: cache-core (shared), cache-idb (IndexedDB for web), cache-sqlite (native), cache-wasm (WebAssembly), indicating multi-platform targeting.
- TypeScript workspaces include packages/observability, packages/collaboration, packages/loro-mirror, packages/lexical-core, plus services for AI editing, Anthropic status, and Stripe payments.
- Backend uses axum 0.8 for HTTP, async-graphql 7.2.1 for GraphQL, async-openai 0.36.1 for LLM calls, and Bebop 3.1.3 for sync-service serialization.
- AWS dependencies include DynamoDB, S3, Lambda, SES v2, SQS, SNS, and MSK (Managed Kafka) — indicating a serverless event-driven architecture with substantial cloud lock-in.
Integration Surface: Blocks, @Links, and External Services
- Nine documented blocks: Email (Gmail multi-account), Messages (channels + DMs), Tasks (Linear-inspired), Docs (CRDT, markdown-native), Canvas (2D board), Agents (team-level memory), Calls (transcribed), File storage (auto-imported), Pull requests (GitHub-linked).
- An MCP service and MCP auth proxy exist as separate workspace members, indicating Model Context Protocol support for agent tool use.
- GitHub pull request integration links PRs to tasks and embeds them in channels, making them available to agents for context.
- gmail_client crate handles email ingestion; email_api_client crate provides the abstraction layer for multi-provider support.
- unfurl crate and unfurl_service handle link previews, enabling rich embedding of external URLs in messages and docs.
- async-openai 0.36.1 with features (chat-completion, embedding, byot) indicates OpenAI as the primary LLM provider, with 'bring your own token' support.
Adoption Checklist: What You Need to Run and Contribute
- Local setup: Follow docs/RUNNING_LOCALLY.md (referenced in CONTRIBUTING.md) for the full application stack.
- Rust changes: Run 'cargo fmt' and 'just clippy' before pushing. Test affected crates with 'cargo test -p <crate>'.
- Database changes: Run 'just prepare_db' from the repository root to refresh the sqlx query cache after modifying SQL or migrations.
- Frontend changes: Use Bun 1.3.5 for installs. Lint with Biome ('bunx @biomejs/biome lint') or oxlint 1.73.0. Type-check with 'tsc --noEmit'.
- Contributions require a linked issue before PR submission. Branch and PR titles follow Conventional Commits: 'feat(chat): add dev observability' or 'fix(email): handle empty thread subjects'.
- License is AGPLv3 — contributing means your changes are licensed under the same copyleft terms. Hosting Macro for other users triggers AGPLv3 source disclosure obligations.
- Code style requirements are documented in docs/STYLE_GUIDE.md.
Alternative Matrix: How Macro Compares to Incumbents
The README explicitly names Slack, Linear, Notion, HubSpot, and Superhuman as the tools the founders used and replaced. Macro's advantage is that all nine blocks share one data model and one backend, so a task references an email thread, a doc embeds a channel message, and an agent traverses all of it. Each incumbent excels in its own domain but requires external integration (MCP, Zapier, API glue) to connect to the others — and that glue is what the founders describe as breaking at scale.
The trade-off is depth versus breadth. Linear's task management is more mature than Macro's Tasks block. Notion has more templates and third-party integrations than Macro's Docs block. Slack's messaging infrastructure handles enterprise scale that Macro has not yet proven. Macro bets that the unified graph and shared AI memory outweigh the depth gap — a bet that only matters if your team's pain is fragmentation, not feature depth in any single category.
Who should pay attention?
Good fit if
- Small companies (under ~50 people) currently paying for Slack + Linear + Notion + HubSpot and experiencing tool fragmentation pain.
- Rust or SolidJS engineers who want to contribute to an AGPLv3 workspace platform and understand the codebase.
- Teams that want AI agents with access to unified cross-tool context rather than siloed per-tool assistants.
- Self-hosting advocates who prefer AGPLv3 guarantees over proprietary SaaS lock-in.
Skip for now if
- Teams that need enterprise SSO, audit logging, or compliance certifications (HIPAA, SOC 2) — none are documented in the source pack.
- Organizations already deeply integrated with Salesforce or other enterprise CRM platforms — Macro's CRM is early-stage.
- Teams without Rust experience who need to self-host and debug issues in the backend.
- Anyone requiring production SLAs — the product is dogfooded by ~15 people and has no documented deployment guide beyond local development.
Risks and cautions
AGPLv3 copyleft, 90+ workspace members requiring significant infrastructure, heavy AWS dependencies, and a product still validated by only ~15 internal users create high adoption risk for external production use.
- AGPLv3 requires disclosing source modifications if you host the software for users over a network — this affects any SaaS deployment of a modified Macro.
- The Cargo workspace has 90+ members and package.json lists 10 workspace packages — deploying and operating this stack requires substantial engineering capacity.
- AWS dependencies (DynamoDB, Lambda, S3, SES, SQS, SNS, MSK/Kafka) make self-hosting non-trivial; there is no documented self-hosted deployment path beyond RUNNING_LOCALLY.md.
- Pinned dependencies and patched packages (7 patchedDependencies in package.json) indicate active dependency management that external deployers must replicate.
- The product has been dogfooded by approximately 15 people for two years — limited external validation at scale.
- AGPLv3 copyleft license covers all contributions; contributors must agree to the same terms per CONTRIBUTING.md.
- Dedicated mcp_auth_proxy service handles authentication for MCP agent tool calls.
- macro_authorization crate manages permissions; graphql_permission crate exposes permission checks via the API layer.
- dataloss_prevention_handler service exists in the workspace, indicating DLP capabilities.
- organization_retention_handler and organization_retention_trigger services manage data retention policies.
- email_suppression_handler manages email suppression lists for compliance.
- AWS Secrets Manager integration (aws-sdk-secretsmanager 1.104.0) for credential management.
Alternatives to compare
| Approach | When to use | Trade-off |
|---|---|---|
Notion | Docs and wikis are your primary need; you do not require email, chat, or CRM in the same tool. | Commercial, freemium |
Linear | Engineering issue tracking is your core need; depth in task management matters more than unified context. | Commercial, free tier |
Slack | Team messaging at enterprise scale is the priority; you need mature integrations and compliance certifications. | Commercial, freemium |
Twenty CRM | You need an open-source CRM only, without the workspace unification. | Open-source, self-hosted |
Outline | You need an open-source team wiki and documentation tool. | Open-source, self-hosted |
What this trend reveals
Consolidate SaaS spend with self-hosted deployment
A small company paying for Slack, Linear, Notion, and HubSpot could replace all four with a self-hosted Macro instance, eliminating per-seat charges across multiple tools. The AGPLv3 license permits self-hosting for internal use without source disclosure obligations.
Run docs/RUNNING_LOCALLY.md to confirm the full stack operates outside Macro's own cloud, then map your team's daily usage to Macro's nine blocks.
Build custom agent skills on unified data
Macro's agent crate, skills crate, system_skills crate, and MCP service provide an extension surface for custom AI agent behaviors that access emails, tasks, docs, and CRM records through the bidirectional graph — impossible when data is siloed across separate SaaS tools.
Examine crates/agent, crates/skills, and crates/mcp_service in the repository to understand the skill registration API and MCP tool interface.
Extend the block system for domain-specific surfaces
The README describes blocks as modular and extensible 'like Lego,' with each surface sharing one backend. A team with domain-specific needs (e.g., a manufacturing tracking block or a legal case management block) could build on the existing bidirectional graph rather than integrating yet another tool.
Review how existing blocks like Tasks and Canvas reference the shared entity model in crates such as complete_graph, entity_mutation, and foreign_entity.
RepoDaily verdict
Macro is one of the most ambitious open-source releases in the workspace category — a 90+ crate Rust platform with a SolidJS frontend that has been in production dogfooding for two years. The bidirectional graph and shared AI memory are genuinely differentiated. But the AGPLv3 license, AWS-heavy architecture, and early-stage validation (~15 internal users) mean this is a project to contribute to and build on, not one to deploy casually for production. For small teams frustrated by tool fragmentation, it is worth the 2-3 day evaluation. For anyone needing enterprise-grade stability, the depth gap versus incumbents remains real.