Q:

You are a senior financial systems analyst specializing in subscription commerce, reverse logistics, and circular inventory models. Your task is to design a UNIT-ECONOMICS SIMULATION MODEL for a weekly apparel subscription service governed by circular inventory reuse. The model must: – Treat revenue as time-based subscription yield, not per-item sales. – Treat cost at the level of per-cycle marginal economics. – Explicitly model cleaning, labor, logistics, loss, damage, and inventory retirement. – Allow simulation across scale (100 users → 100,000 users). – Surface break-even thresholds, sensitivity to variance, and compounding efficiency effects. Produce: 1. A narrative explanation of the economic primitives and why traditional retail metrics fail here. 2. A formal definition of the unit of analysis and all dependent variables. 3. Pseudocode or spreadsheet-ready formulas for per-cycle cost and contribution margin. 4. Scenario analysis describing best-case, base-case, and failure-case trajectories. 5. A section titled “Economic Kill Conditions” identifying conditions under which the business model is structurally non-viable. Do not hand-wave logistics. Do not assume perfect behavior. Explicitly model friction, variance, and human error.

A:

1. Economic primitives and why retail metrics fail

A weekly apparel subscription is a temporal yield business, not a point-of-sale business. The customer is not “buying items”; they are purchasing guaranteed access to a rotating wardrobe experience with bounded cognitive load and high service reliability. Revenue therefore accrues as subscription yield per active user-week, while the physical garments are reusable production assets that generate many user-weeks of service before retirement.

Traditional retail metrics mislead because they attribute value at the moment of sale and treat inventory as a one-time cost of goods. In a circular subscription, the inventory is not “sold,” it is “worked.” The correct mental model is closer to fleet economics: each garment has a finite service life measured in deployable cycles, and each cycle consumes variable resources (transport, cleaning, labor) and incurs probabilistic friction (loss, damage, late returns, quality fails, human error). The unit economics therefore live at the per-cycle margin and at the inventory-turn level, not at the per-item gross margin level.

The non-negotiable reality is logistics physics. A “weekly” promise creates a hard cadence constraint. Any variance in return time, cleaning turnaround, pick-pack accuracy, or carrier performance converts directly into additional buffer inventory, expedited shipping, refunds, and churn. This is why the model must explicitly represent distributions (lateness, loss, damage) rather than assume averages.

2. Formal unit of analysis and dependent variables

The canonical unit of analysis is one User-Week Cycle, denoted as one successfully fulfilled weekly service interval for one active user. A User-Week Cycle begins when a box is inducted for outbound fulfillment and ends when the previous box is received, processed, and garments are requalified for redeployable inventory (or retired).

The core dependent variables are defined below using environment-variable style placeholders so the model can be parameterized and versioned.

