Warp wants to be the terminal of the future

Well, we’re here with Zach Lloyd from Warp. Zach, thanks so much for coming on the show.

Thank you guys for having me. Excited to be here.

Exciting week, or last week I guess it was for you all… The announcing of Warp, a brand new terminal for the 21st century. Do you wanna tell us about your launch? It seems like it made quite a splash…

I would say the launch went really well, yeah. Last week we went from being in private beta to public beta. We announced the funding that we’ve raised so far, we had our first press, we had a TechCrunch article… We were, I would say, heavily discussed on Hacker News, which was cool. We were at the top of Product Hunt, so the number one product of the day… And generally, it was awesome. A lot of people trying the app, a lot of feedback, a lot of chat on Twitter… We worked really hard to set it up, and it went pretty well.

Well, congrats. That’s no small feat.

Thank you.

Launches can be very – you can get very anxious during the process, right? There’s so much planning involved… It’s like, behind the scenes you’ve seen the excitement, right? You mentioned a private beta, so I imagine there’s some sort of excitement to kind of keep you going and prepare for it, but… You know, launches can be a time of anxiousness. How was it for you and the team?

Yeah, I would say there was definitely a bunch of anxiety. The thing with the launch is that you can kind of control the inputs, but you really can’t control the outputs. There’s just a lot of factors that are sort of lock in unknowns go into it… So the thing we sort of emphasized was like “Let’s do the best job that we can preparing the product for launch, and fix as many things as we can. Let’s make sure that we’re on top of handling all the feedback…” But then, you know, you post something on Product Hunt, you post something on Hacker News, you even get an article written about you, and you have no idea really what the pickup is gonna be, what the reaction is gonna be…

I think the most anxiety-filled part of it was probably the 20 minutes or so after we went live, to see if people would care or not. I think the thing that you really don’t want is a launch that people just don’t care about. That’s sort of the big risk. And so there’s this slight period once you put your thing out where it’s like “Does anyone care?” And once we got past that, it was more like “Okay, people care, and there’s a lot of stuff that we have to do to sort of make it successful.” But yeah, it was definitely a bunch of anxiety.

[04:10] What was the care level, let’s say? Let’s use that as the barometer for the day.

I would say the care level was really high. We were the number one post on Hacker News for almost all day, Tuesday. I think we had like almost a thousand upvotes, and maybe like 800-900 comments, or something like that… Which is a pretty insane level of engagement from that community. And to be clear, there was a lot of stuff which I would consider feedback, or questions people had…

Criticism…

Criticism… Hacker News is an environment where people say what they think, and a lot of people are not shy about doing that. So as a team, taking the feedback, trying to figure out what adjustments should we make, how should we respond to it - it was stressful, but good. Again, like I said, I would much rather have a lot of people interested than people not caring.

Hacker News - I would say really, really successful. Product Hunt - number one product of the day. I don’t know how typical it is for developer-facing tools to be the number one. Twitter - I think our video, our sizzle reel had 60,000 or 70,000 views, or something like that. We were retweeted by a lot of really prominent developer influencers and entrepreneurs… I think people really did care about it. So from that standpoint, the launch was amazing.

The one point that was missing was Jerod’s response back to you on Twitter, coming on this show.

Ah. The biggest one. [laughter]

We had one overall goal, which was like “Can we get on Changelog Podcast?” And you guys reached out, and I was like, “Okay, mission accomplished.”

Well, I have to say that the pump was primed. So we had a listener request you come on the show…

Oh, yeah?

And he is under your employ, so I’m not sure if this was a part of the launch plan, or Roshan just thought it was a good idea…

Ah, interesting.

So shout-out to Roshan for suggesting we have you on. Now, this is back – this came in early March…

Okay.

It was pre-launch. I didn’t know what Warp was at the time. And actually, when I saw you guys’ launch, it was like the synapses connected and fired, and I was like “I feel like this has been requested as an episode.” So there was some priming that happened there, and it all came together very nicely.

But in addition to that, the reason why I thought this would be a good episode is because we just recently did an episode with Toby Padilla from Charm. And the Charm team is building tools for text user interfaces, and all sorts of command line things.

Yeah.

They’re also VC-backed… And during that conversation, speaking with Toby, a lot of their hurdles are in dealing with kind of lowest common denominator features of the existing terminals. So they’re building inside of the terminals… And to him, Adam and I both said “At a certain point, don’t you feel like you should just reinvent the terminal?” And he said “We’ve thought about that, we’ve talked about that. Right now we are not doing that.” And when I saw Warp - and actually, Adam has since pointed out a couple other people that are trying to do this as well. Fig I think is another one… I was like, “Well, cool. Here’s somebody who’s actually going after the terminal itself.” So that’s kind of the back-story on why you got the invite.

Nice!

Roshan, plus some timing around the Charm episode, plus - it seems like what you guys are doing is pretty interesting.

Cool! What the Charm folks are saying makes a ton of sense to me, and it’s basically the attitude that I kind of approached this with, and what we’re on the team thinking about. It’s like “What is the best possible product and user experience that someone who is using the command line could have?” And if you actually wanna get to that sort of end result, I feel pretty strongly that the terminal is the place to focus, because the terminal is the actual app. And if you’re just working within the shell, or within the CLI, basically what you have then is the terminal is the sort of fixed rendering surface for characters, and you’re just gonna be sort of intrinsically limited in what you can do if you’re not actually rebuilding the app. The hard part about rebuilding the app is that it’s harder. From an engineering standpoint it’s harder, from an adoption standpoint it’s harder…

Exactly.

[08:20] …from like a “How do you innovate while still making it backwards-compatible?” is hard… And all these things are hard. But you know, we’re taking a very long-term view here, which is like “What should this thing actually look like?” if you had a magic wand and were designing not only the tool, but also the platform around the tool… So we were just fortunate, I think, to be in a position where we can build the ultimate vision of this. And I think it will take a while for that vision to become a reality, it’ll take a while for every developer to use it, but I think the way that Warp will become prevalent is just by building the best possible version of this experience.

The timing aspect of a launch is kind of interesting too, because it’s like - I’m looking on your LinkedIn, and at least by your personal resume (for a lack of better terms) for LinkedIn, it says “June of 2020.” So there’s one, I wanna talk about timing of like how long has this been going on…

Yeah.

And then two, in terms of like a launch, the hidden ingredient there which you cannot control really is market timing. You may have been toiling away for - in this case now - years, ready to launch, and now it’s funding, you’re at a place where you can actually welcome non-internal beta users, or beta users into the system to use Warp and whatnot. But timing is one thing… But in terms of time, how long has this project been going on? What’s some of the back-story?

