Jacob Beckerman - Macro

Speaker A: I call it the Notion Balkanization. The whole company started on Notion. And when we got to 20 people in our before pivot, you know, we had the sales team. The guy's like, I want Salesforce. You're like, okay, you're the vp, Sales. Sure, you can have Salesforce. Okay. The engineering team's like, ah, Notion's, uh, slow. Whatever. We got to go to linear. And then all of a sudden, Notion is basically just for, like, almost nothing.

Speaker B: Hello. Welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host, Justin.

Speaker C: 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. I want to talk about the story of how y' all got that. Um, but Macro is sort of a universal workspace for people doing sort, um, 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'm kind of framing it like Google Workspace and like Slack and sort of all this stuff, like, combined and together. You all even have, like a CRM 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?

Speaker A: Yeah, sure. Um, Jacob? My, uh, background's in computer science. Um, from like, uh, early teenager, I was obsessed with robotics and video games. And that led me to, uh, Penn, where I started as an electrical engineer, switching to computer science and, uh, finance, and spent a lot of time hacking on various projects. Macro was one of them. And now I've spent the past sort of five years, uh, building various things in this corporate entity. 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.

Speaker C: So that's exciting.

Speaker B: So you started out as an investment logic engineer. I want to know what that is first. What does an investment logic engineer do?

Speaker A: Yeah, so I was. That was between my undergrad and master's in nlp. So I was doing some NLP work. Um, that turned it to, into grad school. Um, and when I worked at Bridgewater, it was just, um, 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, I used to be just obsessively read everything I could, um, about. About investing. Um, and 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. Because half the job I was writing, um, code in an ide, and then the other half, just for my own personal interest, was in Adobe Acrobat reading documents. 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.

Speaker C: Nice. Nice. And Macro, before it was Macro was called Coparse. Is that correct?

Speaker A: Coparse. It was the only$7.com that we could buy and I had no money. And so we were looking for. Because Paul Graham says if you don't have the dot com, change your name. I don't know if you've seen that article from.

Speaker C: Yeah, yeah.

Speaker A: So, you know, we wanted a dot com. And I like the idea of like, parsing documents. So that was, that was the idea. But as soon as we could, we, we got Macro dot com.

Speaker C: Yeah, it's, um, interesting to talk about that, like, evolution. So you sort of talked about this, like, thinking about, like, PDFs and, um, like, document, like how you interface with the document and how you maybe edit and read them to this, like, full workspace that you have today. Um, when did you start that transition of like. Well, actually I want to do more than just like, you know, editing PDFs or like, reading PDFs. I kind of want to, like, build more into this, like, idea, larger workspace. What was your transition there?

Speaker A: Yeah, two different things. Right from the first day, day that I had started macro, I. Well, not quite the first day. And 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 there's like an enhanced, uh, IDE for documents that would help you use NLP to help you read documents faster. That was compelling. Um, I was interested 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, already, uh, the first day though, um, the idea of building an IDE for Reading was sort of indicative of my interest of 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. I was like, wait a minute. 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 maybe 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 applications. So right from the get go we were thinking of, okay, what does it look like for you to seamlessly be able to do math, be able to do, uh, writing, reading, ah, 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, um, which Brett Taylor sold to Salesforce over a decade ago now and is now I think been deprecated like just recently as of uh, this recording. And so 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 a 16C 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, uh, in the process of demoing it. We didn't really say that in the demos, but turns out a 2D plane is just 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 meshing together, this seamless mind melding workspace of all these formats is still really compelling. That's clearly didn't work. What else is going to work? Um, and we built a couple other form factors of the same idea. Uh, let me step back though as to 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 adhding to x.com or fucking YouTube or something, right? So, um, I wanted to build this thing that was actually a bicycle for the mine. 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 this area. What we've built by the standards that I had back then, I would consider underwhelming. 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 he showed me what we built a couple years ago, I probably been like, oh, really? That's what we're going to 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 ended up building a five year arc with a detour. What I intentionally sort of wanted to build at the beginning.

Speaker C: Software engineering is a challenging job and it's harder when you're forced to constantly context which you have email in one tab, Slack in another. Five different Google sheets. So many accounts to keep track of. Uh, 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. 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 Want to 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 in 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@macro.com and get $100 off your subscription using DevTools100. Nice. Yeah, I think there's this interesting vein of time, uh, especially like post Pandemic where um, there's 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 Betaworks, uh, 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, features. And it was the same sort of paradigm of like how do we re consider 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 is 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 added.

