A design file is not a specification. It is a picture of the intended outcome in the states someone remembered to draw. The distance between those two things is where estimates go wrong, and it is measurable in about two hours of careful reading.
Structure before pixels
The first question is not what the site looks like. It is how many distinct templates exist. Eleven frames often turn out to be four templates and seven content variations, which is a much smaller job. Or three frames turn out to be nine templates once you notice the blog, the archive, the single post, the category page and the search results are all implied but undrawn.
Counting templates properly, and agreeing the count in writing, resolves more disagreement than any other single step.
The twelve checks
Template count, agreed explicitly rather than inferred.
Breakpoints actually designed, versus breakpoints we will be interpreting.
Interaction states: hover, focus, active, disabled, loading.
Form validation: what an error looks like, and where it appears.
Whether the copy is final, and who can approve a change to it.
Interaction states: hover, focus, active, disabled, loading.
Image ratios, and what happens when the client uploads the wrong one.
Font licensing for web use, which is more often missing than present.
Icon source: a set with a licence, or drawn shapes we will need to export.
Anything animated, and whether a reference exists or we are inventing it.
Third-party embeds: forms, booking, chat, maps, payment.
Accessibility intent: contrast ratios in the palette, focus treatment, heading order.
Most files fail on four or five of these. That is normal, and not a criticism of the designer. Design files are made to communicate intent to humans, not to be compiled.
Every unanswered item on this list is either a question now or a change order later. Now is cheaper for everyone.
What to do with what you find
Do not send a list of complaints. Send a document with three columns: what is missing, what we will assume if nobody tells us otherwise, and what it costs if the assumption is wrong. Assumptions are the important column, because they let the project proceed without waiting for perfect information.
An agency reading that document learns two things. That the estimate is grounded in the actual file, and that when something ambiguous comes up during the build, it will be raised rather than guessed at. That is most of what they need to know before handing over a client.