Yeah, so Warp as a company started in June 2020. We spent – so it was me, and then the first person who joined me was actually… He used to run the design team for Google Docs. My background, by the way, is I used to run the engineering team for Google Docs. I was the principal engineer there. I helped build a lot of Google Sheets.

We spent, I would say, the first six months in the mode of like bringing on the first couple engineers to join us, and then doing really a bunch of prototyping and figuring out what should the product be, how should we build it… We actually built a version, like a prototype thing in Electron, then we ended up throwing away and starting over in Rust… And I would say product development in earnest, for the Warp today, that people are actually using, started around the beginning – actually, around the end of 2020. Probably like November-December 2020.

Then we went into a private beta in July of 2021, so about 8-9 months later, where – you know, the tool still had a lot of rough edges, but we still managed to get very meaningful feedback from… We had thousands of developers using it in the private beta, so we got a ton of feedback on that. Then we felt like it was good enough to go into public beta, which is what we’re calling it now… Because it still is like – this is a hard piece of software to build and get right. So there still are rough edges, there still are workflows that don’t work for developers, we have like 400 open GitHub issues… So it’s been a long haul, and it’s like nowhere near actually where it needs to be. It’s only one platform right now, we haven’t built a lot of the things that I think are really gonna be compelling around teamwork, and even around single user stuff that we wanna do. So it’s just a long slog to build from scratch something like this kind of app.

It’s been around for a while. It’s been there, right? It’s tried and true. There’s a statistic out there that says 100% of developers use their terminal, and I guess a small percentage use VS code, you were saying, Jerod… I’m not sure if that was from Warp or not, but…

Yeah, I think Zach wrote that.

Zach wrote that? We question that statistic, but… It seems pretty accurate.

Every developer, whether they want to or not, uses the terminal. It’s very – for me at least I’ve never worked with someone who can get away with not using a terminal. I think the stat was like –

60…?

I think VS Code now has like 70% of the IDE market. The terminal market is much more fragmented.

[12:09] Right. To set up your environment and to install things you’ve gotta at some point touch the terminal. You may not use it as your driver, but you definitely have touched it as part of your flow as a developer to get set up. It’s highly likely.

What about timing? So we talked about time involved to get here… What about timing of the market? Why is now the right time, I suppose years later, of course, given the time you’ve put in so far - but why is now the right time for someone to really reinvent the terminal? What is it about today, or this moment, or this time?

Yeah, I think that’s a great question. It’s a common question that I get. The terminal has basically been unchanged for 40 years. There’s been like a lot of open source projects to try and make things that are within the terminal work better. Terminal itself hasn’t really changed much.

I think that the reason that this is viable right now with our approach, which is like we’re a company that has raised money, and built a team, and trying to take a sort of from-first-principles approach to redoing it, is basically that we believe and investors believe there’s an actual business to build around this. And that, I think, maybe is not so obvious. So the thing that has happened recently is that there’s a lot of companies that have taken sort of single-user tools and made them collaborative, and built businesses that are compelling around them. And I’m thinking of tools like Figma in design, or Notion for wikis task tracking tools. So it’s now plausible – I think not even plausible, I think it’s inevitable that someone will take the terminal, make it work for teams, make it collaborative, and that will drive a bunch of business value which is something that you could actually build a team and have enough capital to really try and redo this. So that’s kind of my answer…

The other thing I would say is there’s a lot of evidence of demand around better CLI tools and better terminal environments. If you were to look at some of the top GitHub projects of all time in terms of how starred they are, you would see that some of them, actually in like the top 10 - I think maybe Oh My Zsh - are things that are just like “Let me make your terminal experience somewhat better. Let me give you completions, or theming. So I do think there’s been demand around this for a really long time. It’s just like, the notion of like you’re gonna totally try to change the system and rebuild it probably takes capital, and that’s why I think the opportunity is happening now.

How much of this was informed by your time at Google Docs? Because when I think your strategy, it’s very much the Google Chrome strategy, which was ambitious. Of course, they had Google.com advertising, right?

They had a great distribution channel.

They did, and it worked. But you’re very much doing that - brand new terminal, install base zero… Right?

Yeah.

And you have to get that install base out there, otherwise you won’t have the penetration that you need…

Correct.

Whereas you could work inside the terminals, like Charm is doing, and paper over certain things, like people on websites do back when they had – you know, we needed jQuery because the DOM was so different in different browsers. Well, Google came along and said “We’ll create our own browser.” They had lots of reasons to do that, but one of them - probably driven by needs of like Google Docs…

A hundred percent.

…and desire to make richer experiences, move faster etc. So you’re kind of copying a little bit from the playbook, or at least inspired by it. What was your experience with Google Docs, and how does that inform what you’re up to with Warp?

[15:47] Yeah, there’s a lot in there. So on the Google Docs side - I think the main things that I carried over were that from like a product perspective and a productivity perspective the idea of taking desktop software (and for Google Docs it was Office, basically) and just making that live in the cloud, making it cloud-native, making it really easy to share, making it really easy to access from anywhere. That model is just – even if your base product isn’t even as good, and I think at Google Docs it took us a long time to get to a base product that was really good… That model is so powerful; I think you could pick almost any piece of productivity software, apply it, and there’s gonna be some benefits. You’ve seen that in – I mentioned Figma, Notion… Like, pick a tool - if you make it internet-native, if you make it work for teams, it’s gonna be better.

For the terminal, I really believe the same thing will be true. I think the features might be different. I think real-time collaboration is cool, but maybe not the most important thing for a terminal… But actually, to be honest, it’s not the most important thing for Google Docs either. The most important thing for Google Docs is actually more sort of asynchronous modes of collaboration, where it’s like one person creates something, and then another person builds off it, and looks at it. So for the terminal I think there’s always other modes of collaboration that it’s gonna be really powerful when we unlock.

So that’s like the Docs angle. I think the Chrome angle is really interesting, because – I mean, I wasn’t on Chrome, so I can’t totally speak to their motivations… But I think at some point Google was just like “Look, we want the web to be as good as it can possibly be”, and without sort of taking control of the platform and building what they thought would be the best possible experience, they’re kind of like stuck to making these apps marginally better.

Now, Google had, like you said, a huge advantage in that they could not only spend a ton of money building a browser, which is very expensive… And in that sense, Warp is actually not as hard as a browser, but it’s kind of hard… But they also have this amazing distribution channel, which we don’t have, and so we have to figure out another way to sort of get the product to grow. But yeah, there’s similarities and takeaways from both.

Have you got any plans, have you got any ideas?

On how we’re gonna grow?