Speaker A: Yeah, I mean sort of like notion is ah, I would say 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, just doing nothing and using a bunch of tools and maybe connecting them via MCP M. But the notion in 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. It like 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 is 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 one to $2 billion exits. Which like sounds nice, maybe 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 super 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? Should I really fund this? Um, and 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 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, 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 just, you know, great artists, Steel, 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 because 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 I started by big braining it and then brought it back down to earth.

Speaker B: 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, the whole picture easier.

Speaker A: 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 in further 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 of. Agents are sort of the interface layer anyways that, you know, I'm just, if, if everything's hooked up to claw and I'm never opening those tools anyways, like, what's the point? Um, which is a fair question.

Speaker B: Um,

Speaker A: one, I think 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's also useful to ask Claude, but like, often you just want to get to the interface and like keyboard shortcut and 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 MVP 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 fund it with very expensive R and 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 SaaS apocalypse that you're, you're seeing.

Speaker C: Now.

Speaker A: 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 talk to each other because they're literally facing 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, uh, and then you can do whatever you want with it. There were no rate limits. We're going to focus on quality. We're going to build it in rust, we're going to build it in solid. It's going to be very high quality. And we're going to win for different reasons. We're uh, not going to win because we figured out how to extract value from you on our platform. We're going to 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 going to be a silly decision to choose to run it on, you know, 2010's era proprietary bunch of closed source, uh, tools that don't really talk to each other, made from different vendors. Um, assuming that we can get to parity or near parity on these different surfaces, it's going to make so much more sense to run it on our thing. Um, 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 going to write it in a weekend. But like if you're like no, fuck you, I already made it open source. You, what are you going to do? You can't slot 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 going to be worse. But you know, at least for this core office suite, maybe there's, there's definitely still a role for some propriety 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.

Speaker C: M It's interesting because we've kind of seen the opposite thing happening where more companies are just saying we think open source doesn't make sense anymore because people can slot torque or whatever and they think it's less defensible. Whereas historically it's like the source is open but um, running the business is the hard part and so the code doesn't matter. Which probably is still definitely true today. Right. Um, but it is interesting that we've seen somewhat of the opposite position at different points in the industries. Like people starting to close source things or definitely getting more restrictive with licensing and a bunch of other things like that.

Speaker A: 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 dollar 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. Like, like, um, I don't know. Cal.com recently sort of rug pulled in my opinion. Um, yeah, 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 going to work but my perspective is I would rather own a small piece of a super large piece. Like what good looks like is macro becomes just like the default os. Not our, not our hosted version but like in general forks of macro, you know, Amazon slot forking it and running Amazon bedrock macro, you know, like just macro becomes a standard like USB C. Um, 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 were 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.

Speaker B: 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. What uh, makes you think that Macro can be that everything app?

Speaker A: Um, I have really good taste. Um, I've designed our. Go to macro.com and look at 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 have raised 30 million from a 16Z um, and we're based in either New York or San Francisco. And I think the company that does the thing is going to be a well funded company that does the thing. It's hard for this to come from Poland. Just structurally. I, um, wish that weren't true and the world didn't work that way, but it's just like 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 dog fooded this for over two years. Um, so our team of 15ish 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 uh, 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 whole nav has changed since like 2 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 Recur center folks, um, shout out to uh, Nick and Sonali and those folks, the Recur center folks. And I think maybe I'm wrong but I think in sf, so I think I said you have to be a New Yorker, SF, um, I think SF also is not SF of the 90s or 80s. It's not the, it's, it's, 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 we have. So Peter used to be a poet, you know, Seamus former mfa. Aidan's like currently doing his MFA at M 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've 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 tried it, what does it mean to try? Um, I think so like actual well funded attempts at this ClickUp, uh, has quickly gone up market. Like they got to revenue really quickly. That's because they basically just built the shell of a product that didn't, each module didn't actually work super well and then they went at 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 go creep into things like coda what they did with sheets and stuff like that. They were like where 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 it's the wrong layer of abstraction. Markdown, uh, documents, uh, in arbitrary databases are not as good as purpose built modules for each vertical. It's not. You're, 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 pivot, you know we had the sales team. The guy's like I want Salesforce. You're like okay, you're the vp Sales, sure, you can have Salesforce. Okay. The engineering team's like ah, notion's uh, slow, whatever, we gotta go to linear. And then all of a sudden Notion is basically just for like almost nothing. 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 you're everything app. So I think nobody has tried with the approach we've tried is maybe part six of my answer.

