1. Meet developers where they are.  This means that our terminal should be backwards compatible. A developer using it for the first time should be at least as productive as they were in their old terminal. Practically speaking, this means we should aim to create a POSIX-compliant terminal that works with developers’ existing shells, scripts, and key bindings. When we do innovate, features should be designed with compatibility in mind - typically we should try to provide an on-ramp or import path. We think of this as “building a bridge” from the legacy terminals to Warp.
  2. Keep the power, but fix the UI. We don’t see any reason why the terminal can’t have a more modern, intuitive interface, while maintaining the power of a primarily textual, keyboard driven experience. If a user wants to use the mouse to position the cursor, why not support that? Why not have a native autocomplete and search experience? Our goal is to create the UX that best supports what developers use the tool to accomplish, and we are pragmatic about whether that UX is character based or pixel based and whether the input mechanism is the keyboard or the mouse.
  3. A great out-of-the-box experience. There are many different plugins, themes, and open-source projects that improve aspects of the CLI; e.g. tmux, mosh, and powerlevel10k. Each has its own install process, configuration scheme, update mechanism and more. Many developers end up using a very basic and underpowered version of the CLI because they never discover, configure or learn these tools. We believe there is value in an integrated, out-of-the-box experience that helps all developers be more productive immediately.
  4. Build for speed. One of the great attractions of working in the CLI is that if you master it, you can work very quickly. That’s only true though if the underlying terminal is fast. We are building Warp on the fastest possible stack. On desktop: a pure Rust app that goes directly to the GPU for rendering. On the web, a WASM app that uses WebGL.
  5. Build a platform. Most developers will experience Warp as a terminal app, a product they launch and run. However, the command line is more than an app, it’s a platform, much like iOS or Windows. It has (primitive) mechanisms for discovering apps, installing them, running them, but it lacks many of the affordances of modern platforms, like an app-store, a unified way of securely installing and removing apps, a well defined API for developers to configure the runtime environment, and more. While we are starting by focusing on the terminal app and experience, we eventually want to build the best possible CLI platform.
  6. Leverage the cloud. The basics of computing have changed since the advent of the CLI, and no change has been more profound than the rise of the internet. Once you start to think about it, there are a lot of leverage points: why is shell history limited by your local hard-drive? Why doesn’t your shell configuration follow you across machines? Why can’t you transfer a CLI session to the browser so you can keep working on the go?
  7. Build for teams. Developers today work in teams on shared projects. Because of this, most applications developers use are collaborative in one sense or another. Github is a good example, as is VSCode live session sharing. And yet the CLI is still primarily a single-user tool, with collaboration facilitated by copy/paste, screenshots, and screen-sharing, rather than a true multi-player experience. We believe that CLI-based teamwork is a very powerful concept, extending beyond google-docs real-time collaboration, to facilitating asynchronous workflows like command-reviews, shared devops terminals and more.
  8. ***Build for everyone.***The CLI traditionally has a bit of a mystique around it; developers feel like hackers when they use it, and there’s almost a rite of passage in conquering its idiosyncrasies.  We believe that the CLI should be more accessible, more humane, and more useful to all developers.  Too many are turned off by the intimidating UI.  Many aspiring developers have their first experience using the CLI (it’s how they set up development environments), and that first experience is often very negative because the interface is so hard and creates so much incidental complexity.  We want to fix this and make a modern CLI for all developers.
  9. A meta point: build for the long-term. In order to deliver on the above, we need to build on a solid foundation. Whenever there is a question of whether to build a short-term solution where we cut corners on the tech vs. a solution that might take longer to build but improves our underlying technical capabilities and gets us closer to the ideal product experience, we should bias towards the harder, longer-term solution. We will take calculated risks to get to what we believe is the best product experience, and we will be OK with those risks sometimes not panning out. As with all our other principles, we will be pragmatic in applying this one.

[Prioritization Principles at Warp](https://warpdev.notion.site/Prioritization-Principles-at-Warp-99d6f81efe264ab0920931b98612b569)