Yeah, because - I mean, you got a good splash… The Changelog episode is gonna get you some downloads, but those are one-hit wonders. They’re not gonna sustain. So you have to have some sort of way of getting it out there to folks. That being said, you probably don’t need 60%, 100% market share to be a successful business, right?

No, we don’t. But yeah, I can tell you the way that we’re thinking about it… So there’s sort of three prongs to it for Warp, about how we’re gonna grow. So the first is really like something that’s called product-led growth these days, where the idea is there will be ways within the product where if you use Warp, you create something that’s valuable not just to you, but to people on your team, and then you share it. And person-to-person or person-to-team sharing is to me like – if we can get to that, that’ll be the best way for Warp to grow. Because it’ll sort of be growing itself. The more people use it, the more valuable it gets, just because we have collaboration features, or we have things that people can do in Warp that are useful not just to themselves, but to their teammates.

So that’s one way, and I would say the primary way that we care about. The second way I think is really through trying to build out sort of an ecosystem and extension points, meaning like - you know, we’ve built a very general-purpose, horizontal terminal, but if we can build things that enable developers to take what we’ve done, tailor it to their own use cases, build in things that are useful to their teams, or just to the public at large… I think that building community and ecosystem plugins, extensions, that type of thing - there’s a sort of network effect to that, which could help us grow.

And then the third thing is stuff like what we’re doing right now, which is like, we need to find ways to get in front of developers, make them aware of the product; that could be on social, it could be through podcasts, it could be through us producing great terminal content that lives on TikTok, or YouTube, and just sort of positioning the company as a leader in like “Hey, if you’re doing anything related to the command line, Warp is where you want to be.”

[20:16] So those are the three ways that I think we can actually get Warp to grow. And it’s working so far. We had a big splash, but we’re getting more and more people to use it, which is pretty cool.

Sure. Well, I can speak to the stickiness of Google Docs back when it was like the only collaborative office type of thing… And just the fact that, like you said, that feature alone, the web-native features of Sheets and Docs, even though Office Suite was better native software, it was just like “Yeah, but I can just collaborate with this so easily.”

Right?

“So I’ll just share a link, and now we’re both working on it.” That is a viral – what do you call it? Product-led growth?

Yeah, a hundred percent.

That is product-led growth. And then b, it’s so compelling that you put up with shortfalls or shortcomings elsewhere just to have that one thing. So if you can get to that collaborative bit, and if people want to collaborate inside their terminals like they do on Office documents, then I think that is a nice strategy for growth.

Yeah. I mean, the thing is – I think you can’t really start with that for the terminal. It’s just hard to get a group of people to adopt a thing at once, relative to an individual. If you look at the features that we have today, it’s actually not so much about collaboration. It’s more about how do you make the terminal more usable? How do you make it more powerful for an individual, just so an individual has some reason to use Warp, and immediately gets benefit out of it? So there’s this sort of – you’ve gotta make it awesome even for individuals to start, I think, for the terminal… Whereas for Google Docs, that was gonna be a very hard value prop, because Office had a 20-year lead in terms of features. I actually think the terminal - it’s feasible to do it the way that we’re doing it because the existing terminal experience, in my opinion, is really not good. So we can actually sort of get a lot of traction just by improving that, and then we can continue to add on features that are for teams.

So I guess the question is – you said the existing terminal experience isn’t that good… So what’s the baseline for what you say the terminal experience is? Because you’ve got the terminal app on Windows… You mentioned you’re not multi-platform yet, but obviously, the terminal is multi-platform… So there’s a terminal experience per operating system, Windows, macOS, Linux. So what’s the baseline for what you think the terminal’s experience is not good enough? What is that baseline?

Yeah, so I think the things that are from a user experience standpoint not good are it’s a hard tool to learn. So when you open it up, you’re literally just looking at like a black screen, with nothing in it; you don’t know what to do. In order to get it to actually be useful, you typically have to do a lot of configuration. So the defaults that ship with it out of the box aren’t very good.

It’s a tool that it’s very easy to make catastrophic mistakes in… So people will cause outages because they have one or two characters off, and they don’t know what they’re doing… It’s a tool where it’s totally single player and non-collaborative; you’re using it on your own, you don’t know what you’re doing on your team. It’s totally ephemeral, in the sense that every time you close it and reopen it, you’re basically starting over. If you switch computers, you switch contexts, it doesn’t switch with you.

The basic UI paradigms are very weird, meaning like input in the terminal doesn’t work how it works in every other app. It’s not mouse-accessible; you can’t click and put the cursor someplace. If you select text and hit Delete, it doesn’t delete what you have selected, it deletes the thing at the end of the line. If you have multi-line text, hitting up or down you can’t always edit it.

The output is very hard to use. It’s just one big stream of characters. So there’s no logical delineation between the different things that you’ve done in the terminal, even though for the most part people are using it. It’s a sort of like repl… Like, run a command, see an output; run a command, see an output.

So those are just things that I’m scratching the surface with, but if you start thinking about it, I think you’re kind of like “Why is it like this?” because this is not what you would build if you were trying to build a tool for interactive text-based apps. So that’s my take on that.

It’s a pretty good list… I find myself going down the list with you thinking like “There are solutions to each individual problem”, but even those are esoteric solutions… Like, you have to discover those things.

For sure.

And I think it is – like, the first one is nail on the head; discovering how to use the thing is darn near impossible. It takes years to master certain parts… That’s why we have – what is it, like commandlinefoo.com, and all these mastery things, and courses, and cheat sheets, and all this stuff.

Yeah. Everything has a sort of point solution. So it’s like, documentation - okay, you can run a man page, or you can go to Stack Overflow… Completions - you can go into GitHub and install some third-party GitHub thing… If you wanna keep your stuff in sync, you can make a dotfiles repo on GitHub and sync it across computers… It’s all just such a pain to do, and it’s unnecessary. So these are the things from a product standpoint that initially got me really excited about like “Why is this thing like this?”

And by the way, part of the reason why it’s like it - just to diverge for a second - is the historical architecture of like what is a terminal and what is a shell. The terminal that you’re using when you open a terminal app on your computer - you’re running an app, say on your Mac, that is emulating the behavior of a physical hardware terminal that hasn’t been, I don’t know, made or used since the ‘80s. And it’s doing that because that’s what the shells and all these command line programs expect to interact with. So all the shells and command-line programs just treat the terminal as a very simple character input and output device. So it’s like characters go in, characters go out, and the shell can basically say “Draw a character on the screen at X place.”

[28:22] Sure.

So that’s kind of some of the historical baggage of why it’s like that.

I feel like we need a detox session, or a – what do you call it? Like a user group where we all hold hands and talk about it. What’s good about a terminal? Because I love them, and I agree with every point that you made there… And it’s like, “Why do I like it though?” Surely, as a person who wants to reinvent, you have a love/hate relationship with the terminal itself. What’s good about the terminal? Why would you want to bring that to modernity, versus GUIs.

