Opening the book…
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.
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 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.