Rule 3 of 38 · Chapter I — Start With the Problem
Prototype the riskiest part first
Why this rule exists
Risk is not spread evenly across a project. One or two unknowns usually decide whether the whole thing is feasible, and everything else is comparatively routine. Building the easy parts first feels productive but leaves the real question unanswered until late, when a bad answer is most expensive. Prototyping the riskiest part first buys information when it is cheapest.
In practice
List the parts by how likely they are to sink the project: unproven integrations, performance ceilings, unclear algorithms. Take the scariest one and build a throwaway spike that answers the specific question, nothing more. Timebox it. If it fails, you have learned that for a day's work instead of a quarter's.
When it doesn't apply
When the risky component is well understood by the team or backed by a proven library, spike something else. If the risk is external and cannot be resolved by code, a prototype will not help; reduce it through contracts or conversation instead.