That’s a great question. So I was pointing out the things I think are wrong with it, but the things that are right with it are it is the fastest way to do a lot of things. So if you’re a keyboard person and you wanna just use text, it has just ergonomic benefits.

Terminal apps, command line apps are the easiest apps to write, by far. So you always have people writing command line apps because it’s just so much easier to write a text-based app than to write a GUI. So probably more text-based apps are written than any other kind of app; most of the internet runs on text-based apps. Every Docker container is just running a bunch of shell script underneath, that is launching a text-based server… So it’s very powerful for controlling those types of text-based apps.

Text-based apps themselves have nice properties, in that you can super-easily script them. It’s really so much easier to program a series of things that are text, than to program a bunch of GUIs. They are composable, meaning you can easily take the output of one and put it into another. So for that reason, it’s a super-fast, nice, minimal interface, where for a lot of the tasks that developers are doing and a lot of programs they’re running it’s the ideal way to do it; it’s just so much nicer than pulling open a GUI to do it.

So I think the command line is awesome. In fact, one of product principles that we’ve started with was like - I’ve always worked with engineers who are really good at using the terminal, and the idea was like “Can you just make that power accessible to a much larger group of developers, with a lot less work?” Because I think that’s where a lot of the leverage from building a better terminal is going to come from.

As you were going down that list I was also nodding my head, but at the same time not envying you, at all. I was thinking like, “This is an absolutely hard job.” And I applaud you and the team for taking on this challenge. I think it needs to be done, but wow - I’m just taken aback by the mountain that you must climb.

Well, what’s really hard is like – you know, we’re talking about reinventing it, but we’re trying to do that within a world where we are largely backwards-compatible. We could just be like “Oh, we’re gonna write a totally new system, new terminal, new shell. Everyone who uses it has to start over, and Warp’s so great they’re gonna want to do it.” That is not the approach that we took. We took the approach that Warp is gonna as much as possible work with people’s existing shells, and their existing scripts, and we’re gonna kind of bridge people into a better product experience. So that’s actually harder, because it’s easier if you fully control a system.

You’re inheriting the baggage.

Exactly. So you know, this was a conscious decision, and that makes it even harder, because we have to support a lot of things people expect to just work.

There’s the analogue that I’m drawing in my mind with databases, and the approach that FaunaDB is taking, versus CockroachDB… Fauna is saying like “Hey, we’ve got a whole new query language, and you’ve gotta use it. It’s great.” They have the reasons why it’s great. And then other companies like Cockroach is like “We are Postgres wire-compatible. We have our own language, but also, here’s the things that you’re used to, because we think that’s going to help adoption.” I respect both approaches. One puts the stake in the ground and says “No, because we can do it better if we forget about all this other stuff.”

[32:17] Clean break, right.

And the other one says “Yeah, but we’re not gonna get anybody to come along unless they have some sort of path towards that…” So that’s a tough call, and probably one you had to make early on.

Yeah. And by the way, Google Docs had the exact same set of questions with Office compatibility. There were arguments to be made, like “Hey, just forget Office compatibility. It’s like a cost that we always have to incur, and we can innovate faster if we put it aside.” But we decided then, and I took a similar approach with Warp, that it’s better to try to bridge people into the experience.

Now, I do think – you know, there’s trade-offs. That’s kind of the simplest way of putting it. Both approaches are cool, there’s trade-offs, but it is a conscious decision that we made to try to bridge people into Warp.

Yeah.

Did you consider both paths at one point and say “Okay, with the bridge we have these benefits, and we can sort of predict this future, and without the bridge we’re throwing the baby out with the bathwater, and we get this. Brand new approach, brand new thing, forget everything else.” Did you consider both paths and sort of came to a conclusion, or did you just sort of go one direction?

We considered both. So what it would mean for Warp to not be compatible - I really think it’s probably we would write our own shell. And we may eventually do that. The real downside - well, there’s a bunch of downsides to doing that. The downsides are people having existing configuration and setups for their shells, so we would have to have some way of importing that, which I think is actually maybe doable. The real thing that’s very, very hard with it is the remote shell use case, where we want Warp to work if you are connecting to a remote machine, and the person who’s running Warp on their Mac might not actually be able to install or configure anything on that remote machine.

So that’s where it necessitates some level of compatibility, because SSH and remote work is important to people who use the terminal. So that kind of made the decision “Okay, let’s start with the compatibility approach”, and then I think at some point we will write a shell at some point; I just think we’ll probably do it at a point where Warp has enough traction that we feel like we can ease people into that, rather than betting the whole product experience on it.

So you set out to build a terminal, you’re making these hard decisions at the time when you’ve gotta make them… But what does that process look like? I like ambitious people and the way they take on projects; I appreciate it, and I like to think how did you come to this decision, and then the next thing I think is like “And then what did you do next?” Because here you stand, and – I think I just said this the last episode, Adam, or maybe it was on a different show - how do you eat an elephant? One bite at a time. It was kind of like, “Well, we take that next step”, but you’ve also gotta decide which part of the elephant you’re gonna bite off first, I guess, if you’re gonna keep the analogy.

When you face this mountain that Adam has described, “I’m gonna build a terminal from scratch”, what do you do next? What do you start building first?

Okay, so it’s a great question. So we started with sort of the fundamental UI things in a terminal. We started with what people really do in the terminal; they work with input and output… It’s the predominant use case. There’s this second use case which we actually don’t do much with right now, which is like they run full-screen terminal apps, like Vim or Emacs or something… Warp right now doesn’t do – there’s not much special in Warp with those apps. But for the type of uses that we were looking at, which is like “What do people do all day in a terminal? They run commands”, we were like, “What is that fundamental experience like, and how could it be better?” So we started thinking about, “Well, on the input side for instance, the input and editing experience is not good. What would actually be a very good input and editing experience?” and we decided it would be something that’s much more like what you would get in VS Code, basically. Like, why doesn’t that experience exist in the terminal?

[36:17] On the ouput side, we were like “What are the problems with it?” and it’s sort of like what I talked about before - you can’t really tell what command produces what output, so that means you can’t navigate around your terminal on a command by command basis, or copy-paste what you want, or share one specific thing you did from the terminal. So we took inspiration from VS Code for the input, we took inspiration from Notebooks for the output, where you have a structured sequence of things you do… And then our bet was like, you know, for this for real with a long-term vision let’s just start with the fundamental things and try to make them as good as possible.

