Policy : Minimise Inventory and Overproduction

Commitment to Building Only What’s Needed
We believe that unshipped code, unused features, and over-engineered systems are forms of waste. By focusing on validated needs, iterative releases, and tight feedback loops, we reduce excess inventory and avoid the cost of overproduction—technical, financial, and cognitive.

What This Means
We build only what we can validate, ship in small increments, and avoid carrying excess code, data, or architectural complexity. Teams are encouraged to solve for today, not anticipate all possible futures. Inventory in the form of unmerged branches, unused features, or oversized systems is seen as a liability.

Our commitment to minimising inventory and overproduction is built on:

• No Speculative Features – Features are only built when backed by clear, validated user needs. Hypotheses are tested early, and assumptions are challenged before committing to code.
• Frequent Merging to Main – Teams merge code frequently into main branches to reduce long-lived feature branches and the associated risk of integration debt.
• Minimal Viable Data Collection – Telemetry, logs, and metrics are collected purposefully. We avoid collecting or retaining data “just in case” without a clear reason and lifecycle policy.
• Right-Sized Architecture – Architectural decisions are made in proportion to current needs. We avoid building speculative abstractions or solving imagined scale problems too early.
• MVPs Over Big Designs – Minimum Viable Products (MVPs) and iterative delivery are preferred over large, upfront designs. Early feedback is prioritised over early completeness.

Why This Matters
Overproduction hides work in progress, delays value realisation, and increases the cost of change. Unused features become technical debt. Unmerged code increases rework. Building too much too soon undermines agility. By minimising inventory, we improve feedback, reduce risk, and accelerate learning.

Our Expectation
All teams must avoid speculative build-up and excess complexity. This includes regularly merging code, designing for iteration, and making data and architecture decisions grounded in validated needs.

To support this policy, teams will be guided by standards for trunk-based development, MVP planning, telemetry governance, and lean architecture. By minimising inventory and overproduction, we deliver value sooner, with less waste and greater clarity.