minimal-first-implementation

The minimal correct version approach in software engineering designs the smallest functional feature iteration while enforcing exhaustive case coverage and fail-closed behavior. It prevents overbuilding by returning typed errors for unimplemented paths.

Avoid over-engineering features by defining the core path and implementing only that functionality first. Return typed errors for any unimplemented variants instead of guessing scope, and extract shared packages only after a second consumer exists.

Extract shared packages during early-stage design only after a second consumer for the shared logic exists. Premature extraction leads to overbuilding; ship the minimal correct version first and wait for actual duplication to justify abstraction.

Fail-closed error handling returns typed errors for unimplemented feature variants instead of allowing silent failures. This exhaustive decision logic ensures all possible paths are explicitly addressed upfront, maintaining system correctness even in an incomplete state.

Yes, lean scope discipline applies to extracting shared components by enforcing a second-consumer rule. You ship the minimal implementation first, then extract the shared package only when actual duplication occurs across software projects.

Shipping the smallest correct version requires upfront exhaustive decision space definition, which adds initial design overhead. It is limited by the need to define all variants before implementation, making it less suited for truly exploratory prototypes lacking clear scope.