So we had ideas around that, because we’re developers and we use the terminal every day, non-stop; we talked to a lot of developers about this… And then our goal right at the beginning was like “We need to get to a feedback loop.” So when you’re starting a company – we knew we had to build for a while before we’d have even something people would give us feedback on, so we did that. But then the first big milestone was like “Can we ourselves use it?” That was actually the first one. And then secondly, it was like, we had external people giving us feedback.

And now that we have a lot of feedback, we’re in a mode where we’re much more easily able to do planning and prioritization based on what users are saying. So you kind of get into a mode where it’s like, it’s no longer just us guessing, it’s more like, we know users want X, so we can sort of prioritize those things.

And somewhere along the way you also had to select technology choices. You said you started off in Electron and switched to Rust. Do you wanna tell that story?

Yeah, so we were – you know, my background is engineering and web technologies. That’s what I know best. The first couple of people we hired were also coming from that background, from Google and other places… So we started off in Electron, using a stack we kind of knew, and then we made the decision to switch to Rust because we thought that would produce a much faster app.

The app in Electron was kind of slow, and my experience from Docs was that you pay a very big performance penalty when you use the web platform. The web platform is awesome in a lot of ways, but you know, we spent so much time on, say, Google Sheets trying to optimize what should the memory layout be for a spreadsheet cell, and on the web platform and JavaScript you actually just couldn’t control it. So it was very hard to build a higher-performance app.

So the reason we chose Rust was primarily performance. Second to that it was performance with a decent – actually, not a decent… Like, a really nice actual language design, which you could be productive in. Rust is not quite as easy to work in as TypeScript or Python, but it’s really ergonomic; you can be very productive in it.

And then thirdly, Rust had a great cross-platform story for how we wanna eventually do cross-platform, which was we do wanna support the web, we wanna support Linux, we wanna support Windows, and Rust can sort of cross-compile to all of those, and so we ended up just thinking that for the best product experience that that was the way to go.

Cool. And it sounds like you were using some other open source stuff as well under the hood, one of which surprised me. We’ve had them on the show… Nushell. Nushell is like a part of Warp?

No, so–

Or just for inspiration. I’m on your readme, looking at your open source dependencies.

Well, it’s slightly complicated. We worked pretty early on with one of the creators of Nushell, Andrés Robalino… And he actually helped us build out some of our completion engine using some piece of – we basically forked a bit of Nushell code and turned it into terminal completion.

Gotcha.

[40:10] But yeah, Warp unfortunately at the moment doesn’t really natively even support Nushell. It’s something we would like to support. Nushell is a pretty cool product. But it’s built in Rust, so we have a relationship with them.

Gotcha. Yeah, I was looking at your open source dependencies and I was like, “I thought there’s no shell inside yet”, but you’re gonna have your own shell eventually… But then I saw Nushell and I was like, “Wait, is there a shell in there?”

It isn’t. We run right now Bash, CSH and Fish are the shells that we support.

Okay. So my next line of questioning is around kind of the user experience of what’s currently available… But Adam, do you have anything else on the history of that, or the architecture, that you wanna squeeze in here first?

I think just recapping really the how it works, from the site, really. Warp is a fully native GPU-accelerated, I think – you know, talking about GPU acceleration, why that’s important… Those are part of user experience; obviously, there’s a reason you chose Rust, but the reasoning for being 60 fps friendly on 4k screens, why no Electron - you’ve kind of answered that. Why web tech obviously being web-native… But the GPU accelerated and the 60 fps I think can use an explanation in terms of the user experience.

Sure. So we’re truly a full-stack native app in Rust, and we – so not only is our terminal code written in Rust, but we actually have our own UI framework that’s written in Rust, that interfaces directly with Mac’s graphics library, which is called Metal. Metal is sort of like the OpenGL equivalent on Mac.

Again, this was all done from the user experience standpoint to – I think the terminal needs to be fast; the things that are likely to be slow in a terminal are rendering a ton of text. So laying out/rendering text can be very slow. We had that problem on Docs. So just being able to do everything directly on the GPU, through our own UI framework, makes it from a stack perspective as fast as it can be. You can still write slow code, whatever stack you use; you can write an algorithm that runs slowly. But we’re not limiting ourselves by the actual framework that we’re working in.

The other reason we did it that way is like, when we do go to Linux or the web, it’s pretty clear in our code what parts are platform-specific. For instance, on the web, rather than using Metal, we’ll use WebGL to do the rendering. So that was why we picked the technical architecture we did.

So how heavy to lift will it be when you decide to do Warp for Windows? Will it be 30% of the existing code rewritten, or 60%…?

Probably more like 10%.

Okay.

So probably like 10% of our code is platform-specific. The code that’s platform-specific is the rendering code; it’s like the windowing and event-handling code, it’s things like system notifications, and build pipeline, that type of stuff… But I would say 90% of our code is not platform-specific.

That’s a good percentage.

Yeah. I mean, most of the stuff is about the terminal, not the platform.

I would feel pretty good about that 10%, if I were sitting where you’re sitting. That’s a good number. I would expect you to say 30%, so 10% is actually pretty nice.

Yeah.

So for most products you go iOS, then Android. Do you either go Windows first, or then you go Mac, and then Windows, and then Linux is always the thing that you’re “working on”? But for a developer terminal tool, you almost think like “Linux is actually a pretty important platform for you guys”, right? You almost might wanna do that one next. What are your thoughts?

Linux, if you look at our GitHub issues and you sort them by number of requests, Warp for Linux is number one. So from what users are asking for, Linux would be next. I think Windows will be last. I don’t know if Linux will be next or the web will be next. Those are the two that we would potentially do next. Of the two, Linux would be easier, and users clearly want it. Web I think is maybe more interesting for us from a product standpoint, from what are the features that are unlocked if you have a web-based version of Warp.

[44:19] And then the reason we started focusing on one platform is just like I’d rather have a killer product on one platform than an okay product on three. So it’s faster to iterate on getting the product perfectly right on one platform before we spread out.

Well, I think your move away from Electron pretty much made that bet, right? You made that decision at that point.

We made a bet… By the way, that bet - I feel 100% that we did the right thing with that bet. I don’t think developers want an Electron-based terminal.

Yeah.

I guess would you get the GPU acceleration, would you get the 60 fps- would you lose that in Electron?

It depends how you did it. You could always technically run a WebGL app in Electron, which is a very contorted way of doing it, but… That’s actually Figma, if you look at what they do; their codebase, I believe, is C++, and then they compile to WebAssembly and WebGL. And then they run that – their Figma desktop app is running that WebGL and WebAssembly stuff. So you can get good performance, but you basically would still be doing it via a native code path.

