175 - Free
Jacob: I call it the No- Notion balkanization. The whole company started on Notion and when we got to 20 people in our, before our pivot, you know, we had the sales team, the guy's like, "I want Salesforce." You're like, "Okay, you're the VP of sales. Sure, you can have Salesforce." Okay, the engineering team's like, "Ah, Notion's slow, whatever.
We gotta go to Linear." And then all of a sudden Notion is basically just for like almost nothing.
[00:00:27] Introduction
Andrew: Hello. Welcome to Dev Tools FM. This is a podcast about developer tools and the people who make them. I'm Andrew, and this is my co-host, Justin
Justin: Hey, everyone. Uh, we're really excited to have Jacob Beckerman on with us. So Jacob, you are the founder and CEO of Macro. Um, it's macro.com, which is an awesome domain name. talk about the story of how y'all got that. but Macro is sort of a universal workspace for people doing, um, sort of information work in general, but it seems like it's, like, accreting all these capabilities of, like, all these disparate tools that we end up using.
So I kind of, I'm kind of framing it like Google Workspace and, like, Slack and sort of all this stuff, like, combined and together. Y'all even have, like, a CRM part, as a part of it. So excited to dive in and chat about it. But before we get started, um, would you like to tell our audience a little bit more about yourself?
Jacob: Yeah, sure. Um, Jacob, I, uh, my background's in computer science. Um, from like, a early teenager, I was obsessed with robotics and video games, and that led me to, uh, Penn, where I started as an electrical engineer. I switched into compute- to computer science and, uh, finance and spent a lot of time hacking on various projects.
Macro, uh, was, was one of them, and now I've spent the past sort of five years, uh, building various things in this corporate entity. We've pivoted around. We'll talk about that. Um, but yeah, based in New York, here with our team, 15 people, and, um, feeling like we're building something that I was meant to build now, so
Justin: Nice. That's exciting
[00:02:06] Macro's Origin Story
Andrew: So you started out as an investment logic engineer. I wanna know what, what that is first. What does an investment logic engineer do?
Jacob: Yeah. So I was-- That was between my undergrad and master's in NLP, so I was doing some NLP work, um, that turned into, into grad school. Um, and when I worked at Bridgewater, it was, um, just the investment engineering team, um, and basically like writing Scala code for trading. Um, and when I was there, I was reading just as like a keener, um, reading all of the, like, stuff that I could about investing.
I used to think investing was like s- I used to be just obsessively read everything I could, um, about, about investing. Um, then I was studying finance at Wharton at the time. Um, and in the process of doing that, I just felt that we could build a much better way to read documents that would allow me to sort of ingest information a lot faster, 'cause half the job I was, um, writing code in an IDE, and then the other half, just for my own personal interest, was in Adobe Acrobat reading documents.
And I thought, "This program's really old. Um, and why is there no, like, special way to, like, read all of this really cool information that they published over the years?" Um, so that led me to Macro.
Justin: Nice, nice. And before it was Macro was called Coparse,
Jacob: Yeah, Coparse. It was the only $7 .com that we could buy, and I had no money. And so we were looking for-- 'cause Paul Graham says if you don't have the .com, change your name. I don't know if you've seen that article from, like,
Justin: yeah
Jacob: ~~Ian. Um, ~~so, you know, we wanted a .com and I liked the idea of, like, parsing documents, so that was, that was the idea.
But as soon as we could, we, we got macro.com
Justin: Yeah. It's, um, interesting to talk about that, like, evolution. So y- you sort of talked about this, like, thinking about, like, PDFs and, um, like document, like how you interface with a document and how you maybe edit and read them to this, like, full workspace that you have today.
[00:04:14] Evolution to a Unified Workspace
Justin: when did you start that transition of like, well, actually, I wanna do more than just like, you know, editing PDFs or like reading PDFs.
I kinda want to like build more into this, like, idea of a larger, larger workspace. What was your transition there?
Jacob: Yeah, two, two different things. Right from the first day that I had started Macro, I-- Well, not quite the first day. At, right at the beginning, it was like, "Okay, we have no money. We have no customers. Um, how do we get some money and some customers?" And once we had not even closed our first customer, my ambitions had already sort of scope creeped to actually, what is this supposed to be?
What is this supposed to become? Like, the thesis of this, I didn't quite describe it, but it was like an enhanced, uh, IDE for documents that would help you use NLP to help you read documents faster. And that was compelling. Um, I was interested from an, from an academic use case for reading papers, but there's not really a huge market there, so we ended up selling it to law firms and financial institutions.
Um, it, uh, already at the first day though, like that, um, the idea of building like an IDE for reading was sort of indicative of my interest of like just reinventing these popular softwares that we use all the time. Um, I think there's-- I had gone through an arc in college of like being really interested in like niche robotics, like pest robotics applications.
I worked in the GRASP lab at Penn my freshman year, and then, uh, slowly got uninterested in sort of niche applications of technology, and it was like, wait a minute. The, the biggest market opportunity and the most interesting thing to do, um, maybe is not quite consumer tech, but is just like rebuilding sort of this productivity software that everyone uses daily and isn't so good.
Um, and if you look at like the two largest markets in software, uh, CRM and Office Suite now may be narrowly surpassed. I mean, in future will be far surpassed by LLM, but that's not quite software. Um, but I wanted to rebuild these, these applications. So right from the get-go, we were thinking of, okay, what is, what does it look like for you to seamlessly be able to do math, be able to do, uh, writing, reading, uh, images?
And we had this idea called Canvas, and Canvas was that everything should live on a 2D plane like Figma. Um, so like you could tie together a spreadsheet, and then it would flow into a document. The closest thing that exists is Quip, uh, which Brett Taylor sold to Salesforce over a decade ago now, and it's now, I think, been deprecated like just recently as of, uh, this recording.
Um, and So I, I wanted something like that. I loved this like 2D infinite canvas idea, so we were thinking of that. It turned out we actually fully built that as part of our seed round, um, that we raised from a16z in 2022. Sean on our team, who's still with Macro, he's on vacation right now, um, he built this whole prototype of Canvas even though it wasn't what we were selling, and that's what I demoed to investors.
It was actually terrible, and we figured that out in the process of demoing it. We didn't really say that in the demos, but like turns out like a 2D plane for-- is just like the wrong form factor. Um, but we had the idea, I think, still of like, okay, that was the wrong form factor. We learned something. But this idea of like meshing together this seamless like mind-melding workspace of all these formats is still really compelling.
That's clearly didn't work. What else is gonna work? Um, and we built a couple other form factors of, of the same idea. Um, let me step back though as to like why this was compelling to me. Um, and it's because like when you have a piece of paper, you can just, you can write, you can do math, you can-- like it's totally free form.
And as soon as you open a computer, your brain is constrained to a specific modality. You open a spreadsheet, and now you're thinking math. You open a document, you're thinking in words. And I wanted like, you know, Steve Jobs famously talked about a bicycle for the mind. Um, and you know, computers now, I can't open my Mac without ADHD-ing to x.com or fucking YouTube or something, right?
So, um, I wanted to build this thing that was actually a bicycle for the mind. That was the idea, and that's what I was hoping Canvas would be, and turned out to be the wrong form factor. So right from the get-go, we were experimenting, um, in, in this area. What we've built, by the standards that I had back then, I would consider underwhelming.
Like it turned out to actually resemble the past a lot more than I thought it would. We had to, from first principles, basically totally rebuild something completely wacky, starting with a 2D plane, and then basically land at rebuilding versions of software that look a lot like previous software, CRM, docs, et cetera, but that all really mesh together.
It's built in one database. I can talk more about the architecture, uh, later, but it ended up looking, um, a lot like the past. If you'd showed me what we built a couple years ago, I'd probably been like, "Oh, really? That's what we're gonna get towards?" But, um, yeah, we had to relearn a lot of, a lot of things from first principles in terms of product design and then also in terms of company design, um, from first principles.
But we, we ended up building a five-year arc with a detour, what I intentionally sort of like wanted to build at the beginning.
[00:09:16] Ad
Justin: Software engineering is a challenging job and it's harder when you're forced to constantly context switch. You have email in one tab, Slack in another, five different Google sheets, so many accounts to keep track of. It can feel like half the job is just dealing with organizational overhead when really we just want to be writing code.
That's where Macro comes in. Macro is a tool to cut through the noise. It's a workspace built for engineers. And it's one place for all your emails, your tasks, your chat, and your documents. The best thing is the source code's available. So if you go on a peek under the hood to see how it works, you can definitely do that.
If you want to extend it, feel free. The back end is rust and the front end is in TypeScript. It's easy to extend to make anything custom. And the cool thing is Macro will pay contributors for any features that they land. So if your team is tired of bloated project management, or maybe you're just like starting fresh and you just want one tool instead of many, give Macro a try.
It's fast, it's fun, it's a better way to build. Sign up at macro.com and get $100 off your subscription using DEVTOOLS100.
Nice. Yeah. I, I think there's, there's this interesting vein of time, uh, especially like post-pandemic where, there was like this big groundswell around tools for thought, um, which has been sort of like a ecosystem that's like jumped around for a while, and there were a lot of companies coming up. I remember, uh, Betaworks had this think camp where it was like a bunch of tools for thought, and there was a lot of them building on like Canvas, uh, you know, like features.
And, and it was the same sort of paradigm of like, how do we, you know, r-reconsider how we work with computers? And it seems like a lot of that sort of fizzled out, and then people tend to go back towards the things that are like a little bit more tried and true, like, um... And it's always interesting, you see like even things with like Obsidian, it's like somebody will go like really, really wild, and they'll build this like very ambitious setup, and then they get really exhausted and they just go back to like, "I have one markdown file that I edit."
Jacob: Yeah. I mean, sort of like Notion is a, I would say a core competitor of ours, especially with where they're scope creeping to with email and all this stuff. It's Google, Microsoft, Notion, and then the bigger competitor is just the status quo of just doing nothing and using a bunch of tools and maybe connecting them via MCP.
But the Notion and Obsidian I think is after, you know, my PhD in this area, uh, so to speak, is definitely the wrong approach. It's, it's sort of, um, it's performative. Uh, it like, it at first seems like quite useful. Um, there seems to be a whole cottage industry of content creators like helping you make this stuff work.
But at the end of the day, a domain-specific CRM, a domain-specific document editor is much better than like your second brain with tags and whiz-bang features. Um, the other problem with that industry, I think Obsidian's done a great job of staying bootstrapped and just building a good product and like probably the founder's rich from all of the $4 subscriptions or whatever, but like we had raised venture money.
My intention was never just to build like a personal brain thing and sort of the immediate tension is when you look at public comps, um, this is like why I'm glad I studied, you know, finance too, and had this part of the brain, is like you look at Coda, ClickUp, Monday, Notion, Smartsheet, you look at all these companies and they're all like $1 to $2 billion exits, which like sounds nice, maybe to somebody who doesn't know things, but like if you're talking to a VC, it's like, it's, if that's like the prize, it's not so compelling, especially now that Anthropic is at a trillion and SpaceX is at $1.8 trillion and whatever.
It's like, is this really worth doing? Like should I really fund this? Um, and like if you're building an Obsidian-like thing, it doesn't even have the potential to grow to a monday.com. Um, and there's this tension between like, you know, Notion, which Notion is trying to solve now, where you've sort of built for the personal brain market and now you're going to the enterprise market and your product can't really do both.
Um, so it ends up being a little kludgy and you're trying to serve both personas. our solve for this is dedicated modules, so like we haven't really tried to give the user endless performative sort of flexibility. We're like, I have an o- we have an opinion. That opinion is Jacob's opinion, um, on like what is good, uh, what is good when it comes to CRM, what is good when it comes to task management.
Um, you know, it's heavily inspired by Linear, Superhuman, Notion, um, and all the products that came before us. Like we, we just, you know, great artists steal, uh, or whatever the saying is. Like we just, in some things we just really grabbed it and, and our only innovation was really tightly integrating it with the rest of the suite.
Like how in an email you can click task and then you got a bidirectionally linked task to your email. You can't do that with Linear plus Outlook, for example, 'cause they're made by different companies. Um, but we've been, we've been more opinionated and have just built purpose-built modules, whereas I think, uh, other players have tried to big brain this and, and I started by big braining it too, and then brought it back down to earth.
Andrew: Do you think there was a lot of value in just like having one database and just like being the one player, uh, like in the game? like with agents, I know having one database and easy data access patterns makes like the whole f- the whole picture easier.
Jacob: Yeah, we often get that question like, you know, somewhere near the end of a demo if I'm showing somebody. We get a lot of people who are interested for their companies who don't sign up and then book a demo. Like, I have like 15 demos a week. Um, and at the end of the demo, often people ask me like, "So why should I use this instead of, you know, HubSpot plus Salesforce plus blah, blah, blah, blah, blah?"
And they list the nine tools that they're currently using at their company. Um, like what's the benefit if agents are sort of the interface layer anyways? That, you know, I'm just-- If, if everything's hooked up to the cloud, I'm never opening those tools anyways, like what's the point? Um, which is a fair question, um One, I think that we're not quite in that world.
I don't know if we ever will be, but like it still is useful to like open up your CRM and just see your deals. Um, it, it's also useful to ask Claude, but like often you just wanna get to the interface and like keyboard shortcut and then click. Like you really can't beat keyboard shortcut speed if you know the interface, um, with an LLM.
You do, you definitely want both. Um, and then like do you really want nine different proprietary siloed tools? Um, yes, you can MCP them all together, but they're all in different databases. They're all with different technologies. Uh, when Claude wants to access something, let's say Claude wants to understand the source of truth, it has to check your Google Docs and then your Salesforce and it's like, then it's trying to compare timestamps and like it's very smart, it can do this, but it's kind of every time it needs to find something doing like a CSI investigation through all of your different tools.
So we've put as much effort into the UX for agents as we have for humans, and I think sort of a lot of other companies, um, are, you know, just bolting this, this on and also maybe even worse than bolting it on, like putting limits on MCP, like rate limits or, you know, limiting what you can do because historically as a SaaS company, like, you know, you, you fund it with very expensive R&D and then you milk it for as long as you possibly can.
Um, and that's like the business model. So if anyone can take their data anywhere, then what's SaaS worth? And that's the SaaSpocalypse that you're, you're seeing now. Our, our approach is a little bit different. Our approach is what if we did everything, built it like an Apple product, like really, really well designed as a single system under one roof, not like Microsoft where, I don't know, the Excel team is in Tel Aviv and the other team's in Seattle, right?
Like under one roof. We had one project owner for per thing. So one person's in charge of notes, one person's in charge of docs, and the shared modules, you know, they, they talk to each other 'cause they're literally facing, uh, or backs to each other, but they're all in the same room. Um, so what if we did all of that, then we made it open source and then, uh, and then you could do whatever you want with it.
There were no rate limits. You know, we're gonna focus on quality. We're gonna build it in Rust. We're gonna build it in Solid. It's gonna be very high quality and we're gonna win for different reasons. Uh, we're not gonna win because we figured out how to extract value from you on our platform. We're gonna win because we're maximally open.
Um, because I continue to believe and I hope, and it's working a little bit so far, I hope over the next three to five years my thesis will play out. But like if you're choosing what system to run your business on or your personal work, but you know, if you're a solo entrepreneur or whatever, but usually your business or your team, um, I think it's gonna be a silly decision to choose to run it on, you know, 2010s era proprietary bunch of closed source, uh, tools that don't really talk to each other and made from different vendors.
Um, assuming that we can get to parity or near parity on these different surfaces, it's gonna make so much more sense to run it on, on our thing. Um- Maybe the, maybe the big labs will also compete in this area. Um, maybe they will also, like, get into the CRM market, into the docs market, I'm not sure. But, um, if they don't, I think, uh, you know, we'll, we'll be well-positioned, um, and maybe even still if they do.
And part of making open source is, like, I think it kind of, um, just like puts a pin in like the balloon. Like if there's like other-- All developers are like, "Fuck you, I can write this myself. I'm gonna write it in a weekend." But like, if you're like, "No, fuck you, I already made it open source. You, what are you gonna do?
You can't slop fork it, it's already open source." Like, uh, you know, I just... There's, there's no point anymore in being closed source. Like, people can point Fable at your thing and just say, "Slop fork it," and then it's gonna be worse. But, you know, a- at least for this core office suite, maybe there's, there's definitely still a role for some proprietary software, like on the edges.
But like the core stuff that your company uses, like the core chat, the core docs, like this stuff should be maximally open, and the other stuff on the periphery should be built around this, is my strong opinion.
[00:18:50] Open Source Strategy & Competition
Justin: Hmm. It's interesting 'cause we've kinda seen the opposite thing happening where more companies are just saying, "Hmm, we think open source doesn't make sense anymore," because, like, people can, like, swap fork or whatever, and they think it's, like, less defensible. Whereas, you know, historically it's like the source is open, but the, um, running the business is the hard part, right?
And so, like, the code doesn't matter, which probably is, is still definitely true today, right? but it is interesting that we've seen somewhat of the opposite position at different points in the industry, is like people starting to close source things or definitely getting more restrictive with licensing and, you know, a bunch of other things like that.
Jacob: I think it depends on what your goals are. Like you can't say somebody's stupid if you don't know what their intentions are. Um, if your intention is to run like a $10 million ARR business that is going to like feed your family, that's one thing. If you're trying to change the world, that's a different thing.
Uh, like, like, um, I don't know, Cal- cal.com recently sort of rug pulled, in my opinion, um,
Justin: Yeah
Jacob: after building the brand on, on open. And like they beat Calendly. I use cal.com because they were open. This is like, I think, morally wrong. Um, I don't, I don't think that's a good thing. Um, I also don't understand it. Um, but I assume that a calendar booking app can only be so big, and maybe their goals are different than my goals, and their goals are like, "Okay, we're bleeding revenue to like people just self-hosting this."
But my perspective on this, and it's a bit of a leap of faith, um, I don't know if this is gonna work. But my perspective is I would rather own a small piece of a super large pie. Like what good looks like is Macro becomes just like the default OS. Not our s- not our hosted version, but like in general, forks of Macro, you know, Amazon slop forking it and running Amazon Bedrock Macro.
You know, like just Macro becomes a standard like USB-C, um, is what good looks like. And some fraction of that ecosystem we're capturing is a much happier outcome than like, you know, the XKCD about competing standards where like we're number 17 proprietary ClickUp. Like, you know, it's, it's just, it's not exciting.
Like Coda, ClickUp, Notion, they've already tried this everything app thing. It's hard. You need all the help you can get. You need the tailwind, you need the moral tailwinds, you need the developer tailwinds. Like we need it all. We need every, every assistance we can get. And just as a-- people want you to win when you're maximally open and you're trying to build something of high quality, and they want you to lose if you're building shit.
Um, so I think the long run strategy, startups are path dependent. If we run out of money, uh, we'll run out of money. But like if we can get to a certain point where, um, where we need to be, I think it'll become the obvious sort of default.
[00:21:43] Why Macro Can Win
Andrew: So you're not the first company to try to build an everything app. I feel like I hear everything app every few days from different angles. Uh, what makes you think that Macro can be that everything app?
Jacob: Um, I have really good taste. Um, I've designed our-- Go to macro.com and look at our, our website. Um, I've directed or done most of that design. Um, I not only have good taste visually, but I have good taste when it comes to each individual block. I have thought very deeply about what makes things good. I have studied this stuff more than anyone else has studied it.
Some of that lives in Twitter and LinkedIn posts, but most of it lives in my head. Um, we've raised 30 million from A16Z, um, and we're based in either New York or San Francisco, and I think the company that does the thing is gonna be a well-funded company that, that does the thing. It's hard for this to come from, like, Poland, just structurally.
Um, I wish that weren't true and the world didn't work that way, but it's just like it's, it is the case. Um- What else? Uh, the technology. We've spent an egregious amount of time on the core technology. We have probably overbuilt. We have dogfooded this for over two years. Um, so our team of 15-ish people has, um, really, you know, kicked the tires.
Um, we use it and we've been willing to change it in ways that I don't think most companies would be willing to change it. Like, we've been willing to, you know, because our-- we've raised enough money to stay afloat for a while, we've just, like, thrown out whole iterations and gone back to the drawing board on things.
Like, for example, the top bar. The, the whole nav has changed since, like, two years ago or 18 months ago, and that involved lots of migrations and decisions that we just had to say, "Sucks. Feels bad, but, you know, let's, let's just do the migration." Um- And then we have a really great team. So we have a lot of Recurse Center folks.
Um, shout out to, uh, Nick and Sonali and those folks, the Recurse Center folks in, I think maybe I'm wrong, but I think in SF. So I think I said you have to be in New York or SF. Um, I think SF also is not SF of the '90s or '80s. It's not the, it's, it's, it... There's something about Brooklyn right now that you get a lot of like very talented, creative people that gravitate, um, to Brooklyn.
And like re- like we have what, so Peter used to be a poet, you know, Seamus, former MFA. Aiden's like a, currently doing his MFA at M- F- FIT. Then we have like our Rust guys who are just like, you know, really strange, um, and care a lot about Rust. Like, I think the team that we have assembled would be hard to assemble, um, elsewhere.
Um, so yeah, all, all of those reasons. And then the open source, nobody's tried this in an open source way. Um, and then nobody's really tried this. Let me, let me make that point when you say people have tried it. What does it mean to try? Um
I think for like actual well-funded attempts at this, uh, ClickUp has quickly gone up market. Like they got to revenue really quickly. That's 'cause they basically just built the shell of a product that didn't, each module didn't actually work super well. And then they went up market and sold it to like, you know, like Coca-Cola's marketing team or whoever, like people who don't have high taste in software.
What ClickUp never did is like win Y Combinator. Like, you know, like high taste startups do not use ClickUp. Um, Notion was very clever. They stayed very focused for a long time. Um, they did not scope creep into things like Coda, what they did with Sheets and stuff like that. They were like, "We're notes." And that I think was really important.
Um, people shit on the product for being slow. It was actually slower in 2020 than it is now. They've improved it. Like I think overall it's good, but the, the problem is that it's the wrong layer of abstraction. Uh, markdown documents, uh, in arbitrary databases are not as good as purpose-built modules for each vertical.
It's not your, you know, we, I call it the No- Notion balkanization. The whole company started on Notion and when we got to 20 people in our, before our pivot, you know, we had the sales team, the guy's like, "I want Salesforce." You're like, "Okay, you're the VP of sales. Sure, you can have Salesforce." Okay, the engineering team's like, "Ah, Notion's slow, whatever.
We gotta go to Linear." And then all of a sudden Notion is basically just for like almost nothing. Um, and so this Notion balkanization happens as the team gets beyond 10 people, and then Notion just turns into like a Confluence and it's no longer like your, your everything app. So I think nobody has tried what the approach we've tried is, is maybe part six of my answer.
[00:26:16] Go-to-Market Strategy
Justin: One, um, interesting follow-up to this is the sort of specialized tools for, like, different areas. So, Linear or Slack or, you know, maybe Notion for just docs. Um, they spend a lar- lot of marketing budget and, and, you know, a lot of product time really thinking about, like, doing their thing well. And arguably, some of them lose their way, uh, as the products develop.
But, you know, the, the, the point still stands. They become known for the thing, right? Like, Slack is kind of known for the place that you go for work chat, you know?
Jacob: Mm-hmm.
Justin: And competing against all of those markets with, a, a sort of like unified interface is a little bit challenging just because, like, you don't have the mind share in each of those verticals.
So how do you think about, like, go to market, just like getting people to convert and switch over, um, maybe some of the platforms that they're already using? I, I know in your, your docs section, you have, like, this, like, really good, like, switch from, like, switch from all these products. Um, what is that story like for y'all?
Jacob: I think the, the pitch of unification, um, to an early stage founder is like, "Okay, I get to save some money." And to a late stage founder, which I had a demo with a, a 500-person company I didn't realize 'cause I, I, I clearly need more OpenClaws. I got zero OpenClaws and zero Mac Minis over here, so I need more OpenClaws that are doing research before my calls with my Hermes Pi agents or whatever the fuck that is.
But, um, you know, I show up to the call and the guy's like, "Oh shit, there's a 500-person company. You're the CEO. That's cool." Um, that's happened multiple times over demos the past few weeks. Um, so the pitch, why that resonates with late stage founders is that it's like, "Oh my God, I have no idea what's happening at my company," right?
Um, everything is all over the place. I have no visibility. Um, and yeah, I can sort of like get an agent to go through everything, but still, like I gotta log into 27 different things. Like it's, it's a great promise. Um, actually switching after that is hard. So we've, you know, transparently we've lost, not even lost the deals, just like after the discovery call, the pitch lands.
But switching from these things is hard, right? If you already have all this stuff, um, even if you dislike Slack, if you have so much history on Slack, you, you know, are you gonna get everyone to move over? Um, similarly, like the organizations that were on Microsoft Office in 2008, they didn't move over to Google.
Like none of the New York banks have moved over to Google. The organizations that run Google are the organizations that got started since 2008, right? Like it's just, it's new, it's greenfield, not brownfield. Um, I think Macro will be a similar story, but Macro is not really positioned as an office suite.
It's positioned as a unified system. Um, so we're happy for you to bring your Outlook email, your Google email, and I think this, this opportunity to do category creation is, uh, enabled because of, of, of AI. Like, I couldn't have done this in 2022, even 2023, especially not 2021. But like now is the right moment.
Like you see YC put out a request for startups for like Company Brain or something, which is adjacent and related and one component of what we're doing. Um, but there's-- the AI wave gives a, from a marketing perspective, the, the raison d'etre to, for the why now story. Um, so does that answer your question?
Justin: Yeah, I think so
[00:29:33] Tech Stack: SolidJS Frontend
Andrew: Cool. So let's move on to talking more about the tech behind the product. Uh, so I'll start with the front end since I'm more of the front end guy. Uh, you guys chose SolidJS over React. Uh, in a world where AI writes most of the code, it seems, uh, interesting to me to not pick just, like, the most popular thing.
So why did you guys go with Solid, and have you seen benefits from it?
Jacob: I don't know if that was necessary, but it was sick. Uh, we had a whole React-- Not only did we build it in Solid, we rewrote it in Solid. Uh, we had a whole React code base, big code base And when we're, um, we, we were at the time not building, uh, we were trying-- So it wasn't a hard pivot. I wasn't like, you know, "Screw this prior thing."
We, we were at one and, about one and a half million in revenue and serving finance law firms, and I sort of had this idea that we could serve both, um, both, both, uh, like build what I want and also serve our existing customers. So we actually started by building a word editor. Uh, Chase Coleman, brilliant former engineer on our team, built a word editor in a browser using LibreOffice, if you know that software package, and he got it to work in WebAssembly.
And in the process of doing that, the overlays on top of this WebAssembly, you know, rendered down to a canvas document view or the overlays for whatever reason, according to Chase, unclear to me if this is true, but he said that the Solid rendering engine was better for, for that. So we had this sort of chimera of a solution where everything was React except the popovers for this overlay, which were Solid.
And then that somehow scope creeped to more and more and more Solid spreading, you know. And then eventually the Solid had like metastasized to like other packages and, and then we're like, "Fuck, all right. Everyone's kind of liking this Solid thing." You know, this is back when people wrote code. You remember back when people wrote code?
Um, so everyone was liking the Solid thing, and so we switch, we switched to Solid. And at that time it was before React 19 or whatever it is that, you know, got a little bit faster. So I think, I think there still is a diff, at least according to Solid's landing page. Um, but speed was a, it was a compelling reason, uh, to do it and, um, you know, no virtual DOM and, and all of that stuff.
Uh, are we happy with the decision? We should probably write a blog post about this. I mean, now two years later from that decision, there's a lot of stuff that we've reinvented the wheel because the ecosystem for Solid is just not as good. But now who cares? Because you can just slot fork the React stuff into Solid.
So, you know, with Rust, same, same story. Um, you know, with Rust or, or with, sorry, with, um, with our mobile app, we've done Tori. So Tori is, you know, cross-platform how we've nativized things. Um, and with Tori, like we needed to get our, our macro calls, um, working, uh, through iOS calls. So like you actually want like a proper, like WhatsApp does this too, where you get an actual like phone call looking thing, and you need to do a bunch of Swift for that, and we don't have a Swift guy.
So, you know, we just slot forked a whole bunch of Capacitor plugin into Tori to, to do this, um, with Mythos or whatever it is. So, um, I think with AI you kind of want to choose the fastest solution, which on the front end for us is Solid. I mean, I guess you could just do plain JS, but like Solid and then on the back end, uh, is, is Rust.
E- especially like we made these decisions, um, pre-AI, but I think with AI they've, they've been even better design decisions. Um, we haven't realized all the benefits of these decisions yet because there's still some, you know, random like normal snafus with, uh, like speed is very rarely due to the framework and very often due to other bullshit that just creeps into the code base.
Like we're fetching too much stuff, TanStack's doing dumb stuff, you know, things like this. Like, so any slowness now is caused by that, but I think the peak performance, which we are hopefully close to getting to, will be faster than you would be able to get in other competitors. Um, will it be noticeable?
I don't know. Um, but I do think part of our value proposition is being extremely well-built. Like for us, this is the platform, um, for the future, assuming the form factor of laptops and mobile phones stays. I mean, we're-- if it doesn't, I, I, all bets are off. But assuming laptops and mobile phones stay, like I'm confident that Macro will stand the test of time.
Um, so yeah, that's, that's why we chose Solid
[00:33:45] Tech Stack: Rust Backend
Justin: Maybe to build on that, um, so you, you already mentioned you're using Rust as a backend. Um, a lot of startups when they're starting out, they just choose the most expedient technology to move as fast as they can. Um, Rust is not necessarily that unless you really know what you're doing. So I'm curious about like both the experience.
I'm assuming that the, the big part of this is performance, but the experience of like why you chose Rust and then how that has like played out over time and any challenges that you're running to, if any, at this point.
Jacob: The biggest difference that I notice is the culture that we have at the company and the types of people that we've hired. Um, like the l- the choice of language, uh, one effect is how fast the code is, but, you know, that's dominated by other effects, which is how well you wrote the code, whate- whatever framework language you chose.
Um, the second one is like the ecosystem that you get or don't get. But like the bigger one is the kind of people that you hire. And for us, like we had, we would've just had a totally different company. I would've been looking out at different faces here if we had chose like TypeScript for the backend.
Like Sean, who started at Macro, left to go to 1Password 'cause he wanted to write Rust, came back to Macro because he heard we were now writing Rust. Um, you know, like Hutch has been here for four years 'cause he loves writing Rust. He loves building great performance systems. Like if you choose TypeScript or whatever you wanna choose, like, you know, it deeply affects the kind of people that you hire.
And, um, we have a bunch of people that really care about quality. They, um, maybe are having a little bit of existential despair because their sense of self-worth is tied to being great engineers. Um, and that's changing now of what that means. But people, I think, are refinding their footing now, maybe more so than in January or February.
Um, but yeah, it, it's, it reinforces our commitment to building a, a great, fast, performant long-term product
Justin: Yeah. That's, uh, I found that to be true. Like, language definitely shaping the culture of the company is a big thing. Um, this is a, this was very true for Oxide when I worked there. I mean, they're all in on Rust, and the kinds of system engineers that you attract, uh, with that is, um, not to be discounted by any means. maybe talking about, like,
[00:36:10] Real-Time Collaboration
Justin: another area of this that's hard, which is the sort of like interface between these two systems. Um, so you're building this, like, multi-module collaborative interface for running your business. Um, and I mean, that sort of key word, like collaboration, is gonna be like really key here.
So you have documents. You need multiple people to edit the documents at once. I'm sure that once you build that functionality, you're like, "Okay, where can we reuse this in other places, like this core capability?" but that's also, like, it's not an easy thing to do. Um, so what has your story been about, like, trying to tackle real-time collaboration, and how do you think about, like, where, what is a collaboration functionality we add in one module?
Is that something we can take to another? And like, I don't know. How, how have you been
Jacob: great question. Yeah I don't know the full details 'cause T.O., our CTO, is the one that actually built this when he was-- he still does a lot of IC work now, but when he was just an IC, um, before. Uh, but, uh, Loro, CRDTs, um, and Cloudflare durable objects are the buzzwords that, that I, I know, and I don't know, uh, too much more than that.
Um, other than why, why did we decide this to, to roll it ourselves is something that I can speak to versus use like TipTap or TipTap? I don't know. One of like these open source editors. So we built it on top of Lexical, like we didn't build the text editing framework ourselves, and that Lexical text editor is used in the markdown block.
It's used in the task block, which is basically a f- a fork of the markdown block. It's used in the input area in channels like, uh, like the input box. It's used everywhere basically. And then the @ mentioning system, so the nodes in that lexical are used everywhere. So this is what powers one of our core, you know, value adds, which is that everything links together bidirectionally, and that's 'cause you can @ mention things.
So in Notion you can @ mention docs. In Macro you can @ mention the whole graph of your entire company, whether that's an email, a customer record, a task, whatever. So that makes everything really tightly integrated. And then how sharing works, building on top of this, is let's say I @ mention a task and I send it to you, Justin, in a channel.
If I've just @ mentioned something in a channel to you, you ought to have access to that thing, right? Um, and so instead of having a separate sharing system, you know, like when we'd have Notion, I would share it in Notion or share the Google Doc, but then I don't trust that you received the email from like Google that the Google Doc was shared.
So I'm also gonna send you the link in Slack. So like now you got two ways to access it, when really I should have just sent you the link and it should have auto-shared. And I think there's some kind of Slack bot that might do this, but it doesn't work for everything. It doesn't work for Figma and so on.
So like in Macro when you mention something, all the permissions cascade. I call that channel-based sharing. And we actually threw out our v1 of the sharing system in order to do channel-based sharing, um, because we had this weird thing where you would share it and then you'd still send a link. And I was like, "Guys, this is one of these perfect opportunities for-- it's a perfect sort of abstraction.
There's bad abstractions, good abstractions, bad concept unification, good concept unification. This is a great example of how we can unify things and make things awesome." So like if I share something in the, uh, Macro channel or engineers channel, and then you leave the company, because you're no longer in that channel, you no longer have access.
So it, it just, it works really well and it all sort of, you know, this is how things build on top of each other, these concepts like Lego, and why unification actually makes your, your day more seamless than all these separate tools that don't work together. Um, but anyways, yeah, all of that, all of that can, can work collaboratively.
Um, the diagrams that we have, uh, we have not turned on. It's gonna use the same CRDT engine, uh, and the whole collaborative synchronize. We call it a sync service if anyone wants to search the repository for how it works, uh, 'cause it's all open source. Um, but yeah, it's built on top of Loro. We had to contribute to, to Loro and, uh, T.O.
contacted the Loro guys. They were gonna do some work for us. They didn't end up doing work for us. We're doing it internally and now Wolf, uh, another recursor is working on full local first, uh, markdown editing and instant loading. I mean, our eventual goal is that this should all be mirrored onto the local system, um, so that Claude Code and other agents, um...
There's kind of this weird-- We're in this weird place where like I can do so much on my local machine with Claude Code, but then none of it's collaborative. Like it can make me a PowerPoint deck or whatever, then I can't collaborate on it or like, you know. So I want Macro to be like a Turing complete POSIX, um, you know, version controlled, uh, which in some aspects it already is, system.
Like imagine if your entire workspace was version controlled and, and sort of POSIX compatible. Um, this is more medium to long term, uh, maybe faster now with Mythos, but like this is what we're working towards, is that your whole company, the whole-- all the people that work here, all of your agents are in the brain of, of one computer.
Uh, and all of that's just sort of versioned and computable and there's not this like weird, um, sort of, uh, like chasm between my local machine and, and remote
[00:41:03] AI & Agents Integration
Andrew: Um, so that's a great transition into talking about AI. We've mentioned it a bunch of times during the podcast. It's probably changed the complete face of your company. Uh, but how has it, like, how have you guys integrated agents into the product? Uh, I, I see mentions of memories throughout the marketing pages, and I could see how that'd be really useful, but, like, how is that represented in the system?
Jacob: Yeah. So the benefit of have doing everything in one place is unified memory. So unified memory is one of those good concepts. We invented some bad unified concept, but unified memory really stuck. So if I open my memory in Macro now, or I just ask the agent, "What do you know about me?" You know, Claude or ChatGPT creates memories.
I think it's daily on a cron job they do now. They sort of do dreaming is the new jargon that's been emerging. Um, so when Macro dreams, Macro doesn't just dream about your chats that you've had in the past day. Macro dreams about the emails that came in. It dreams about all the team conversations. It dreams about the tasks to create that team level memory.
And then the tool surface is co-designed across, um, across everything. So, you know, of course you can MCP everything together, but like the agent in Macro has one search tool. It's not like, oh, I'm gonna go search Linear now. I'm gonna go search Notion. I'm gonna go search this. I touched on this earlier in this pod.
Um, but like it's just search and then it can pass in the arguments of which modules it would like to search or just leave it open-ended. And then you as the user, you know, good old-fashioned human can also search across all of these, all of these different modules. Um, so that's a benefit for, it, it is actually a pretty real benefit for, for agents and humans.
Um, there's some things that we're missing that I, that I want to get to. Um, like we have cron job agents, so you can set up recurring automations in Macro. Like I have one that asks me, you know, comes in with what the team is doing every day and anything that I've delegated that hasn't gotten done, it reminds me that I've delegated it.
So I have a couple useful things like that. It's not full OpenClaw style yet. So like OpenClaw style is like one thread, uh, and you know, just on a heartbeat. So there's kind of two patterns that are emerging. One is like the heartbeat pattern where it just sort of manages itself, and then the other is like, you know, um, more sort of, uh, like discrete automations that you set up that run on a specific cron job.
Um, I think we want both. We've been debating whether to just do heartbeat 'cause it theoretically sort of works, but the problem with heartbeat is like if the heartbeat is every 15 minutes and you want a thing that, uh, runs on, you know, let's say a bad customer email comes in and that should be a kickoff for something to happen, you don't wanna wait for the heartbeat.
So like you kinda want a mix of both systems.
Justin: Yeah. It's really fascinating. Um, haven't really seen or at least heard of, like, integrated memory systems. I, I'm sure that, like, other folks are doing it, but I mean, it's interesting because you have, like, an agent's interface, like, built into your app. So, like, building that unified memory layer, helps because it's like, it's not just, like, what you're chatting with, but the whole system, which is kind of fascinating. Um, maybe sort of a follow-on question to that. Uh, I've seen in a lot of companies there's this tension between, like, building sort of this, like, internal agents or agent as, an agent as a product interface. You're building a chat with an agent that you're, like, wrapping a harness around, versus, like, external integration with, like, Claude Desktop or ChatGPT or Codex or Cloud Code or whatever. it's not sort of an either/or, but when you're thinking about investing in, like, what is the product surface for agents that we build versus, like, what is the sort of external, um, interactions that we build, how do you sort of, like,
Jacob: Yeah
Justin: and weight do we wanna take this on ourself versus just, like, let the labs have it?
Jacob: Well, it's a little depressing, right? If you don't get to be an AI company and you're just a depreciating wrapper company that is like kinda offering a user interface and a database, and you're just like, "Okay, yeah, we'll just offer the MCP. They can do all the cool stuff, and like eventually our product surface is just gonna be subsumed by their chat interface."
Like, what's the point? What are we even doing, right? Um, so I think that attitude pushes you towards like doing stuff internally, like making the Slack AI and then putting limits on the MCP leads to that kind of corporate behavior. But what's best for the user is the opposite. What's best for the user is that it's maximally, maximally open, right?
Um, part of the downstream effect of being open source is that we can't be evil. Um, like Google says, "Don't be evil," and then continuously has to reinforce not being evil. Um, when you're open source, you kinda made the decision once and now you can't really be evil again because it's open source. Um, so you know, we're doing both.
We're making great internal agents. People have asked for BYOK, bring your own key or bring your own agent into Macro. I wanna bring my Hermes, bring my Bing Bong agent, you know, into Macro. I want to @mention Bing Bong and have him go do stuff. It's like, you know, if we were closed and sort of in that mindset, maybe we'd be like, "Fuck, well, but from a revenue perspective, we wanna be like Cursor.
We wanna be charging, you know, on top of the tokens so that we can say we're an AI company and then, you know, we get to make the inference margin, whether that's 10%. Turns out that it's more like minus 20%. Um, but like, you know, in the future, maybe we're gonna be able to clip a 5 or 10% inference margin, which is gonna be huge.
It's like, uh, you know, it's like being labor. Uh, all the VCs are saying we're gonna displace labor. Maybe we get to be labor I don't know. I think you just have to make the product that people-- Like for us, we're in-- It's, it's nice to be in an underdog position. It's nice to be open source. It forces us to make the thing really good.
Um, like you are going to migrate to Macro or you're gonna use Macro for your next business or whatever because it is just such a better and more open alternative than all this proprietary other stuff where incentives like these arise and make the product worse over time.
Justin: I do think you have a special position too, 'cause it's like you were mentioning earlier, it's like, when people are thinking about building an agent in their product or, or not, it's like the ones that don't and leave it to the labs end up like making Slack integrations and other things. Because like a lot of it is like they're still trying to go where the customers are. You know, they're trying to put like integrations into the tools that they're already using, but like you are the tools that they're already using, right? That's like, that's your whole point. So it's like you're also uniquely positioned, um, maybe even more so than like a place like Linear who's like had sort of fantastic success with their agents integrations, but like they also have to have this sort of third party like integrations into all these places where people are doing work and you're like, "Well, actually we kind of control all the surfaces."
So like having this the place where you use agents like makes sense in the same way it's makes sense to have this be the place that you use email,
Jacob: I really respect Kerry and Linear. It's like, it's brilliant. It's, uh, on a spectrum of like Linear to Notion to Smartsheet.com. They're the first name I mentioned 'cause they're the Apple-level quality. They are s- make it s- build it slow, uh, anti-996 or whatever. Like, just like, "Let's build, let's just make this good."
Um, and they, and they did. But they also face a little bit of an innovator's dilemma where, um, they have their existing product, um, they don't own all the surfaces, and I, we, I'd be surprised if they make it open source. I guess there's nothing strictly prohibiting that. But like, you know, they're at 100 million in revenue and, and we're not.
Um, so it's a pretty classic innovator's dilemma situation where they actually have something like a, they have a real legit business, whereas we can sort of rethink what it means to do that in 2026.
Justin: Yeah, for sure. They're a great product. It's just, like, interesting the, the, the different incentives you have because of the shape of your product
[00:48:41] What's Next for Macro
Andrew: So looking towards the future a little bit, uh, you guys have accomplished a lot. The product already does a lot. The, the marketing pages look amazing. Uh, but what are you guys working towards next? What's the big milestone?
Jacob: Make the marketing pages more amazing. Um, the homepage took me about a year of, uh... That was because it was-- I mean, the other pages won't take that long, but like Building a brand that is both unique and good is hard. You kinda have to choose one or you have to put in a ton of money. Um, so we hired the agency, they're called Paper Crowns.
They-- believe they did the latest, like, Black Ops. They've done Ninja stuff. They do a whole bunch of gaming stuff. And then we hired three different artists internally and our existing guys. And then I just learned a whole bunch about fonts. And then it was just... It was the weirdest thing for a s- company of our stage for me to do, but I just, I just really felt like I had to do it.
And one night I landed on this slab serif pairing of this futuristic Rajdhani sort of font and this slab serif, and that sort of flowed through with other stuff. I spent months. I don't think the team knew what the fuck I was doing. Um, I think it, I think it's pretty good, but there's still more to do.
I've sort of put it to the side to focus on other stuff. I could spend so long just thinking about fonts. Um, but, uh, yeah, more marketing, more, uh... The documentation was nonexistent 10 days ago, so all of those docs that you see there I've wr- I've written, uh, with some help from Julia on my team and from Fable.
Um, but making the docs really, really good. Um, if you really interrogate them, I think you'll find some holes. So I want brilliant documentation. And then on the product side, we're about to fully release CRM and then pull requests in Macro. Uh, so just, you know, full on, uh, integrated with tasks. Let them like imagine customer email comes in, that's in the email client, boom, to the ticket, boom, to the agent, boom, to the PR, all that in Macro, uh, with, with shared memory.
So that's exciting. That'll be the coding surface and the sales surface. That's the sales part's, uh, about 80% done. Uh, it's flagged on in dev, and we've been playing around with it. And then after that, we have most of the surfaces that I want, um, that are, like, high value. So it's just about making it really fast.
Like, our mobile app can use a little bit more work, um, to be really fast. The local-first stuff will, uh, you know, offline will be great. Um, building an SDK. We're open source, but it's still actually... We need to make it easier to build on Macro. Slack has, like, a great marketplace and sort of, you know, all this stuff, despite them sort of being closed in, in ways that I mentioned.
Like, they have made it easy to build on top of Slack. We're gonna make it super, super easy to build on top of Macro. Um, so plug-in SDKs, all that stuff, and then just evangelizing it. I mean, I'm here today. I would-- if you guys have more ideas on how to do it. But I think a lot of, you know, today it's about distribution, not just about, about product.
I do think people underweight how much product is still important. Like, we have 15 people grinding really hard, plus all their agents on, on this product. Um, and obviously the surface has expanded. This problem that we're tackling was just simply intractable, uh, two years ago. I'm glad I got started and didn't know it was intractable, but in hindsight, without these coding agents that we've got, it would've been intractable counterfactually if we hadn't gotten AI.
And I-- that was just lucky. I didn't really foresee exactly this trajectory happening on the timeline that it did. Um Yeah, just making everything really g- really, really good. Um, and then waiting and marketing it and seeing what happens
Justin: Are y'all gonna build a calendar?
Jacob: Uh, we really need to build a calendar. Uh, we, we-- I slopped-- There's a PR up. I built a calendar, but it's not, uh, it's not very good. So Evan is, uh, I think he's out hiking in British Columbia this week, but once he's back next week, we're gonna take a look at that and, uh, do calendar. We're-- We also just got unified inbox done.
So Superhuman, great product. I used it for like six years. Um, it's heavily inspired-- Or e-email and macro is heavily inspired by Superhuman. Um, but what Superhuman doesn't have, because to my understanding, they use the Gmail API, which doesn't nicely allow sort of multi-account fetching. Whereas what we do is we actually backfill all of your emails from Gmail into our database so we can splice and do whatever we want.
That's how we can do email sharing with our CRM is 'cause we own, we have all your email, um, in, in our database. Of course, it's SOC 2, HIPAA now, and all this stuff. But, um, so what we can do with that is what Superhuman didn't or could not do, which is, uh, multi-inbox. You know, not rocket science, just like I, I wrote a post about this, about how, you know, Front.com tried.
Like there's so many different ideas when it's come to email clients. Nobody's put it all together in the way that we're putting it together, which is surprising 'cause there's been so many attempts, but like lots of different ideas from different places that, that have been good. So we're about to fully ship.
It's, it's, uh, worked. We have it flagged on just for our team, but we're about to fully ship multi-inbox for email, which I think will be great as a reason for people to use this in- instead of Superhuman. Um, yeah, basically scope creeping all of our surfaces towards best in class for each block type, right?
Like Salesforce is a big, big freaking product. Um, you know, 20CRM is like trying to be an open source version of that. We're obviously doing a lot of other stuff. Evan's, Evan and Fable are cranking on CRM block. Um, you know, we're, we're basically at parity where with Linear was last year, but Linear's keeps adding new stuff.
Like, so we're just making sure that every block is actually, you know, asymptotically approaching best in class or, you know, plus or minus a couple features, uh, with, with the, you know, competitor in that space.
Justin: Awesome. you've done a lot of great work. It's pretty cool to see it develop. Um, and you know, this is a hard but very respectable thing to tackle. I mean, trying to, to solve all the problems of a business is-- or all the problems of like collaboration within a business is, uh, is, it's a fun challenge.
Jacob: Yeah. It's a, it's a lot of fun to build. It's-- The only time I've had more fun was when I was making a video game, um, in college. It was like a multiplayer, physically simulated, Skyrim-inspired, um, magical fighting game. Um, other than that, this is like the most fun I've had 'cause like we're, we're, you know, play testing it every day as a, as a team.
Justin: Nice
Andrew: Sweet. Well, that wraps it up for our questions. Thanks for coming on, Jacob. This was a, a fun dive into all things macro. It looks like you guys have built a really cool app here, and it boils the ocean and boils it well. So thanks for coming on and tell- telling us about
it
Jacob: Yeah. Awesome. Thanks, Andrew
Justin: Yeah. Thanks, Jacob. Uh, excited to see what you're building, and, uh, y'all have, like, a fantastic team. So many great recursers there. Um, yeah, can't wait to see where y'all go next
Jacob: Thanks, Justin