Optimise for the decisions ahead
Architecture should reflect the changes a business expects: a new customer type, a new channel, tighter access control or a higher volume of work. Avoid generality that no current decision needs, but avoid shortcuts that turn a known next step into a rebuild.
Make boundaries intentional
Clear boundaries between responsibilities help a team change one part without guessing about every other part. They can be small and pragmatic: a stable contract, a contained module or an explicit data ownership rule.
Document the reason, not just the result
A future engineer can read code, but may not know why an option was rejected or what risk the design was intended to control. Brief decision records preserve that context and make later change more thoughtful.