Well, they say if you’re not embarrassed by what you shipped, then it took you too long. You guys launched, had a great response, a lot of interest… If I’m picking up a little bit of your vibe, it’s like still early days, you’re putting that out there, fair enough… You know, get it out there…

Yeah.

Obviously, there is a warp.app you can go out and get on macOS today and try public beta. Whenever you compare a thing and maybe consider adopting it, you compare it to what you’re currently using, and you’re like, “Okay, which one’s better? Which one do I like more?” And while the future I think is bright, there’s certain feature set today of what it looks like, how it works… Is there anything in there that’s killer right now, that I’ll be like, “Okay, I’ve gotta try this, because it has this thing that my terminal doesn’t have”, even though it may not have the colab stuff yet, and some of the stuff we’ve been talking about? What’s Warp like today, that will get people excited to give it a shot?

Yeah, so the feedback that we get as far as what people love the most today are actually the most basic features we have, which is - input is a real text editor, which means fully mouse-accessible, selections work, you can do multi selections, you can do multi-line… It’s just a much nicer experience to edit a command in Warp.

The second thing is a feature called Blocks. When you run a command in Warp, we give you something that looks like a notebook output, where the command and its output are connected together, and you can do things like copy-paste the output, you can create a permalink of the output, which you can then share to anyone on your team, or put in a wiki, or whatever… So basically anything you do in Warp today, you can opt-in to share it.

We have awesome features around command entry. So we ship with about 500 built-in completions, where we give you visual completions as you type things, in a tab. And we don’t just give you completions, we give you in-line documentation, which is super-cool.

We have a feature called Workflows, which doesn’t exist in any other terminal. The idea there is - it’s basically a searchable library of saved commands for things that would be annoying or hard to figure out on a word-by-word basis using completions. A good example is how do you undo your last Git commit? I always forget how to do that, and so for Workflows there’s a specific workflow it’s like git reset -- heart carrot head where you can now semantically search for workflows.

You can save your own, which is really cool, and share them with your team. So if your team has a bunch of private commands that they typically do that are harder to remember, you can bake them right into Warp and keep them up to date that way.

And then we have one really amazing feature… It’s basically natural language command search, which uses OpenAI Codex. So kind of like - if you are familiar with Copilot on GitHub or something like that, we have something where you can opt in on a command-by-command basis to ask OpenAI to generate your commands… And that’s really, really cool. And it works actually remarkably well.

So those are all, I would say, reasons to use it today. Beyond that, it’s just a much nicer, more polished terminal experience. We have a command palette, we have built-in themes that are super-nice… But if I had to summarize the pitch to a developer right now, it would be like “Warp is something that’s gonna make you significantly more productive, without breaking your workflow.” With a big asterisk next to it, which is that there are certain workflows that we don’t yet support, because we’re public beta. For instance, if you use tmux, you’re probably not gonna get a ton of value out of Warp right now. And we are working through things that don’t work that well, to try to make them work better for everyone.

[52:09] What’s it gonna take to support Vim, Emacs, Tmux, things like that?

So Vim, Emacs, Tmux - just to be clear, they all work. If you run Vim in Warp, you get the exact same Vim that you would get in your normal terminal app. Tmux I’d say needs more work, because when you run Tmux, what happens in Warp is it basically takes over the full screen, and you lose all the cool features around better input and output that you get with Warp. So for Tmux we’re either gonna build something on top of Tmux that gives you the Warp features, or we’re gonna basically replace that Tmux functionality with something that’s native to Warp, which I think is the more likely way that we would do it right now.

So it’s gonna take some time for us to support the full range of tools that people use totally natively, but I’d say – for most developers today you’re not gonna hit one of those issues, but there are some people who will.

You were saying too before that one of the user experience issues that you kind of encounter is this blank screen, which is a challenge for those who are new to terminal, or those who don’t use it too often… So dare I just say “newbie”, or someone who doesn’t use it that often; a novice in it.

Yeah.

Whereas – I’m curious, this roadmap you’re focused on, is it focused on more of like “I currently use a terminal, and I’ll get benefit from these initial features, so it’s easy to adopt?” or is it more like attract those who never have used a terminal? If you had to skew your percentage of focus, would it be on the current terminal users, but maybe not like the Tmux, Vim users, because they’re obviously not support right at this moment? Or is it more like brand new to terminal focused features? How would you skew that?

It’s professional engineers. So it’s people who are in the terminal, who depend on the tool, who want a better experience from it. There are gonna be some people who are like “The current terminal is perfect. I’ve spent the last 20 years learning it, and I’ve configured it exactly to my taste”, who probably are not the initial users that we want. But we’re building this primarily for professional developers who wanna be much more product and effective in the command line.

That said, we do have a lot of people who are like college students, or in dev bootcamps, who - terminal is a very unapproachable tool, and Warp is a much nicer experience for them. But we’re explicitly trying to build something that is primarily targeted at people who need to be in Terminal a lot, and will benefit most from these types of productivity gains.

So I’ve been using it off and on here today, and as we talk… The blocks feature is, I guess, a little difficult to explain just in conversation, but it is really cool. After you issue a command - let’s just do a basic ls, and it lists the things in the current directory… Well, that whole – the input, the command and the directory listing are blocked off with like basically a horizontal rule, a border… A one-pixel border, basically, for web dev talk…

[laughs]

And you can highlight them all together and then in the upper right there’s the three dots menu; you click on that, you can copy the command, you can copy the output, you can copy them together… So it treats them as this almost atomic unit. And that is a cool thing. It looks nice, it actually encapsulates mentally, as a person who’s been using the terminal for 20 years, the way that I think about it anyways… So yeah, the first run from that perspective, from a professional, is like “This is just a nice-looking, and has some cool ideas terminal”, as it stands today.

Now, the one thing that kind of stopped me on first launch is… Sign up with GitHub?

Yup.

That to me seems like a business part of Warp, and not really like for me. Is that for you or for me?

[55:53] Great question… This is one of the things people gave the most feedback on on Hacker News. The short answer is it’s for you; it’s not so much for us. But it’s a little bit more about where we wanna go than where we currently are. The place that we wanna get to with Warp is that there’s a reason that we need to know who you are in order to keep your things, sync them across computers, make it so you can work with people on teams… And if we don’t have a sense of who’s using the product, I think it’s just really hard to do that. There’s some use cases that you can do anonymous, but what we’re trying to do is build a sort of cloud-native terminal that works for teams. And without someone logging in, I think it’s gonna be very hard to move past, just basically to get to that product experience. But it’s a question, like – we got a lot of feedback on this, especially on Hacker News…

