These principles express Rei’s default approach as Katteke’s founder and final product decision-maker. They are decision tools, not slogans: when principles pull in different directions, the choice and its reason should be documented.
Keep it simple
Prefer the smallest design that solves the real problem and remains understandable. Remove accidental layers, configuration, dependencies, and ceremony. Simplicity does not mean skipping necessary security, recovery, tests, or documentation.
Compose like Unix
Give components one clear responsibility, predictable inputs and outputs, useful exit states, and a way to combine with other tools. Stable contracts matter more than forcing every capability into one process or repository.
Lean, lightweight, and fast
Resource use and latency are product qualities. Measure before optimizing, keep idle cost low, and make common paths quick. A smaller system is preferred when it is also reliable and maintainable.
Rust first, not Rust only
Rust is the default for Katteke-authored systems components because it combines performance, memory safety, strong tooling, and explicit interfaces. It is not a loyalty test.
Choose another language or tool when it is clearly simpler, safer, more maintainable, or more efficient for the task. Record a durable exception when it affects architecture or long-term ownership. The desired outcome is a good system, not a maximum Rust line count.
CLI and API before GUI
Administrative workflows should first exist through stable, scriptable primitives with machine-readable input and output. A web, terminal, or native interface should call the same application contracts instead of becoming a separate source of truth.
Human commands should be memorable and forgiving. Advanced flags may exist for automation, but routine work should not require a wall of punctuation or hidden knowledge.
Modular by default
Products and integrations should behave like useful building blocks. A customer may choose one module without buying or operating an entire suite. Full-suite use should improve integration, not create a hidden requirement.
Optional integrations must fail clearly and leave standalone behavior intact. Customer-specific configuration belongs at the edge, not hard-coded into the general product.
Open standards and accountable freedom
Favor documented formats, exportable data, replaceable providers, and auditable behavior. Avoid lock-in as a business strategy. Katteke’s moat should come from accountable builds, operations, support, migration, training, and expertise.
Evidence over appearance
State whether something is current, planned, experimental, or unavailable. Do not use legal, security, compliance, performance, or certification language beyond the evidence. When evidence changes, update the documentation and the decision that depended on it.