Half the scope disputes we see start with one of these three words meaning different things to the two people in the room. They are not stages of polish on the same artefact. Each answers a different question.
A wireframe answers: what goes here, and in what order?
Grey boxes, real labels, no colour and no craft. Its whole value is that it is quick to argue with. If a wireframe looks finished, people review the visuals instead of the structure, which defeats the purpose.
A mockup answers: what does it look like?
Pixel-accurate, final type, final colour, real content. It is what you approve, what you hand to development, and what you should never use to test whether something works, because a mockup cannot fail, because nothing in it responds.
A prototype answers: does this work?
Clickable, stateful, close enough to real that a person can attempt a task and get stuck. Prototypes are the only one of the three you can put in front of a user and learn something reliable from.
A mockup gets you a decision. A prototype gets you a fact.
Which to ask for
- Unsure what the product should contain → wireframes, in volume, quickly.
- Structure agreed, need buy-in or a build-ready spec → mockups.
- Structure agreed, but a risky flow nobody can predict → prototype the flow, test with five people, then mock it up.
- Selling an idea internally → prototype the one path that makes the argument. Nothing persuades like a thing that moves.
The order that wastes the least money
Wireframe broadly, prototype the risk, mock up what survives. Teams that mock up first spend their best craft on flows that research later removes.