Efficient by design, not by accident

What this means in practice

Treat efficiency as a deliberate design constraint, not an afterthought and not a reflex to micro-optimise.

Cost is an input alongside correctness and delivery speed, including cloud spend, partner costs, and human time.

Teams should optimise where it matters, based on evidence, while defaulting to clarity and maintainability unless performance is a stated requirement.

Why this matters

Hardware is finite and paid for, and inefficient systems become expensive at scale. At the same time, premature micro-optimisation often slows delivery and increases complexity for little real-world gain. A measured approach ensures teams invest performance effort where it delivers meaningful impact, reduces operational cost, and avoids building brittle systems that are hard to change.

Practices that meet this principle

• Make efficiency a documented non-functional requirement where it matters (latency, throughput, memory, cost per request)

• Measure before optimising, and use profiling to find real bottlenecks during development

• Prefer readability and maintainability first, unless performance is explicitly the requirement

• Optimise the largest cost drivers (for example: chatty calls, inefficient queries, large payloads, unnecessary allocations)

• Use budgets and guardrails (for example: SLOs, rate limits, payload limits, cost alerts)

• Re-test after changes to confirm improvements and to prevent regressions

Validation

A project meets this principle when:

• Performance and cost targets are explicit where relevant, and are validated with measurements

• Profiling and metrics are used to prioritise optimisation work

• Changes that improve efficiency are backed by before and after evidence

• The codebase remains maintainable, and performance work does not introduce unnecessary complexity

• Resource usage and cost are monitored in production with alerts on key regressions