There's a common misconception in software development that quality is something you "polish" at the end of a project. You build the thing, then you make it good. We've learned the hard way that this approach almost never works.
Quality is a design decision
Every product decision is also a quality decision. The structure of your data model, the words you choose for an error message, the latency you're willing to accept on a core action — these all compound over time. Quality isn't a final coat of paint. It's baked into the foundation.
We ask a simple question at every design review: "Would a thoughtful person using this feel respected?" It sounds abstract, but it's surprisingly clarifying. It rules out sloppy defaults, confusing labels, and the kind of friction that makes you feel like the software doesn't care about you.
The 90% problem
Most software gets to 90% of what it needs to be and stops there. The last 10% — the edge cases, the subtle animations, the way errors are communicated — is where the experience is really made or broken. We try to resist the pressure to ship at 90% whenever we can.
Quality as culture
Ultimately, quality is a cultural value. It has to be something the whole team believes in and holds each other to, not just a checklist maintained by QA. We'd rather ship less, more carefully, than ship fast and apologize later.
