How Wispr builds: our operating principles

A note on how we build

We’ve put off writing Wispr’s operating principles for longer than either of us would like to admit. Partly because we have an allergy to anything that feels like corporate process, and partly because it’s really hard to write them in a way that’s useful.

But Wispr is growing, and decisions are being made across more people and teams. We want the thinking behind how we build to be easier to share, so everyone has the context to make good decisions independently.

These principles are a first attempt at doing that. They come from building Wispr together: what we got wrong, what we changed our minds about, and what we’ve learned from people here who care deeply about the product and our users.

We expect to argue about them and revise them as we learn. But that’s the point. They’ll grow with us.

Pursue the unreasonable

We want interacting with technology to feel as natural as talking to a close friend. It should understand an incomplete thought, learn how someone works, and — with earned trust — help carry the work forward.

Our goal is to build the first voice interface used every day by a billion people. That raises the bar for what our product has to do. Wispr must work across languages, devices, applications, abilities, and environments. It has to respond before someone loses their thought and become personal without becoming intrusive.

We also recognize that we cannot solve all of those problems at once. So we are truth-seeking, asking what is limiting the experience the most right now, working on that constraint, and reassessing. Working this way lets us hold two views at once: what Wispr could become, and what needs to get better next.

Build to discover what is true

When we first explored voice, we built roughly a hundred prototypes. A browser extension showed us that voice needed to work wherever people typed. A more capable desktop app taught us that more features didn’t matter if the product couldn’t keep up with the speed of thought.

That became the pattern: each experiment gave us a sharper understanding of what Flow had to become. It needed to work in every text box, respond quickly, and produce language people could use without stopping to correct it.

We’ve learned to treat experiments as a way to turn assumptions into evidence. We start with a clear point of view, define what would change our minds, and look closely at what actually happens. Being wrong is useful when it gives us a clearer understanding of what to build next.

Let product taste set the technical frontier

Our current working definition for product taste is knowing how an experience should feel, then doing the work to make it feel that way.

Two principles shape how we apply it:

• Great products change behavior. A capability matters when it becomes dependable enough to become a habit. We meet users in their existing workflows and deliver value before asking them to change.
• Simplicity is absorbed complexity. Users shouldn’t have to understand our models, infrastructure, or failure modes. The product should feel effortless because the system handles the complexity behind it.

That simplicity takes work across the whole stack. For voice to respond within 500 milliseconds, every layer, from hardware and networking to model serving and native clients, has to fit within a single latency budget. Accurately attributing speakers in a meeting may require combining acoustic diarization, participant rosters, accessibility signals, microphone input, and system audio.  In both cases, users experience one simple outcome because we optimize the system as a whole.

We have to earn the right to do more for our users

As AI systems gain more intelligence and autonomy, the bar for reliability rises with it. A dictation error is irritating, an agent that remembers the wrong thing feels unsettling, and an system that acts on the wrong interpretation can break trust entirely.

We believe trust is earned in sequence: first the product understands, then it adapts, remembers, and eventually acts. This shapes what we choose to build. We ask not only whether the product can do something, but whether it should do it yet. Does it have enough context? Is the action reversible? Should it infer, suggest, clarify, confirm, wait, or remain silent?

The goal isn't to show the upper limit of the system's capabilities. It is to increase what our users can comfortably trust it to do.

Build momentum, not motion

A company can look busy while barely moving. Every new project divides attention and adds decisions, meetings, and maintenance. We think of speed as the rate at which important work improves.

That doesn’t always mean shipping sooner. Sometimes the fastest path is a rough prototype. Other times, it means spending weeks resolving the constraint behind a recurring failure. And often, it means letting a good idea wait so the most important work gets the attention it deserves.

We judge the quality of our work by whether it teaches us something important or meaningfully improves the product.

Be kind enough to tell the truth

We want to build with people who hold a high standard and care enough to help one another reach it. Honesty doesn’t always feel kind in the moment. It can be easier to hold back a concern, soften it, or wait until the outcome has already been decided. But by then, the truth is far less useful. Directness without care isn’t useful either. We should be able to challenge someone’s reasoning without making them feel smaller. When someone raises a concern, we should treat it seriously and be willing to change our minds.

We’d rather reach the right answer together than win the argument. And, when we’re working intensely toward ambitious outcomes - we might as well have fun doing it.

Always stay close to the user’s feeling

When we build, it’s an opportunity to make our users feel something. With Flow and Notetaker, we want our users to remain inside their thoughts and conversations. And when this breaks, they notice, even if they can’t explain why. A pause interrupts their thought, and an unreliable transcript makes them double-check the product instead of trusting it.

Building around this feeling means taking those moments seriously. If the metrics look healthy but the product still feels wrong, there is more for us to understand.

A final note: We won’t always get this right. But writing these principles down gives us something to return to, so we can always find our way back.

—Tanay and Sahaj