1. Meet developers where they are.  This means Warp should be backwards compatible. A developer using it for the first time should be at least as productive as they were in their old tool. Practically speaking, this means Warp should work seamlessly 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 legacy products 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 want 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. We believe there is value in an integrated, out-of-the-box experience that helps all developers be more productive immediately. Rather than having to customize Warp before you can work efficiently, we believe the best experiences are productive by default. Warp should always strive to ship an experience that “just works” while still supporting a wide range of customizations for developers who want to tweak the app to suit their needs.
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 app 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 where developers write and distribute text based apps. We should aim to support command-line app developers, as well as developers who want to extend and improve Warp itself. We should always think through extension points and APIs as we build Warp so that as much as possible Warp is extensible by developer community.
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 for the cloud in a developer’s daily workflow beyond just cloud source control. For example, why doesn’t your terminal configuration follow you across machines? Why can’t you transfer a CLI session to the browser so you can keep working on the go? Warp aims to add useful, secure, cloud-functionality that ups every developers productivity.
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 Slack. 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 sharing, in-terminal runbooks, and more.
8. Use AI to solve real problems. Generative AI is transforming how developers work, and the terminal is an ideal interface to apply it. Since the terminal is text based, and LLMs speak text fluently, we can use AI to make the terminal much more accessible and powerful. Our approach to using AI is the same as using any other technology: we want to work backwards from user problems and ship solutions that meaningfully improve developers lives. That means not over-indexing on flashy demos but integrating AI seamlessly into Warp where we think it can benefit engineers doing real tasks today.
9. ***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.
10. 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)