```plain text $PRICE_WEEKLY_USD = subscription price per active user-week (net of discounts, before refunds) $ACTIVE_USERS_t = active users in week t $FULFILL_RATE_t = fraction of active users successfully fulfilled in week t (captures stockouts and ops failures) $REFUND_RATE_t = fraction of cycles refunded or credited due to service failure

$ITEMS_PER_BOX = average garments per shipment (can be fractional by mix) $BOXES_PER_USER = normally 1, >1 if concurrent boxes allowed; keep as parameter

$RETURN_LATENCY_WEEKS = expected time from outbound ship to inbound receipt (includes wear time + return transit) $CLEAN_TAT_WEEKS = expected cleaning + QA + restock time in weeks $TOTAL_CYCLE_TIME_WEEKS = $RETURN_LATENCY_WEEKS + $CLEAN_TAT_WEEKS $SAFETY_STOCK_FACTOR = multiplicative buffer for variance (late returns, rewash, rework, mis-sorts)

$INVENTORY_MULTIPLE = effective garments required per active user to sustain weekly cadence $INVENTORY_MULTIPLE = $ITEMS_PER_BOX * $TOTAL_CYCLE_TIME_WEEKS * $SAFETY_STOCK_FACTOR

$GARMENT_ACQ_COST_USD = weighted average acquisition cost per garment entering service $GARMENT_LIFE_CYCLES = expected deployable cycles before retirement (after repairs, downgrades, etc.) $GARMENT_RETIRE_RATE = 1 / $GARMENT_LIFE_CYCLES (baseline retirement per deployment)

$LOSS_PROB = probability a garment is permanently lost per cycle $DAMAGE_PROB = probability a garment is damaged per cycle (requires repair or causes downgrade/retirement) $REPAIR_COST_USD = expected cost conditional on damage (labor + materials + admin) $DAMAGE_RETIRE_PROB = probability damaged garment is retired rather than repaired

$CLEAN_COST_USD = cleaning + finishing cost per garment per cycle $QA_COST_USD = quality assurance + rebagging cost per garment per cycle $PICKPACK_LABOR_USD = pick-pack labor cost per box per cycle $INBOUND_PROCESS_LABOR_USD = inbound receiving + sort labor cost per box per cycle $CUSTOMER_SUPPORT_USD = variable support cost per user-week (contacts driven by errors, fit, delays)

$OUTBOUND_SHIP_USD = outbound transport cost per box $INBOUND_SHIP_USD = return transport cost per box $PACKAGING_DEP_USD = packaging depreciation per cycle (box + inserts + labels)

$PAYMENT_FEE_RATE = processor fee as % of collected revenue $PAYMENT_FEE_FIXED_USD = processor fee per transaction (if applicable)

$MISSHIP_PROB = probability of fulfillment error per box (wrong items, missing items) $MISSHIP_COST_USD = expected incremental cost conditional on mis-ship (reship, support, credits) $LATE_RETURN_PROB = probability return exceeds target window (drives extra buffer + exception handling) $EXCEPTION_HANDLING_USD = labor + comms cost per late return exception

$FIXED_OPEX_WEEKLY_USD = facility, core staff, systems, insurance, baseline overhead per week $CAPITAL_COST_RATE_WEEKLY = weekly cost of capital for inventory funding (optional but recommended)


Two higher-order outputs drive viability decisions. The first is **Contribution Margin per User-Week**, which must be positive and sufficiently large to cover fixed operating expense and capital intensity. The second is **Required Inventory Capital**, which must be financeable given churn, growth, and replacement rates.

# 3. Spreadsheet-ready per-cycle formulas for cost and contribution margin

The model should compute economics at three nested layers: per-garment-per-cycle, per-box-per-cycle, and per-user-week-cycle. The formulas below assume named ranges matching the variables in Section 2.

## 3.1 Revenue per User-Week Cycle

```plain text
REVENUE_PER_CYCLE_USD
= $PRICE_WEEKLY_USD * $FULFILL_RATE_t * (1 - $REFUND_RATE_t)

If you want to represent discounting and partial failures explicitly:

```plain text COLLECTED_USD = $PRICE_WEEKLY_USD * (1 - $DISCOUNT_RATE_t) REFUNDS_USD = COLLECTED_USD * $REFUND_RATE_t REVENUE_PER_CYCLE_USD = COLLECTED_USD - REFUNDS_USD


## 3.2 Variable cost per User-Week Cycle

Garment-level service cost per cycle, expressed per box:

```plain text
GARMENT_SERVICE_COST_USD
= $ITEMS_PER_BOX * ($CLEAN_COST_USD + $QA_COST_USD)

Expected loss and retirement replacement cost per cycle, expressed per box:

