If the ZIP contains anything that could be misunderstood, add a README.
That is the short answer. A custom 3D printing quote does not need a README when the package is one clearly named file and nothing else. Once the ZIP starts mixing CAD exports, STLs, drawings, screenshots, revision folders, or alternate options, a small text note can save the buyer and the shop from pricing the wrong file, missing a key instruction, or treating reference material like production intent.
Use a README when your ZIP includes:
- more than one candidate quote file
- photos or screenshots that support the job but should not control pricing
- old revisions, alternate options, or prototype-versus-production files
- special notes on quantity, material, finish, hardware, labeling, or packing
- anything that would take more than ten seconds to interpret correctly
Request a quote here once the controlling file, extra references, and next-step notes are obvious.
If you are building out a stronger file handoff, pair this page with the ZIP-file packaging guide, the multiple-file-versions guide, and the controlling-file guide for shared folders.
When a README is worth the extra minute
A README becomes valuable as soon as the file package stops being self-explanatory. Many quote delays happen because the files themselves are not unusable; they are just packaged in a way that leaves too much room for interpretation.
A README is usually worth adding when:
- you are sending more than one format for the same part, such as STEP plus STL
- you are attaching reference images so the shop can understand the install area or damage
- you want one option priced first but are also attaching alternates for later discussion
- you have mixed prototype and production context in the same ZIP
- the filenames are clear to your team but not clear to an outside shop
In those situations, the README is not filler. It is the shortest path to a cleaner quote.
When you probably do not need one
You can skip the README when the package is extremely simple:
- one approved quote file
- one obvious quantity request
- no alternate revisions
- no supporting photos or drawings that might be mistaken for control files
- no special packing, labeling, or fit notes
If that is the whole job, a normal quote message may be enough. Do not force extra process into a clean handoff.
What the README should actually say
The note should help the shop answer four questions fast:
- Which file controls the quote?
- What are the other files for?
- What key requirements matter for pricing or feasibility?
- What should happen next?
That is usually enough. You do not need a formal specification packet unless the job is much bigger than a standard quote request.
| README section | What to include |
|---|---|
| Controlling file | Name the exact file to price first and make it hard to misread. |
| Reference files | Explain which files are images, drawings, prior revisions, or alternates only. |
| Key quote notes | Call out quantity, material preference, fit sensitivity, finish expectations, deadlines, or hardware context. |
| Decision path | Say whether you want one main quote, separate option lines, or a sample-first recommendation. |
A simple README example
Please quote Bracket_REV-D.step as the controlling file. The STL is included only as a quick mesh reference. The JPG photos show the install area and should not control geometry. Please quote 25 units in black PETG and flag whether this job should start with a sample before the full run.
That is enough structure for many real jobs. The shop knows what to price, what to ignore, and what buyer questions matter next.
Where buyers get into trouble without a README
Problems usually show up when a ZIP is trying to do too many jobs at once. For example:
- one file is the current model, another is an old export, and nobody says which is live
- the ZIP contains a prototype folder and a production folder, but the quote request does not say whether both need pricing
- photos explain the damage or fit risk, but the filenames are so vague the context gets lost
- the buyer expects special bagging, labels, or kits, but those details live only in someone's head
Those are exactly the cases where a small README outperforms a longer back-and-forth later.
README versus full quote email
You can still write a normal quote email or form message. The README does not replace that. It travels with the files so the package stays understandable even if it gets forwarded internally, downloaded by another team member, or revisited later.
Think of the README as the note that keeps the ZIP from becoming detached from the meaning of the ZIP.
What if the package contains alternates?
Then the README should say whether those alternates are:
- reference only
- backup options
- deliberate option A and option B files that need separate quote lines
- older revisions that should not be priced
If the alternates genuinely need separate pricing, say so directly. Do not make the shop guess whether one option replaced the other. If that is your main problem, use the multiple-file-versions page next.
What filename should the README use?
Keep it obvious: README.txt, README_quote_notes.txt, or QUOTE_NOTES.txt. The goal is visibility, not clever naming.
A plain text file is usually enough. If the job needs a richer note with images, a short PDF can work too, but do not bury the key instruction inside a long formatted document if one sentence would do the job.
Frequently Asked Questions
Should every ZIP include a README?
No. Use it when the file package could be misunderstood or when important quote instructions need to travel with the files.
Can the README replace good filenames?
No. Good filenames still help. The README is there to clarify roles, priorities, and quote instructions when names alone are not enough.
What if I already wrote the explanation in my email?
That may be fine, but the README helps preserve that context if the ZIP gets separated from the original message.
Does the README need to be long?
No. Most should be short, direct, and easy to scan in under a minute.
Simple takeaway
If your ZIP file is doing more than delivering one obvious file, include a small README so the quote target, supporting references, and buyer instructions stay clear. The minute spent writing it is often cheaper than a wrong-file quote or a messy requote later.
If you are ready to send a clean file package, get a quote here. If the job needs help sorting revisions, evidence, and the full production handoff before quoting, JC Print Farm can help.