Payment Milestones and File Ownership: The Two Clauses Jewelry Buyers Skip

Most custom jewelry disputes are not about craft. They are about two things nobody wrote down before the first payment: when money moves, and who owns the files that make the piece reproducible. Both are boring. Both are where relationships end badly.

Milestones should be events, not dates

A payment schedule built on calendar dates protects nobody. “Fifty percent on order, fifty percent before shipment” tells you when money leaves and nothing about what has been proven. A schedule built on verification events does the opposite: each transfer is tied to something you can inspect — a manufacturability read of the drawing, an approved sample, a first production piece measured against it, a pre-shipment record.

The practical test is simple. For every payment, ask what evidence do I receive before I release it? A workshop with real gates answers with documents: dimensional records, photographs under consistent light, a first-article comparison against the retained sample. A workshop that cannot describe its own evidence package is asking you to pay against a promise.

File and tooling ownership is the clause that decides whether you can leave

The CAD file, the drawing with its revision number, the wax or rubber mould, any jig made to hold an awkward section — these are what make your piece reproducible by anyone. If ownership is never stated, the practical position is that whoever holds them controls your product, whether or not that was the intention. Four questions settle it, and all four belong in writing before the first payment: who owns the files; do you get the drawing and the revision history, not just the finished piece; what happens to moulds and jigs if the relationship ends; and may the supplier run the same tooling for anyone else.

The answer to that last one should be no. A tool built for your part runs your part — this is the same conversation as design confidentiality, applied to the physical production assets rather than the drawing.

Changes need a version, not a message

Every project changes. The failure mode is not the change itself but the record of it: the drawing says one thing, a message thread says another, and the approved sample is a third. When a revision is agreed, it should come with a new version number, a note on what changed, and a note on what the change affects — a dimension, an operation, a stone, a cost. This is not administration for its own sake; it is what makes the next order reproducible and the current one arguable only in the right direction.

The commercial version of the same rule: if a change affects price, it should be confirmed before the work that change triggers, not discovered in the final invoice. A quotation with its assumptions written down is what makes that conversation short.

Two payment checks that cost nothing

Pay the legal entity that signed the contract, and check that the account name matches it. A request to pay a different company, a personal account, or an entity that appears nowhere in the paperwork is a stop-and-check moment, not a formality. And keep tooling or development payments on their own line rather than folded into the product price — separate lines keep ownership traceable when the project grows.

Also worth agreeing early: the prototype or development scope. What a prototype fee covers is frequently misread on both sides — buyers expect broad experimentation, workshops price a narrower scope — and the misunderstanding is cheaper to close at the start than after two revision rounds.

How we run this side of a project

We tie each stage to something you can see: a manufacturability read before anything is committed, an approved sample that stays as the reference, a first production piece checked against it, and a pre-shipment record. Revisions get a version number and a written note on what the change touches. Your drawings and confirmed versions stay yours. We would rather agree the structure in writing while it is still a small order than negotiate it later, when it matters.