Comparisons

Pairs engineers genuinely confuse — goal and implementation, MVP and bad prototype, prototype and spike, reversible and irreversible. Neither column wins; what decides is the problem. Each record leads with the confusion, because the confusion is what it costs.

Dependency-first vs value-first ordering

What people get wrong about this pair

They are argued as philosophies when they are answers to different questions about different pieces. Dependency-first is right about *order* — you cannot build checkout with no order record — and wrong about *completeness*, because the order record checkout needs on day one is three columns. Value-first is right that the slice corrects the foundation before it hardens, and wrong when it produces a demo that cannot be extended because the foundation was skipped entirely. The strongest form of dependency-first is a platform for several teams, where the foundation is the product; the strongest form of value-first is a greenfield product where nobody yet knows what the foundation must support. The synthesis that works most of the time is a walking skeleton — dependencies at the thickness the first slice needs — and then value.

Dependency-first — build what everything else needs before what the user sees
Use it when

When the dependency is genuinely load-bearing, cheap and well understood — products must exist before a cart can hold them — and when a hard dependency has no thin version.

Value-first — build the user-visible slice first and let it pull in the dependencies it needs
Use it when

When the requirements are moving, when the slice will teach you what the foundation must be, and when the team needs something demonstrable to keep the conversation with stakeholders honest.

AspectDependency-first — build what everything else needs before what the user seesValue-first — build the user-visible slice first and let it pull in the dependencies it needs
First thing builtThe schema and the core servicesProduct page end to end
First demonstrable momentLateEarly
RiskFoundation built for requirements that changeSlice that cannot be extended
Strongest caseA shared platform with many consumersA greenfield product with moving requirements
What it gets rightOrderThickness
Working synthesisDependencies at skeleton thicknessThen value-first slices