Pre-orders for digital downloads: taking money before the file exists, without breaking delivery

Pre-orders feel like free validation: buyers pay now, you finish the product with the money (and the pressure) already in hand. For physical goods, the delivery gap is understood — everyone knows a pre-order ships later. For digital downloads, that same gap is where sellers get hurt, because most delivery systems are built around one assumption: payment and delivery happen in the same minute.

Here's how to run a digital pre-order without that assumption breaking your launch — with whatever delivery tool you use.

The core problem: your delivery clock starts at payment

Most download delivery works like this: the buyer pays, and immediately gets a personal download link with limits and an expiry window attached. That's perfect for a finished product. For a pre-order, three things go wrong:

• Expiry burns during the wait. If your links expire 30 days after purchase and your launch slips to day 40, your earliest, most loyal buyers hold dead links on the day the product finally exists.
• Limits burn on the wrong file. If buyers download a placeholder, a sample, or an early draft through the same link, those downloads can count against the allowance they were supposed to spend on the finished product.
• Support arrives before the product does. "I paid, where's my file?" emails start on day one — and if your buy page didn't say, clearly, that this was a pre-order with a date, those emails turn into refund requests and disputes.

None of this is a reason to avoid pre-orders. It's a reason to separate the two events — payment and delivery — on purpose, instead of letting your tooling blur them together.

Pattern 1: the honest waitlist-then-launch (safest)

Collect interest, not money. Take emails during the build, then open normal sales on launch day, when payment and delivery line up the way your tools expect.

• You lose the commitment signal of real payments, and launch-day conversion from a list is always lower than pre-order revenue already banked.
• You gain a launch with zero delivery edge cases: every buyer's link, limits, and expiry start when the file actually exists.

For a first product with no audience trust yet, this is usually the right trade. A failed pre-order costs you reputation; a waitlist costs you nothing.

Pattern 2: sell the pre-order, deliver something real on day one

If you do take money early, give the payment-day delivery a real job. Buyers should download something immediately — just not the unfinished main product:

• A starter pack: the templates, checklists, source files, or chapter one that are genuinely finished.
• A bonus that stands alone: a related mini-product the buyer keeps regardless of how the main launch goes.
• Early access to the work-in-progress, clearly labeled as a draft, for buyers who want to follow along and give feedback.

This works because the buyer's link and limits are spent on real value, the "where's my file?" email never gets written, and launch day becomes an update delivery — the finished version replaces or joins what buyers already have — rather than a first delivery under pressure.

One discipline matters here: say, on the buy page, exactly what arrives today and exactly what arrives on launch day, with the launch date attached. "Pre-order" in small print under a big "buy now" button is how disputes are born.

Pattern 3: take a deposit-sized commitment instead

Sell a cheap, finished product now — a sample pack, a founding-member pass, a mini-course — whose buyers get the main product on launch day as an update or a bonus. The payment is real, the delivery is real, and nobody is owed a file that doesn't exist yet. This is pattern 2 with the pricing doing the honesty work for you.

The expiry and limits math, done before you announce

Whatever pattern you choose, run these numbers before the sales page goes live:

1. Expiry window vs wait time. Your link expiry, counted from purchase, must comfortably exceed your longest plausible delay — not your planned date, your slip date. If your tool's free tier expires links at 30 days and your launch is "about a month away," you are one bad week from expiring your first buyers. Either shorten the pre-order window, deliver on a tier whose links don't expire, or re-issue links at launch as a planned step (and say so at purchase).
2. Download limits vs versions. If buyers will download a draft, a v1.0, and a v1.1 fix, a 2-download limit is a support ticket generator. Count the versions you honestly expect, then set the limit above that — limits exist to stop sharing, not to ration your own updates.
3. License keys and activation timing. If your product activates with a key, decide whether pre-order buyers get keys at payment or at launch. Keys issued at payment for software that isn't finished yet invite activation problems you can't reproduce; keys at launch need a delivery step you must not forget. Pick one, and write it on the buy page.
4. The refund promise. State the pre-order refund terms before purchase: refundable until launch day is the buyer-friendly default, and it's cheap insurance — a buyer who can leave freely rarely files a dispute. If a refund happens, access should end with it: on FileFreight, when Stripe reports a refund, the buyer's download entitlement and license keys are revoked automatically, so a refunded pre-order buyer keeps no access to the starter pack or the finished file.

Launch day: the delivery checklist

Launch day failures are almost never "the file is bad." They're delivery mechanics nobody rehearsed:

• Upload the final file and buy it yourself first. Use a second email, pay real money, and click through exactly as a buyer: payment, delivery email, download, open the file. If it's a PDF you stamp per buyer, confirm the stamp carries the right identity.
• Send the update to pre-order buyers as its own event. A short email: it's live, your link works, here's what's new since the draft. Buyers who bought weeks ago have forgotten your product exists; the launch email is also your reminder.
• Expect the support spike in the first 6 hours. The three launch-day emails are always the same: link expired (see the math above), download limit hit from draft versions, and "I bought it but used my other email." Having the answers — and the ability to re-issue a link or revoke and replace a key — ready before you announce turns a spike into a non-event.
• Keep selling the finished product on the same page. Update the buy page copy the moment the file is live: "pre-order" language left up after launch undersells a product that now exists.

What FileFreight does and doesn't do here — honestly

FileFreight delivers on payment: after Stripe confirms payment, the buyer is emailed a unique, tokenized download link, plus a license key if you enabled one (validate keys with a single API call, POST /api/licenses/validate, and revoke any key at any time). Files can be up to 500 MB per product, PDFs are stamped with the buyer's identity on first download, and payments settle into your own Stripe account — FileFreight never touches your money. Free allows up to 25 downloads and 30-day link expiry per product; Pro ($19/month, 0% platform fee; Free is 5% per sale) makes downloads unlimited and links never expire.

Note what that means for pre-orders: there is no separate pre-order or scheduled-release feature to switch on, so the patterns above are the product — deliver a real starter file at payment, or waitlist and launch normally. The never-expiring Pro links do remove the day-40 dead-link failure mode for long pre-order windows, which is the specific mechanic that bites hardest.

The standing caveats, because they matter more during a launch than any other week:

1. FileFreight is not a merchant of record. It does not handle sales tax or VAT for you — payments go straight to your own Stripe account, so tax responsibility stays with you, in every country you pre-sell into.
2. There is no automatic importer. If you're moving an existing catalog over for a relaunch, the first 20 sellers get a free white-glove migration — products, files, and license keys rebuilt by hand within 48 hours.
3. FileFreight is not a Shopify app. Every product gets a standalone buy link you can paste anywhere — your site, a social bio, a newsletter.
4. FileFreight is delivery-only. It brings no marketplace discovery and no buyers. Your pre-order audience is entirely your own list and channels — which is exactly why the waitlist in pattern 1 is worth building either way.

The short version

A digital pre-order is two events pretending to be one. Decide what delivers on payment day (something real, or nothing — with a waitlist instead), make your expiry and limits survive your worst plausible delay, put the launch date and refund terms where buyers actually read them, and rehearse launch-day delivery with your own money before you announce. Do that, and a pre-order is what it should be: proof people want the thing, collected before you've finished building it.