Yes, and it is one of the few customisation requests that costs almost nothing per unit but changes everything about how the order has to be run. Preloading turns a hardware order into a data-handling order: it adds a file-copy step, a verification step, a version-control problem and a confidentiality question. Here is what to decide before you ask, what to send, and where the schedule actually breaks.
Preloading is standard and usually inexpensive per unit, but it must be specified before production is scheduled rather than after. Three things decide whether it goes smoothly: the master copy (one folder, one version, named with a date), the verification method (a file-level checksum comparison rather than a visual check), and the confidentiality arrangement if the content is proprietary. Two practical constraints matter more than price — preloading happens after full-capacity testing, so the content is never part of the capacity verification, and the loading step adds a fixed number of days to the schedule regardless of order size.
The request that looks like a footnote and behaves like a project
A buyer specifying a branded drive for a software product, a school archive or a training package eventually asks the same question: can you put our files on it before it ships?
The answer is yes, and the per-unit cost is not the reason to think twice. The reason to think twice is that this single line converts a hardware order into a data-handling order, and a data-handling order has failure modes a hardware order does not have.
None of them are hard. All of them are avoidable by deciding five things in advance.
What preloading actually changes
A normal order runs: components in, assembly, full-capacity test, appearance check, packing, shipment.
A preloaded order inserts two steps between testing and packing:
| Stage | Normal order | Preloaded order |
|---|---|---|
| Assembly | Yes | Yes |
| Full-capacity test | Yes | Yes — still on empty drives |
| Data copy | — | Added |
| Data verification | — | Added |
| Appearance and packing | Yes | Yes |
| Shipment | Yes | Yes |
The two added steps sit in a specific place. That placement is not arbitrary — it is forced by the fact that a full-capacity test fills the device completely, so the drive has to be empty when the test runs. Load first and test second, and the test no longer proves what it claims to prove.
This ordering has a visible consequence: the content is never covered by the capacity report. A drive can pass a perfect full-capacity test and still arrive with the wrong file version on it, because the two checks measure different things. That is why the verification step exists separately.
Decision one: one master, one version, one name
The single most common cause of a preloading problem is not the copying. It is that the buyer sends three files over two days and a link to a share folder, and the factory loads whatever arrived last.
The fix costs nothing. Send one folder, containing exactly what you want on the drive, and name it with a date and a version. If the content changes, send a new folder with a new name and explicitly say the old one is superseded. A folder called archive_v3_2026-03-14 removes every ambiguity that a folder called final creates.
Inside the folder, put a plain text file listing every file name and its checksum. That file is the instrument that makes verification possible later, and generating it takes seconds.
Decision two: verify by comparison, not by looking
A drive that “looks right” when plugged in proves very little. A single corrupted byte in a large file can leave the folder structure perfect and the application broken.
The verification that means something is a checksum comparison: hash each file on the delivered drive, compare against the master list, and report any mismatch. At volume this is done by the duplicator itself; at small volume it is a script and a few minutes.
Ask for the verification result in writing, even as a single line: files copied, files verified, mismatches found. A supplier who cannot state that number is not verifying.
Decision three: the confidentiality arrangement
If the payload is proprietary — an application, a customer database, a licensed asset — the question of what happens to the master copy matters.
Three workable arrangements, in increasing order of control:
Written deletion commitment. The simplest. The factory copies the files, and commits in writing that the master is deleted after the run and not retained for reorders. New master supplied each time. Adequate for most commercial content.
Encrypted delivery. The master arrives as a password-protected archive, password sent by a different channel. This does not stop someone determined, but it removes casual access and makes accidental exposure unlikely.
Self-loading. The drives ship empty and the buyer loads them at their own premises. This is the right answer when the content is regulated, when the volume is small enough that loading in-house is feasible, or when the buyer already has a duplication process. It is not an unusual request, and a supplier should not treat it as one.
What is not workable is expecting a factory to load files it cannot see. Choose one of the three and say which.
Decision four: bulk copy or per-unit personalisation
These are two different services and they are often confused.
| Bulk copy | Per-unit personalisation | |
|---|---|---|
| What is written | Identical content to every drive | Different content to each drive |
| What you supply | One folder | A folder, plus a mapping table and per-unit files |
| Setup | Small | Larger — the mapping has to be built and checked |
| Error risk | Low | Higher; a mismatch is silent |
| Verification | Checksum comparison per drive | Checksum plus matching drive identity to label |
| Unit cost | Low and flat | Higher, and it scales with the number of distinct payloads |
A personalised run has a failure mode that a bulk run does not: the right file on the wrong drive. A student receives another student’s archive. The only defence is verifying the drive identity against the packaging at the same time as the content, and that has to be designed into the process, not checked afterwards.
If the order is personalised, say so at the quotation stage. A supplier who quotes a bulk copy and discovers the mapping table later will either re-quote or, worse, attempt it without the right process.
Decision five: the file system, described by use rather than by name
A file system has to be set before data is written, so this decision precedes the copy. It also constrains the payload: some formats limit individual file size, and a video asset can run into that limit while a folder of documents never will.
The practical approach is to state what the drive will be plugged into and what the largest single file is, rather than naming a format. If the requirement is “works on Windows and macOS without the customer installing anything”, that points to a particular family of formats. If the requirement includes “one file is 8GB”, that rules some out.
State the use, and the format follows. Naming the format first often produces a drive that satisfies the letter of the request and fails on the first file.
What the schedule actually looks like
Preloading adds calendar time, not just cost. The copy itself may take hours rather than minutes on a large order, and verification is a second pass over the same units.
The added time is roughly fixed rather than proportional, which means it hurts small orders proportionally more. A few hundred drives might add a day; tens of thousands might add several. What it never does is add nothing.
The practical implication: if the delivery date is tight, preloading is the first thing to move out of the critical path — either by loading in-house after arrival, or by splitting the shipment so the empty drives travel first.
The short version
If you are about to request preloading, decide these five before you send the email:
A dated, versioned master folder with a checksum list. One folder, one name, one version.
A checksum verification requirement, reported in writing. Not a visual check.
A confidentiality arrangement chosen from three options. Delete-and-confirm, encrypted, or self-load.
Whether the content is identical on every drive. If not, supply a mapping table and expect a higher setup cost.
What the drive connects to and the size of the largest file. Not the name of a file system.
The cost of preloading is real but small. The cost of getting the version wrong, or of a personalised drive reaching the wrong person, is not.
Frequently asked questions
How much does preloading add per unit?
The per-unit cost is usually small, because it is a file copy plus a verification pass on a drive that is already being handled. The variation between suppliers comes from how the copying is done, not from the concept: a manual USB hub copy is cheap but slow and hard to verify at volume, while a duplicator that writes several drives at once and checks them automatically costs more in setup and less per unit above a certain quantity. Ask for the setup charge and the per-unit charge separately, since they move in opposite directions with volume.
Will preloaded files show up in the capacity test?
They should not. A full-capacity write-and-read-back test has to fill the whole device, which means the drive must be empty when it runs. The correct sequence is test, then load, then verify. If a supplier tests after loading, the test is no longer measuring the full capacity and the report is worth less than it appears. This is worth stating explicitly in the order, because it is easy to get wrong and nobody notices until a unit fails in the field.
What format should the master copy be in?
A single folder, with the files in whatever structure you want the customer to see when they open the drive, plus a plain text file listing the file names and their checksums. Not an archive, not a set of nested folders, not a link to a cloud drive. A folder that can be copied onto a drive in one operation and compared afterwards is what makes verification possible, and the checksum list is what makes that comparison a few seconds of work instead of an afternoon.
How do I keep my software from being copied by the factory?
Separate the two questions. The drive manufacturer needs access to the file to copy it; they do not need to keep it. Ask for a written commitment that the master copy is deleted after the run, that no copy is retained for reorders, and that a new master is supplied each time. If the content is genuinely sensitive, supply it on an encrypted archive with the password sent separately, or load it yourself at your own premises — both are normal arrangements and neither is unusual to request.
Is preloading compatible with a personalised order where every unit differs?
Yes, but the mechanism changes completely. Instead of copying one master to all drives, each drive receives a different payload — a name, a serial, a licence key — which requires a per-unit mapping table and a loading process that can read that table. This is a different service from a bulk copy, with a different setup cost and a higher error risk, and it needs its own verification: the serial on the drive must match the label on the packaging.
Can the drive also be formatted to a specific file system?
Yes, and it is worth deciding early because the format interacts with preloading. A file system has to be chosen before files are written, and some formats impose per-file limits that matter if the payload includes a large single file. If the application runs on both Windows and macOS, a format both systems read natively avoids the support question entirely. Say what the drive will be plugged into, rather than naming a format, and the right format follows.