Speaker C: One. Um, interesting follow up to this is the sort of specialized tools for like different areas. So um, Linear or Slack or you know maybe Notion for just Docs. Um, they spend a lot of marketing budget 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 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. And competing against all of those markets with um, 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 know in 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?

Speaker A: 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 500 person company. I didn't realize because I, I, I clearly need more open clause. I got zero open clause and zero Mac Minis over here. So I need more open clause 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 at 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 know, are you going to 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 had 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 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 raison d' etre for the why Now Story. Um, so does that answer your question?

Speaker C: Yeah.

Speaker B: Cool. So let's move on to talking more about the tech behind the product. Uh, I'll start with the front end since I'm more of the front end guy. Ah, you guys chose Solid JS 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?

Speaker A: I don't know if that was necessary, but it was sick. Uh, we had a whole React. Not only did we build in Solid, we rewrote in Solid. Uh, we had a whole REACT code base, big code base. And when we're, um, 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 were at 1 and about 1 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, 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 that. So we had this sort of chimera of a, uh, solution where everything was reacting to, except the popovers for this overlay, which were Solid, and then that somehow scope creep to more and more and more Solid spreading, you know, and then eventually the solid had like, metastasized to like, other packages. 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 switched, 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 compelling reason, uh, to do it. And, um, you know, no virtual DOM and all 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 Forth the react stuff into Solid. So with Rust, same story. Um, with Rust or, um, with our mobile app we've done Tori, so Tory is cross platform how we've nativized things. Um, and with Tory, we needed to get our macro calls working, um, uh, through iOS calls. So you actually want a proper WhatsApp does this too, where you get an actual phone call looking thing and you need to do a bunch of Swift for that. We don't have a Swift guy. So, you know, we just slot forked a whole bunch of capacitor plugin into Tory 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 Rust. Especially like we made these decisions, um, pre AI, but I think with AI they've been even better design decisions. Um, we haven't realized all the benefits of these decisions yet because there's still some random normal snafus with. Uh, 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, tanstacks, doing dumb stuff, things like this. 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, if it doesn't, all bets are off. But assuming laptops and mobile phones stay, like, I'm confident the macro will stand the test of time. Um, so, yeah, that's why we chose

Speaker C: Solid, maybe to build on that. Um, so 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, and Rust is not necessarily that unless you really know what you're doing. So I'm curious about both the experience. I'm assuming that 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.

Speaker A: 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, the choice of language. 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, 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 have just had a totally different company. I would have 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 because 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 because he loves writing Rust. He loves building great performance systems. Like if you choose Typescript or whatever you want to 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 refining their footing now, maybe more so than in January or February. Um, but yeah, it reinforces our commitment to building a great fast performant, long term product.

Speaker C: Yeah. Ah, I found that to be true. Like language definitely shaping the culture of the company is a big thing. Um, 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 not, um, to be discounted by any means. Um, maybe talking about like 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 keyword like collaboration is going to 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. Um, 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 you think about, like where. What is the 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 thinking about that?

Speaker A: Yeah, I don't know the full details because to 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 as something that I can speak to versus use like tip tap or dip dap, I don't know, one of like these open source editors. So we build 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 using the task block which is basically 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 at 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 because 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 just mention 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 receive the email from like Google that the Google Doc was shared. So I'm also going to 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. 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 um, 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 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 day more seamless than all these separate tools that don't work together. Um, but anyways, yeah, all of that can work collaboratively. Um, the diagrams that we have, we uh, have not turned on. It's going to use the same CRDT engine, uh, and the whole collaborative synchronization, we call it Sync service if anyone wants to search the repository for how it works. Uh, because it's all open source. But yeah, it's built on top of Loro. We had to contribute to Loro and uh, to contacted the Loro guys. They were going to 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, 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 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 one computer. Uh, and all of that is sort of versioned and computable and there's not this like weird, um, sort of uh, like chasm between my local machine and remote.

Speaker B: 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, 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?

Speaker A: 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 Claud 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 going to go search linear now, I'm going to go search notes now, I'm going to go search this. I touched on this earlier in this pod. Um, but 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, good old fashioned human can also search across all of these different modules. Um so that's the benefit. It is actually a pretty real benefit for agents and humans. Um, there's some things that we're missing that I want to get to. Um, we have cron job agents so you can set up recurring automations in macro. I have one that asks me, 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 of useful things like that it's not full open claw style yet so like open claw 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 managed itself and then the other is like, you know more um, 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 because 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 want to wait for the heartbeat. So like, you kind of want a mix of both systems.