```plain text EXPECTED_LOSS_REPLACEMENT_USD = $ITEMS_PER_BOX * $LOSS_PROB * $GARMENT_ACQ_COST_USD

EXPECTED_DAMAGE_COST_USD = $ITEMS_PER_BOX * $DAMAGE_PROB * ( $REPAIR_COST_USD

  • $DAMAGE_RETIRE_PROB * $GARMENT_ACQ_COST_USD )

EXPECTED_BASE_RETIRE_REPLACEMENT_USD = $ITEMS_PER_BOX * $GARMENT_RETIRE_RATE * $GARMENT_ACQ_COST_USD


Important: you should not double-count retirement. If you treat “life cycles” as already inclusive of loss and damage, then set `EXPECTED_LOSS_REPLACEMENT_USD` and `EXPECTED_DAMAGE_COST_USD` to zero and let `GARMENT_LIFE_CYCLES` absorb them. If you want explicit friction, keep loss/damage separate and define `GARMENT_LIFE_CYCLES` as wear-out only.

Box-level logistics and labor per cycle:

```plain text
LOGISTICS_COST_USD
= $OUTBOUND_SHIP_USD + $INBOUND_SHIP_USD

FULFILLMENT_LABOR_COST_USD
= $PICKPACK_LABOR_USD + $INBOUND_PROCESS_LABOR_USD

PACKAGING_COST_USD
= $PACKAGING_DEP_USD

Human error and variance costs per cycle:

```plain text MISHIP_EXPECTED_USD = $MISSHIP_PROB * $MISSHIP_COST_USD

LATE_RETURN_EXPECTED_USD = $LATE_RETURN_PROB * $EXCEPTION_HANDLING_USD


Payment processing per cycle:

```plain text
PAYMENT_FEES_USD
= ($PAYMENT_FEE_RATE * REVENUE_PER_CYCLE_USD) + $PAYMENT_FEE_FIXED_USD

Variable customer support per cycle:

```plain text SUPPORT_COST_USD = $CUSTOMER_SUPPORT_USD


Total variable cost per cycle:

```plain text
VAR_COST_PER_CYCLE_USD
= GARMENT_SERVICE_COST_USD
+ EXPECTED_LOSS_REPLACEMENT_USD
+ EXPECTED_DAMAGE_COST_USD
+ EXPECTED_BASE_RETIRE_REPLACEMENT_USD
+ LOGISTICS_COST_USD
+ FULFILLMENT_LABOR_COST_USD
+ PACKAGING_COST_USD
+ MISHIP_EXPECTED_USD
+ LATE_RETURN_EXPECTED_USD
+ PAYMENT_FEES_USD
+ SUPPORT_COST_USD

Contribution margin per User-Week Cycle:

```plain text CM_PER_CYCLE_USD = REVENUE_PER_CYCLE_USD - VAR_COST_PER_CYCLE_USD


## 3.3 Scale, inventory intensity, and capital drag

Inventory required (garments) as a function of cadence physics:

```plain text
REQUIRED_GARMENTS
= $ACTIVE_USERS_t * $ITEMS_PER_BOX * $TOTAL_CYCLE_TIME_WEEKS * $SAFETY_STOCK_FACTOR

Replacement garments needed per week (flow), driven by loss/damage/retirement:

```plain text REPLACEMENT_GARMENTS_PER_WEEK = $ACTIVE_USERS_t * $ITEMS_PER_BOX * ( $LOSS_PROB

  • ($DAMAGE_PROB * $DAMAGE_RETIRE_PROB)
  • $GARMENT_RETIRE_RATE ) ```

Weekly replacement spend:

```plain text REPLACEMENT_SPEND_WEEKLY_USD = REPLACEMENT_GARMENTS_PER_WEEK * $GARMENT_ACQ_COST_USD


Optional but recommended: apply a weekly capital charge to deployed inventory (captures financing reality and makes break-even honest):

```plain text
INVENTORY_CAPITAL_USD
= REQUIRED_GARMENTS * $GARMENT_ACQ_COST_USD

CAPITAL_CHARGE_WEEKLY_USD
= $CAPITAL_COST_RATE_WEEKLY * INVENTORY_CAPITAL_USD

CAPITAL_CHARGE_PER_CYCLE_USD
= CAPITAL_CHARGE_WEEKLY_USD / $ACTIVE_USERS_t

If you include capital charge in contribution margin, define:

