Permanent page / subject to revision
Working
principles.
Not rules. Reminders. A small set of beliefs that should be tested by the products I make.
- 01
Build to Learn
Use real product work instead of disconnected tutorials. A question becomes more honest when it has to survive contact with code, data, production, and another person.
- 02
Make States Explicit
Loading, failure, permissions, offline behavior, and degraded states are part of the product. Name them before styling the happy path.
- 03
Own the Runtime
Understand rendering, subscriptions, data flow, playback, and lifecycle. The interface includes what continues working when the surface is no longer visible.
- 04
Operate What You Build
Instrumentation, monitoring, rollout, support, and repair are part of design engineering. A feature is not complete merely because it merged.
- 05
Preserve Canonical Ownership
New interfaces should project existing systems rather than accidentally duplicate them. Product coherence depends on knowing which system owns the truth.
- 06
Prefer Evidence
Use profiling, analytics, tests, logs, and observation to guide decisions. A strong opinion should become sharper when reality disagrees.
- 07
Native Is a Specialization
Swift extends the web and systems foundation rather than replacing it. Platform craft is strongest when the underlying ownership model is already clear.
- 08
Taste Includes Reliability
A beautiful interface that behaves unpredictably is not well designed. Recovery, latency, accessibility, and trust are part of the aesthetic.