Simple software is not small because it lacks ambition. It is small because every part has to justify the attention it asks for.
The longer a product lives, the more valuable its defaults become. A good default lets a team act without a meeting. A bad default turns every feature into a negotiation.
1. Start from the work
The product should describe the work before it describes itself. If a page begins with internal vocabulary, the user has to translate before they can decide.
2. Prefer fewer moving parts
Every new integration, setting, and workflow creates a maintenance promise. Add them when they reduce the total burden, not when they make a demo look complete.
3. Make ownership visible
Someone should be able to open the repository and know where a decision lives: content in content, shared patterns in the theme, product-specific behavior in the product.
4. Keep the system explainable
Good software can be taught. If a feature needs too many exceptions to explain, it is usually hiding a design debt.
5. Ship in reviewable slices
A useful change should be easy to inspect. The smaller the slice, the easier it is to understand the intention, test the behavior, and reverse the decision later.
6. Write things down
The note after the build matters. It keeps future work from repeating the same search, the same debate, and the same mistake.
7. Let calm be a feature
Serious work is already noisy. Software should lower the temperature, not compete for attention.
Related Notes
Continue through the same thinking system.