```plain text ECONOMIC_CM_PER_CYCLE_USD = CM_PER_CYCLE_USD - CAPITAL_CHARGE_PER_CYCLE_USD


Break-even active users in a steady-state week:

```plain text
BREAKEVEN_ACTIVE_USERS
= $FIXED_OPEX_WEEKLY_USD / CM_PER_CYCLE_USD

If you include capital charge in CM, use ECONOMIC_CM_PER_CYCLE_USD instead.

3.4 Monte Carlo simulation pseudocode for variance and tail risk

This is the minimal structure needed to surface sensitivity and compounding effects (fit learning, ops learning, carrier variance).

```plain text Initialize parameters and distributions for: return_latency_weeks ~ Dist(…) clean_tat_weeks ~ Dist(…) loss_events ~ Bernoulli($LOSS_PROB) per garment-cycle damage_events ~ Bernoulli($DAMAGE_PROB) per garment-cycle miship_events ~ Bernoulli($MISSHIP_PROB) per box-cycle service_failure_events ~ function(miship, late_return, stockout)

For simulation run r in 1..R: Set users_0 = initial users Set inventory_pool_0 = users_0 * $INVENTORY_MULTIPLE For week t in 1..T: Draw realized latency and TAT; compute realized_cycle_time Compute required_inventory_t = users_t * $ITEMS_PER_BOX * realized_cycle_time * $SAFETY_STOCK_FACTOR If inventory_pool_t < required_inventory_t: Set fulfill_rate_t = inventory_pool_t / required_inventory_t Apply service failures and incremental churn Else: Set fulfill_rate_t = 1

Realize per-cycle friction (loss, damage, miship) via random draws
Compute realized variable costs and realized refunds/credits
Compute realized CM_t = revenue_t - variable_cost_t - (optional capital charge)

Update inventory_pool_{t+1} = inventory_pool_t
  - losses - retirements + replacements_purchased - (backlog effects from late returns)

Update users_{t+1} = users_t + acquisitions_t - churn_t
  where churn_t increases with service failures, fit misses, and delay events
  and acquisitions_t may be constrained by cash or capacity

Aggregate outputs: mean CM, p10/p90 CM, probability(CM < 0), peak inventory capital, cash drawdown, breakeven week, and failure probability under each scenario. ```

4. Scenario trajectories: best-case, base-case, failure-case

The scenario work should be treated as trajectory simulation rather than static snapshots, because compounding effects dominate. Fit improvement reduces mis-ships and returns friction, which reduces support load and refunds, which improves retention, which increases scale, which improves carrier and cleaning unit costs, which further improves margin. The reverse spiral is equally real.

4.1 Best-case trajectory

In the best-case trajectory, return latency variance narrows, cleaning TAT is stable, and operational error rates are low and declining with scale. The inventory multiple trends toward the theoretical minimum implied by cycle-time physics, meaning fewer garments are idle per active user-week. Volume-based rate reductions appear in transport and cleaning, and the service achieves high fulfillment reliability, keeping refund and churn pressure low. The business crosses break-even at a relatively modest active-user count because CM per cycle expands with scale while inventory capital grows sublinearly due to improved turns and lower safety stock.

Operational signature: $TOTAL_CYCLE_TIME_WEEKS decreases slightly over time, $SAFETY_STOCK_FACTOR decreases materially, $MISSHIP_PROB decreases, $REFUND_RATE_t stays low, and replacement flow stays bounded.

4.2 Base-case trajectory

In the base-case trajectory, the business experiences realistic variance: a meaningful tail of late returns, periodic cleaning bottlenecks, and non-trivial human error in pick-pack and inbound processing. Inventory multiple remains elevated because safety stock must protect the weekly promise. Some scale efficiencies appear, but are partially offset by growth-driven complexity (more SKUs, more sizes, more routing paths) and by customer heterogeneity.

Operational signature: $TOTAL_CYCLE_TIME_WEEKS is stable but with variance, $SAFETY_STOCK_FACTOR remains meaningfully above 1, $MISSHIP_PROB declines slowly, loss and damage remain persistent, and churn is sensitive to service failures.

