Run a digital-product presale with a delivery gate

A presale sells a dated obligation

Write the delivery card before checkout: product, included files or sessions, excluded work, format, accessibility target, license, support window, delivery date or bounded window, update promise, minimum viable orders, maximum orders, cancellation condition, refund path, and customer contact route. Separate a completed product sold early from a product whose production depends on the presale.

Stripe's current preorder support guidance discusses collecting a payment method for later charge or authorizing and capturing within payment-method limits, and it tells businesses to plan for demand changes, refunds, cancellations, and adequate refund cash. Those are payment options and cautions, not a complete product or consumer-law policy. Review the actual checkout, timing, disclosures, and jurisdiction before selling.

Source notes: Accepting payments for pre-orders

Derive the minimum from incremental delivery cost

Include research, writing, design, editing, accessibility work, files, platform, customer support, payment cost, tax work, refund reserve, and contingency. Mark sunk exploration separately from costs triggered by the sale. The minimum order is the smallest whole number whose expected contribution covers the go-forward cost at the chosen confidence level.

Hypothetical example: remaining production labor is $3,600, external accessibility review is $700, delivery and support setup is $300, and contingency is $400, for $5,000 go-forward cost before transaction-specific deductions. At a $100 presale price with a modeled $92 contribution per kept order after those deductions, the mathematical minimum is 55 orders because 54 × $92 is $4,968. Set a higher operational threshold if refunds or scope uncertainty are not already covered.

US-dollar figures are hypothetical and are not a price, cost benchmark, or forecast.

Set a maximum from support and fulfillment

A digital file can copy cheaply while onboarding, personalization, live sessions, feedback, and support remain scarce. Model maximum orders from the narrowest resource. If each buyer receives a 20-minute review and only 30 hours are available, the theoretical ceiling is 90 reviews before scheduling, rework, or support. The sale cap should sit below that ceiling.

Use a waitlist after the cap rather than quietly stretching the delivery date. Freeze the promised scope after launch. Put requested additions into a later product or explicit add-on. A presale that keeps absorbing custom requests becomes an underpriced service project.

Run the go, extend, or refund decision on schedule

At the decision date, reconcile paid orders, pending payments, refunds, disputes, contribution, committed cost, and capacity. Go only if the documented threshold and delivery capacity are met. Extend only if the original promise allows it and customers receive a clear choice. If the project does not proceed, execute the stated refund path and confirm the result.

Stripe's refund API documents refunds back to the original charged card and tracks refund amount and status. The publisher still needs a reserve and a reconciliation process; initiating a refund is not the same as confirming customer receipt. Keep order, refund, dispute, delivery, and support states separate through closure.

Source notes: Refunds · Accepting payments for pre-orders

Close the presale into a product ledger

After delivery, record delivered date, access success, support time, refund requests, promised updates, and remaining obligations. Compare the actual scope and labor with the gate. Preserve the original sales page and delivery card so later buyers do not receive a different product under the same name without a version change.

The useful result is not gross presale cash. It is fulfilled contribution after refunds and remaining support, with the promise intact. This framework reports no typical conversion, refund rate, or product margin.

• Publish a specific scope and decision date.
• Use both a minimum economic order and a maximum capacity order.
• Keep refund cash available until the go decision is final.
• Version the product when delivery or update promises change.