Full honesty, if I wasn’t compelled to do it, because I wanted to talk to you about it, I probably would have deleted it right then. Because I have a terminal that’s pretty good, in my opinion, and I don’t need to sign into it. So when I had to sign into it, I probably would have stopped… But I pushed through, because I really wanted to try Warp. And once I got in, I was like, “This is cool. I like this.” But I probably wouldn’t have gotten this far if I wasn’t talking to you about it.

Yeah. So we’re talking about this – this is literally a thing that before I got on the podcast…

Had some meetings today? [laughs]

Yeah, I’m trying to put together my thoughts on what makes the most sense. My feeling here is that anytime you’ve tried to facilitate the move of something from local to the cloud, there’s gonna be some uncomfortable moments where people are like “I don’t want this. I don’t wanna log in, I don’t want any facilitation going through servers, or anything like that.” My feeling is that from a product perspective ultimately the benefits of the collaborative model and the cloud model always are big enough to justify a login, or something like that.

I also wanna be super-clear - Warp is not sending or storing any of your commands to our server. We collect telemetry, which was another thing that people were pushing back on on Hacker News, which I understand. That’s all meta data around like “Hey, did a user do a split pane, or did a user open the command palette?” and the intent is to understand how people are using the product. We don’t store any of your command data, any of your output, anything like that. We don’t wanna store it, it’s too sensitive. But… Yeah, my sense is that ultimately to get to the best product here we’re gonna need people to log in… But I will say that we are discussing this pretty actively on the team right now, so I don’t know exactly where it will land. I understand the concern, by the way.

I have somewhat of a theory, and it’s just really based upon your own words, in one case. The reason why you’ve gotten here is because you’ve looked at the landscape and you said “When I look at developers doing their thing, in their work environments, they’re using two applications.” They’re either using VS Code or something like it, or they’re using Terminal. And so when you look at those two applications - well, VS Code itself doesn’t, the last time I checked at least; maybe it’s changed, I don’t know. It’s not a daily driver for me… But the last time I checked, it doesn’t require you to log into it to begin to use the application. So I think there’s a case for – especially on the adoption front. Like, if you want to be the terminal used no matter what, if you have the need for the team features - sure. I think there’s an opt-in, and then obviously sign in with GitHub totally makes sense. But I think for adoption, just simply for adoption’s sake, if you wanna be the terminal of the future, the current terminal doesn’t require to know you.

Right.

Know your customer, you know… KYC is a big thing, I think, in this current world. KYC is a big deal.

[59:46] Yeah. So we could do what VS Code does, which is - I think the moment you have to log in on VS Code is maybe the moment you wanna use live share, or something like that… I’m speaking for myself, I think that’s a bad product experience, and I think it really limits the utility of any kind of sharing feature if you push it off until really late in the experience.

I can’t think of another sharing-based app where you don’t log in… I mean, VS Code is a good example; I just think it really makes the experience worse, and it also creates a speed bump at the actual time where I want to create the most value for people using Warp… Which is like, okay, someone wants to collaborate, and then all of a sudden you’re putting a log in front of them. That said, I have no doubt that we would get more adoption if we did what you said, Adam, if we just made login optional. I just don’t know that it sets us on the path to building a really great, collaborative, cloud-connected terminal. So we’re weighing it, is kind of the short answer…

Yeah. Well, that’s part of the journey, is ferreting that out.

Totally.

I think Jerod’s sentiment - I concur on that; that was my first thought, too. What I wanna see from the terminal of the future is the terminal, not a request to show you who I am… Which I totally understand your reasoning for, from a product standpoint.

Right.

I totally get that.

We’re gonna figure this out. This is really super-interesting.

Yeah. I mean, I think if the collaborative features existed today, then the justification existed today. If you launched with colab, and it was cloud-native immediately, and you put a little note there that’s like, “Hey, this is so you can actually do what the thing does…” But the fact that it’s for a future makes me think “This is so you can know how many people have it installed.”

I can get cynical, and I’m a pretty typical developer in that sense… Because it’s not winning me anything today. And I actually like that flow when it’s like just-in-time, when it comes time for me to use collaborative features…

You would sign in it.

“Hey, you have to have an account to do that.” Now I actually have a justification, and I’m like “Okay.” It’s not even like the GitHub sign-in thing that irked me as much as it is, like, I like to open up a terminal and see my home directory.

This is great feedback. I mean, I don’t know what we’ll do on this…

Sure.

We’re taking all the Hacker News feedback and bringing it to the podcast…

I didn’t read that thread. I did not read the Hacker News thread, I swear.

I’m just kidding with you.

[laughs]

This is all said with love. This is all said with love and respect.

Yeah, yeah.

My goal here ultimately is just to do the best thing for people using the product… So I’m totally down to hear the feedback, and I actually like hearing your viewpoint on like you wouldn’t mind a speed bump at the time of doing the collaboration. I get what you’re saying. I don’t know what we’re gonna do; it’s gonna be a spirited discussion within the team on this.

Even a short-term move - put a little note there. Just put a note up that says why. Even if it’s like, “We promise this matters, but not right now… But just go ahead and do it.” Something like that might even be – like, tongue-in-cheek about it.

That’s coming. That’ll be there within a couple days, actually.

On that note though, that would be a great spot to point your roadmap, too. Like, make your roadmap more public, if it’s already public…

Yeah.

It’s like, “Hey, this feature, and this is the dream.” Which I think is kind of what we’ve done on this show; it’s like, what’s real today for Warp, and what’s the dream? What’s the future your driving towards? I think that’s part of your narrative and your story. And if you share that with developers who are inherently not very trustworthy, inherently semi-cynical, like Jerod is suggesting here… You know what I mean?

[laughs]

If you incorporate them into your story, they’re gonna believe in what you’re doing so much more.

It’s so interesting… Because that is not my default sort of outlook, but I think it is the default outlook of a large percentage of developers. So that makes a ton of sense…

Tell them your story.

[01:03:40.28] Yeah, I agree with that 100%. And the terminal is so close to us; it’s inscrutable, it’s got a lot of problems, like you’ve stated, but once you live there, day in, day out, it’s a pretty close-knit tool. Even switching terminals is kind of a big deal. If I switch to Warp, I want it to be my terminal for N years. And if I feel like “Well, it’s tied –” and maybe we can get into the business proposition next… Because I feel like if Warp’s success is tied on the business’ success, that also gives me pause… Even knowing I can just go back to terminal.app and life would go on.

Yeah.

But I think also telling Warp’s story - not just roadmap, but also “Is this terminal.app, warp.app, is this terminal application require VC hockeystick growth?” Because as a person who’s been a developer for 20 years, I have seen so many businesses come and go, and so many tools that I love don’t exist anymore. In fact, somebody in our Changelog community Slack was just lamenting today that one of their favorite tools just disappeared. No reason why. The servers are gone, the website’s gone… Just gone. And so these are things that - you know, it’s hard to be cynical over time; not because of bad intentions or anything like that. Just like stuff fails, and then we’re left in a lurch. So some sort of sustainability story I think is also important.