The base-case is viable only if CM per cycle is robust enough to absorb variance without triggering a refund–churn spiral, and if inventory capital is financeable through growth.

4.3 Failure-case trajectory

In the failure-case trajectory, variance and friction exceed the buffer design. Late returns are frequent enough that the system effectively runs two-week physics while selling one-week pricing, forcing a high inventory multiple. Cleaning turnaround becomes a bottleneck, producing stockouts that reduce fulfillment rate, which forces credits and increases churn. Human error rises under pressure, increasing mis-ships and support costs. Loss and damage accumulate, increasing replacement spend and degrading assortment quality, which further increases churn and fit misses.

Operational signature: $FULFILL_RATE_t declines during peak weeks, $REFUND_RATE_t increases, $SAFETY_STOCK_FACTOR must be raised, replacement spend accelerates, and the model shows negative CM or negative economic CM after capital charges. Growth becomes a trap because each marginal user requires disproportionate inventory and exception handling.

5. Economic Kill Conditions

Economic Kill Conditions are structural, not temporary. They identify states where no amount of incremental optimization can restore viability without changing pricing, cadence, service design, or the physical network.

A first kill condition is non-positive steady-state contribution margin per User-Week Cycle under realistic variance. If CM_PER_CYCLE_USD ≤ 0 in the base-case after including mis-ship, late return, and refund tails, the model is structurally broken because scaling increases absolute losses.

A second kill condition is inventory multiple inflation beyond financeable limits. If $TOTAL_CYCLE_TIME_WEEKS and $SAFETY_STOCK_FACTOR imply an $INVENTORY_MULTIPLE that drives inventory capital (and replacement flow) beyond what the business can fund at the intended price point, the weekly promise becomes unfinanceable even if nominal CM is positive.

A third kill condition is replacement flow exceeding margin capacity. If the expected weekly replacement spend per active user-week, derived from loss, damage-retirement, and baseline retirement, consumes the majority of contribution margin, then quality will degrade, assortment will shrink, and churn will increase, creating a negative flywheel.

A fourth kill condition is variance-driven refund–churn coupling. If empirically plausible service failures push $REFUND_RATE_t and churn high enough that acquisition spend must rise while CM falls, the model will not converge to profitability because the customer base never stabilizes long enough to realize learning-curve efficiencies.

A fifth kill condition is logistics cost floor above pricing ceiling. If the combined outbound and inbound transport plus cleaning/QA per box has a hard floor that, when multiplied by $ITEMS_PER_BOX, approaches or exceeds the subscription yield net of payment fees, the business cannot win on efficiency; it must change cadence, consolidate shipments, change box composition, change geography, or reprice.

A sixth kill condition is capacity bottleneck economics. If cleaning or fulfillment capacity must be expanded in discrete jumps that add fixed expense faster than CM grows, break-even recedes with scale. In the model this appears as step-function increases in $FIXED_OPEX_WEEKLY_USD or as forced expedited handling that permanently raises variable cost.

If you want, I can also provide a fully specified sheet layout using these variables as named ranges, including a scale slider from 100 to 100,000 users and a Monte Carlo tab that outputs probability-of-failure and breakeven distributions, while keeping the cadence physics explicit (cycle-time → inventory multiple → capital drag).

Q:

Proceed

A:

I built the spreadsheet simulator as an Excel workbook with explicit per-cycle marginal economics, circular inventory physics (cycle-time → safety stock → inventory multiple), loss/damage/repair/retirement, logistics and labor, scale effects, scenario toggles, Monte Carlo variance, and “Economic Kill Conditions.”

Circular_Subscription_Unit_Economics_Simulator.xlsx

README