Speaker C: Yeah, it's really fascinating. Um, I haven't really seen or at least heard of like integrated memory systems. Um, 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, uh, 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 follow on question to that. I've seen in a lot of companies there's this tension between like building sort of this like internal agents or agent, an agent as a product interface. You're building a chat with an agent that you're like wrapping the harness around versus like external integration with like Claude Desktop or ChatGPT or Codex or cloud code or whatever. Um, 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 size and wait, do we want to take this on ourselves versus just like, let the labs have it?

Speaker A: 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 kind of 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 service is just going to 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 kind of 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 want to 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, well, but, uh, from a revenue perspective, we want to be like cursor. We want to 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 going to be able to clip a 5 or 10% inference margin, which is going to be huge. It's like, uh, you know, it's like being labor. Uh, all the VCs are saying we're going to displace labor. Maybe we get to be labor. I don't know. I think you just have to make the product that people, uh, 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 going to 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.

Speaker C: I do think you have a special position too, because it's like you're mentioning earlier, it's like, um, when people are thinking about building an agent in their product or not is 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.

Speaker A: Right?

Speaker C: It'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 integration. 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, yeah, having this the place where you use agents, like makes sense in the same way it makes sense to have this be the place that you use email.

Speaker A: I really respect carry and linear. It's like, it's brilliant. It's on a spectrum of like linear to notion to smartsheet.com, they're the first name I mentioned because they're the Apple level quality. They are make it, build it slow, uh, anti996 or whatever. Like, just like, let's build, let's just make this good. Um, 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'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 we're not. Um, so it's a pretty classic innovator's dilemma situation where they actually have something like they have a real legit business, whereas we can sort of rethink what it means to do that in 2026.

Speaker C: Yeah, for sure. They're a great product. It's just like interesting the different incentives you have because of the shape of your product.

Speaker B: 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?

Speaker A: Make the marketing pages more amazing. 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 kind of have to choose one or you have to put in a ton of money. Um, so we hired the agency they 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 company of our stage for me to do, but I just, I just really felt like I had to do it. And, and one night I landed on this slab Serif pairing of this futuristic Rajdhani sort of font and the 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'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 non existent 10 days ago. So all of those docs that you see there I've written, uh, with some help from Julia on my team and from Fable. Um, but making the docs really, really good. If you really interrogate them, I think you'll find some holes. So I want brilliant documentation. Then on the product side we're about to fully release CRM and then pull requests and macro. Uh, so just you know, full on, uh, integrated with tasks. Then 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. Ah, with shared memory. So that's exciting. That'll be the coding surface and the sales surface. The sales parts. 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, 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 is like a great marketplace and sort of, you know, all this stuff despite them sort of being closed and in ways that I mentioned, like they have made it easy to build on top of Slack. We're going to 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 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 this product. Um, and obviously the Surface is 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 have been intractable counterfactually if we hadn't gotten AI and 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, really, really good. Um, and then waiting and marketing it and seeing what happens.

Speaker C: Are y' all gonna build a calendar?

Speaker A: Uh, we really need to build a calendar.

Speaker C: We, we.

Speaker A: I slop. There's a PR up, I build the calendar. But it's not, 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 also just got unified Inbox done. So Superhuman, great product. I used it for like six years. Um, it's heavily inspired. Our 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 because we own, we have all your email um, in, in our database. Of course it's SOC2 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 multi, uh, 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 because 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 worked. Uh, we've have it flagged on just for our team but we're about to fully ship multi Inbox or email which I think will be great as a reason for people to use this instead of Superhuman. Um, yeah, basically Scope creeping all of our services towards best in class for each block type.

Speaker C: Right.

Speaker A: Like Salesforce is a big, big freaking product. Um, you know 20 CRM is like trying to be an open source version of that. We're obviously doing a lot of other stuff. Evans Evan and Fable are cranking on CRM block. Um, you know, we're. We're basically a parody where with LINEAR was last year, but Linear 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.

Speaker C: Awesome. Well, I'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 solve all the problems of a business is, or all the problems of, like, collaboration within a business is, uh, that's a fun challenge.

Speaker A: Yeah, it's, uh, a lot of fun to build. 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 because, like, we're, you know, play testing it every day as a team.

Speaker B: Sweet. Well, that wraps it up for our questions. Thanks for coming on, Jacob. This was 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 telling us about it.

Speaker C: Yeah, awesome.

Speaker A: Thanks, Andrew.

Speaker C: Yeah, thanks, Jacob. Uh, excited to see what you're building and, ah, you all have, like, a fantastic team. So many great recurses there. Um, yeah, can't wait to see where y' all go next.

Speaker A: Thanks, Justin.