Product Access Controls: Scheduled Drops and Password Protection on a 20-Year-Old Platform

I'd been at Big Cartel for about two years when a pattern in the feedback became impossible to ignore. Every time we ran the annual seller survey, and inevitably at the end of almost every other feedback prompt, a handful of sellers would ask for the same two things: a way to schedule a product to go live at a set time, and a way to put a password in front of a listing.

The two asks came from different sellers with different reasons. Drops were mostly artists, painters, and merch shops who wanted to release inventory on a schedule instead of the moment it was ready. Passwords were mostly sellers running memberships or exclusive product lines who wanted to gate a listing before it opened to everyone.

Both requests sounded simple from the outside. Neither one was, given how the platform was actually built.

Big Cartel's storefront themes are old, and each one was built individually rather than off a shared component system. Standardized classes for common elements only started appearing more recently. Adding a password feature the conventional way would have meant updating every theme in the system, then asking every seller to update their own theme to get the feature. That was a nonstarter.

Instead, I worked with engineering on a different mechanism: intercept the request for a password-protected product, redirect to a password page, and set a cookie once the customer typed in the correct password. No theme code had to change to support the feature.

That moved the hard problem from "update every theme" to "make one new page look right on every theme," which was still real work. I went through the themes personally and audited which CSS classes each one used for its typography, colors, and spacing, so the password page could inherit a seller's actual theme choices instead of shipping as a generic, unbranded page. I did the same for language, so the password page picked up whatever language the seller had set for their storefront.

Before any of that, there were product decisions to make. Was the password for the whole shop, a section of it, or a single product? If a customer entered it once, did it unlock everything, or just that item? Was there one password per shop, or a separate one per product?

Some sellers, in their feedback, specifically asked for shop-wide or section-wide protection. I decided against that for the first version. Locking a whole shop or category behind one password is a bigger, less reversible decision for a seller to make, and it would have meant a more complex permission model to design and support. I went with per-product passwords instead: each product is independently password-protected or not, controlled by the seller.

That gave up the one-click "protect my whole shop" option, but it kept the door open for sellers who wanted something close to it. Because Big Cartel already supported bulk-editing products, a seller who wanted to protect an entire category could filter their product list down to that category and apply a password to all of them at once. Same outcome for that seller, without a second permission model to build and maintain.

Scheduling turned out to be the harder build, for a reason that had nothing to do with calendars. A drop needed to be its own object in the database, separate from the product itself, because a single drop could reference multiple products at once, and because sellers wanted to schedule the same product to go live more than once, a monthly restock of the same listing, for instance, tracked as its own event so they could see the sales it drove and reschedule it independently if they needed to.

That ran straight into a gap in how Big Cartel worked. At the time, clicking "Add New Product" didn't actually create a product record in the database. It behaved like a draft that only became real once the seller saved it; if they navigated away first, it just disappeared. There was no concept of a draft product.

That meant a schedule had nothing to attach to until a seller finished creating the product, which defeated the purpose of scheduling it in advance. I had to change the underlying architecture so that clicking "Add New Product" immediately created a real product record, a shell the seller could keep editing, that a drop could reference right away even before the seller had finished filling it in.

Making "Add New Product" create a real row immediately solved the scheduling problem and introduced two new ones.

First, sellers who clicked "Add New Product" and then abandoned it, which used to just vanish, now left behind an empty, orphaned product sitting in their catalog.

Second, that new shell product defaulted to an active status, so half-finished products were technically live. My fix for that, defaulting new shell products to hidden instead, created a second confusion: sellers would finish building a real product, save it, check their storefront, and ask support where it had gone, because it was still saving as hidden by default and they hadn't noticed. I shipped a follow-up fix so that saving a product flips it to active as expected, and reserved hidden specifically for products a seller explicitly chose to hide or that a drop had scheduled.

That distinction matters for how scheduling actually behaves. If a product was active when a seller applied a schedule to it, it flips to "Coming Soon": visible on the storefront, tagged as upcoming, with the purchase button disabled until the drop fires. If it was hidden, it stays hidden until the drop, invisible on the storefront entirely. Sellers can also choose "Coming Soon" manually if they want the visibility without hiding the listing.

Sellers can edit or reschedule a drop's date at any time before it fires. Once it's scheduled, we handle the parts a seller would otherwise have to remember themselves: an email 24 hours before the drop, plus a push notification if they have the app installed, and a confirmation email and/or push notification when the drop actually goes live.

If a product in the drop can't go live (out of stock, missing a price, whatever the reason), sellers get told which product failed so they can go fix it instead of finding out from a confused customer. I'd scoped out more detailed reporting on drop performance as the next piece of this, but that didn't ship before I left Big Cartel.

Big Cartel's product analytics and support-feedback teams pulled a formal nine-month review of the bundle in August 2026, using Amplitude for usage and upgrade attribution and Enterpret for support-ticket sentiment. The short version: this is a real, durable rate increase, not a launch-month artifact that faded once the initial excitement wore off. Usage held steady to growing every month since launch, and Scheduled Drops turned out to be the stronger of the two upgrade drivers, on both volume and conversion.

The rate is measured on an identical definition each month: sellers who hit Subscription Upgraded to Diamond, divided by the active Platinum payer base (Subscription Payment Completed on Platinum) that month. Since Platinum is the only paid tier below Diamond, every one of those upgrades is a Platinum-to-Diamond move by definition. November spiked to 0.90% at launch, then settled into a steady 0.69% to 0.76% band for the eight months after that, still comfortably above the 0.57% pre-launch baseline every single month. The Platinum base itself stayed essentially flat across the whole window (about 45,000 to 48,000 payers), so this is a real increase in the rate at which Platinum sellers upgrade, not an artifact of the denominator shrinking or growing underneath it.

Monthly schedule volume also grew on its own, from about 1,800 a month early in 2026 to 2,400 to 2,650 recently, meaning existing sellers are scheduling more per person over time, not just more sellers trying it once. Edits (about 120/month) and removals (about 40 to 90/month) stayed low relative to creates: sellers mostly set a drop and leave it alone, which is what "the feature works as intended" looks like in the data.

One honest caveat: this is click-then-convert attribution on a bundled Diamond-plan feature, measured in a 7-day window, so some of these sellers may have upgraded for the whole bundle rather than either feature specifically. What I trust more than the absolute upgrade counts is the relative comparison between the two: Scheduled Drops wins on both clicks and conversion rate, consistently, which is a real signal about which lever is doing more work.

Enterpret found about 497 support records mentioning scheduling or drops since launch, growing to 60 to 70 a month, all through Intercom. Two things are worth knowing before reading that as pure feedback volume. A lot of those records exist because our AI support bot suggests "check your scheduled drops" as a possible reason a seller's products aren't showing, which inflates raw mention counts without those sellers actually commenting on the feature. And among the roughly 364 records that did carry an actual sentiment label, the read is net positive.

The two genuine pain points behind that theme were still open when I left. Drops fire on the seller's device time zone rather than a shop-level setting, which confused several sellers about the actual launch time. And the hidden vs. active vs. coming-soon status model, however logical internally, was still surprising sellers on the storefront side. Bulk-scheduling discoverability came up a handful of times too. All three were exactly the kind of thing the reporting layer I'd scoped would have made visible sooner.