Workbook structure (what to touch and where):

  • README: operating instructions and model notes.

  • Inputs: all assumptions. Blue cells are editable. Column C (Effective) drives the model.

    • Scenario_Mode (0 = Manual, 1 = Scenario Library)

    • Scenario_Select (1 = Best, 2 = Base, 3 = Failure)

  • Scenarios: best/base/failure assumption library powering the toggle.

  • Scale: set Active_Users (100 → 100,000). Outputs inventory required, capital, replacement flow, break-even, and profit.

  • UnitEconomics: per user-week-cycle revenue/cost stack and CM (with and without capital charge).

  • MonteCarlo: variance + discrete friction (late returns, mis-ship, loss, damage/repair/retire). Default runs = 100; increase if you want (Excel recalculation will slow accordingly).

  • KillConditions: structural non-viability flags (e.g., CM ≤ 0, inventory multiple too high, replacement share too high, Pr(CM<0) too high).

If you want the model extended into a full week-by-week cohort/cash simulation (growth, churn coupling to service failures, capacity step changes, and inventory cash conversion over time), say so and I’ll add a time-series “Trajectory” tab that turns this from steady-state into a dynamic system model.

Q:

Extend

A:

I extended the workbook into a week-by-week system dynamics model with growth, churn coupling to service failures, capacity step effects (sites coming online with lead time), inventory ordering with procurement lead time, and an explicit cash runway.

Circular_Subscription_Unit_Economics_Simulator_Extended.xlsx

README

Open $MODEL_XLSX and use Inputs as the single control plane. The new section Trajectory & Cash Simulation adds horizon, starting users, weekly acquisition, CAC, churn sensitivities (refund, stockout, late), stockout penalty economics, starting cash, inventory lead time, reorder buffer, and site-add lead time. The new Trajectory tab then computes, per week, active users, demand vs capacity, fulfill rate, refund rate, net revenue, variable cost, contribution, fixed OPEX, operating profit, required garments, on-hand inventory, ordering/arrivals, inventory spend, CAC spend, and cash begin/end. KillConditions now also surfaces trajectory cash-out and fulfillment-violation flags in addition to the per-cycle structural checks.

If you want the next extension, I can add a cohort retention layer (separate acquisition cohorts with different churn curves), a constrained marketing budget loop (CAC rising with saturation), and a “capacity ramp cost” curve (temporary labor inefficiency when sites are added) so the trajectory reflects the real operational drag during scaling transitions.

Q:

Extend

A:

I extended the simulator with three structural layers: an explicit cohort retention engine (age-based churn with shock), a constrained marketing budget loop with CAC saturation, and a capacity ramp efficiency curve that temporarily degrades throughput and inflates variable labor cost when sites are added.

Circular_Subscription_Unit_Economics_Simulator_Advanced.xlsx

README

Key additions inside the workbook: the new Cohorts sheet computes age-bucketed active composition and an effective churn rate each week (baseline churn by cohort-age plus an operational “shock” churn driven by refunds, stockouts, and late behavior); the new CapacityPlan sheet computes sites required using a utilization target and lead time, then applies a ramp curve to convert “Sites_Online” into “Effective Sites” (capacity) and a linked “VarCost_Mult” (labor inefficiency); the Trajectory sheet is rewired so demand is based on Active_Service = Carryover + New_Users (new users are served in-week), New_Users is driven by Mktg_Budget / CAC_t when marketing mode is enabled, and variable cost is multiplied by the ramp inefficiency factor.

Controls you’ll edit in Inputs, under “Advanced Dynamics Extensions”: COHORT_MODEL_ON, COHORT_CHURN_BASE_WEEKLY, EARLY_CHURN_PREMIUM, CHURN_DECAY_WEEKS; MARKETING_MODE, WEEKLY_MKTG_BUDGET_USD, MKTG_PCT_REVENUE_CAP, TAM_USERS, CAC_SATURATION_SENS, CAC_SATURATION_ELASTICITY, MAX_NEW_USERS_PER_WEEK; CAPACITY_UTIL_TARGET, RAMP_WEEKS, RAMP_EFF_START, RAMP_VAR_COST_MULT_MAX.