Keep it as simple as possible whilst still meeting the required outcomes

What this means in practice

We prefer solutions that are easy to understand, change, and operate. We reduce moving parts, avoid cleverness, and choose the simplest approach that meets the need. We treat simplicity as a design constraint throughout delivery.

Why this matters

Simple systems are cheaper to build and run. They reduce defects, make onboarding faster, and improve delivery speed over time. They also make it easier to reason about risk, performance, and change.

Practices that meet this principle

• Write clean, readable code that prioritises clarity over cleverness

• Remove duplication and unnecessary abstractions

• Prefer small, composable components with clear responsibilities

• Use diagrams to explain architectures and flows when it improves understanding

• Prioritise working software over extensive documentation, while keeping essential docs current

• Prototype to validate assumptions before committing to complex builds

Validation

A project meets this principle when:

• A new team member can understand the core design and main flows with minimal guidance

• Changes can be made without widespread knock-on effects

• The solution avoids unnecessary layers, services, or framework complexity

• Operational ownership is clear and the system is straightforward to support