Yeah. I think that the thing for that that makes the most sense, which - you know, we’re not yet open source, and I think if we were to essentially open source the client, I think that would probably go a long way towards alleviating people’s concerns around like “Is this thing gonna go away?” I don’t wanna publicly fully commit that we’re gonna do that, but it’s probably something that we’re gonna do. It’s certainly something that I think there’s a lot of – it actually aligns our users’ interests and the business interests, in a lot of ways. It gives people confidence that the app is secure, it’s not doing anything nefarious, that it’s not gonna go away…

So I think it is a thing that we will do. I don’t wanna 100% say, because we haven’t decided the strategy, the timing, all of that… But I think it’s something that makes sense for us to do.

I guess just for me to ask you as a potential user, for a second… Is open sourcing the thing that would give you the most confidence when it comes to your question here?

Yes, I think it would. I’m not sure if the client alone would give me confidence… Depending on how much becomes collaborative requirement. Like, what was the old Google Docs competitor? Etherpad?

Yeah.

Well, when Etherpad died, they open sourced it, and that was awesome… But unless there’s an Etherpad service, did it really matter? People could stand up their own. So maybe some sort of stadium… Like, “By the way, if Warp the company disappears, we’ll just open source all the things and you can do what you want.” That actually makes me feel pretty good. That’s a pretty good feeling. Like, “Okay, if they die, it’ll open source and we can do it.”

If the company goes away, we’ll give you the server, too. I think it makes sense.

Right.

Again, it also might make sense for us at some point to just let people stand up their own Warp backends. We don’t have enough in the backend right now where I think totally that makes sense…

Sure.

…but I could see a self-hosted version of Warp being something that companies want… So I guess I would just say this is all early. The concern makes a ton of sense; I think we need to figure out our story around it, and kind of go from there.

Yeah.

Hence the mountain.

[laughs] Hence the mountain.

This is gonna be a long-term thing, but it totally makes sense what you’re saying.

Yeah. On these notes then, what does it take then for the company to be successful? So you’re venture-backed… I think I read 28 million in funding, is that right? Or was it something-20-million?

We’ve raised 23 million dollars.

23 million. My bad. So 23 million in funding… Is this seed funding, or is this series A?

We’ve raised both a seed, and a series A. So the seed was in 2020, and the series A was in 2021.

Okay, gotcha. So what’s the rough total raise? I’m not on your Crunchbase, I don’t have your numbers in front of me. I’m just curious.

The total raise is 23. So that’s counting both rounds.

Okay.

Both of them.

So 23 million of funding… We want a terminal for the future, so this is a desire of the developers…

Totally.

[01:07:58.03] …at large, whether they say so or not… So obviously, that’s why you’re on this map, on the roadmap you are. Now, given that future, given that desire from us as developers, what does it take for 1) you to create the technology, and then 2) sustain as a business? What is the business’ roadmap in terms of being successful?

Sure. So the business we’re trying to build is an enterprise business. We’re not trying to build a business where we charge individual developers for using a terminal or for buying licenses… It would be much more similar to something like in Figma or Notion, where for individuals it’s totally free, and then we’re hoping to add sort of a class of features that are around collaboration, and firefighting, and securing the terminal, and customizing the terminal to a company’s internal workflows, where businesses will want to pay for their development teams to have Warp. So that’s the ultimate place that we’re trying to get to.

I think there’s definitely a future in that. I like the aspect of Notion. I’ve been using Notion a lot more… I’ve been a Notion user for a long time, but hadn’t fallen in love with it as much as more recently… And that’s just after bouncing from one tool to the next and realizing just Notion does most of what I need it to do, better than like four different tools separate.

And I like the aspect of Notion, because we have a Changelog team, or workspace, or whatever the terminology they use, and then I have a personal one. Not that I necessarily need it, because you have private, but just for that encapsulation. And I like the fact that it’s free.

That being see, I can see in the dev space where smaller teams, like Changelog, for example - we’re a pretty small team; we’re not an enterprise. We would still desire to pay a hundred bucks a month or something like that for our team. Do you have an idea of what your team sizes might be? I’m curious how that maps onto the actual plans.

Yeah, I think the smallest team I could imagine using it would be two… But sort of how much we would charge, what the exact feature set would be… Basically, the mechanisms of this are something that we’re trying to figure out over the next six months. But yeah, I also think some of the teams stuff that we’re doing would probably be free as a way of helping people understand the power of it… So it’s a little bit TBD. Our focus right now is not so much on monetizing as it is on just getting the basic user experience to be something that people love and wanna share.

Yeah, I think you have to start there. You’ve got to start with literally the terminal of the future, making it accessible to everybody, invitation and everyone can use it. Obviously, it’s Mac-first right now. Linux is likely next…

Yup.

…then web-native, and then Windows. But I think that’s the better approach, because there’s a lot of virality in the way Dropbox even rolled out. Workflows, I can imagine, will be a quite viral feature for you.

Yeah.

I see Commands.dev I believe is something you have that it’s sort of pulled from…

Oh, yeah.

I don’t know what that is necessarily, but…

It’s a web-based version of looking up all our workflows.

Right. So I think there’s gonna be a virality to that which will help you with adoption, which will help you with marketing, basically… “Who are you, why should I use it, is it truly the future?” And I think that given that, I think you’ll get there. I also think it’s quite smart to focus on the enterprises being the boon of the funding and success, because I think that’s gonna be the easy grab, honestly.

Cool.

Zach, we’ve taken a lot of your time… Is there anything we’ve missed, anything left on the table? Obviously, this is the start of Warp’s story, if you haven’t been paying attention yet… It is, and so there’s lots to come. But for this conversation, anything left unsaid?

No. Just thank you guys for having me on. From my perspective this was a super-interesting conversation; it’s good to hear your guys’ feedback as users as well. I guess one other thing I would wanna get across is - so Warp is growing; we’re hiring. We have a ton of interesting engineering challenges that folks are working on. We’re a remote-first company, so if any of your listeners are interested in what we’re doing, I would encourage them to check us out at Warp.dev.

Very cool. Well, here’s to the terminal of the future. Hopefully what you’re building actually is that. I see a lot of promise and possibility, so hopefully all of this comes to fruition… And a year or two from now we’re having a different conversation, which is like “Okay, you’re winning. You’ve won. What’s next?” I look forward to that.

Let’s do it! Yeah, I love that.

Zach, thank you so much, man.

Thank you so much, guys.

We appreciate it.