Observable. Observability might not be what you think it is. More important even than security, because with poor observability you don't know if you're secure, you won't know you've been hacked.

Secure. Security, including not being taken over or shut down, but also into aspects like not letting your users shoot themselves in the foot with weak passwords, sharing too easily, etc.

Good DevX. Here because without it, every effort to build, maintain and improve any of these quality factors is friction-filled. And things that are high friction get high story points on the tickets and are very hard to prioritize. Some of the key elements of good developer experience include code organization, refactorability, iteration time (ideally hot reloading), good developer environment, reliable & fast CI, good internal tooling.

Resilient. Resiliency means it works as close to expected when things get off the happy path. Partial failures don't take down an entire page. Things still work when a secondary vendor is down. Maybe more importantly, even permanent actions are repairable or reversable. Actions are idempotent, meaning they can be retried with impunity if they fail, or the button just spins and spins and then you refresh. UIs support undos, retries. Error messages when things do get off the path are helpful.

Testable. I have really controversial opinions about testing. I don't believe in it - at least not the way it's employed in many shops which is as a hammer that is required on any change. Most tests I've seen in my career test the wrong things. Many tests I've seen make the code way too rigid for the maturity of the system they cover and therefore they break whenever the code is intentionally changed. All tests are expensive to write and come with a cost to maintain and a cost to run in CI. Lord help you if (when) you start writing asyncronous tests, welcome to the special hell that is The Tests Are Flaky Again.

Nonetheless, I do write tests. Unit tests are actually incredible, especially in a stateless paradigm like functional programming. Extracting and isolating critical, brittle logic into its own module and then testing the heck out of it is a great way to enable confident changes for the lifetime of the system.

Scalable. This means can the software withstand orders of magnitude increases in consumption and/or data volume. Often software works very well in local dev, where you might have 100 of a thing and you're the only one hitting your endpoint. Shared non-prod envs can usually expose you to 1,000 to maybe 10,000 of a thing and a few consumers. It's really hard to reason about and test realistic traffic. There's a whole book to be written about the subtitles between smooth, ramping traffic - like retail shoppers during a day - and bursty, high-volume-at-once traffic like an API consumer fetching your entire catalog at once.

Accessible. This means a11y, but it also means _can humans use the interfaces effectively_. Note from the future of 2025: this is becoming more important with agentic software reading and using your apps, and might eventually make its way above Testable or even Resilient._

Performant. Last only because something had to be. Ill-performant software drives me crazy. And, if you had to sacrifice anything on this list? For me it would have to be performance - up to a certain point, of course, a point located around the order of magnitude where your performance problems are creeping into the accessible, scalable and resilient buckets anyway.