Model 1.0.0

How the model works

ScaleCircuit is a deterministic, expected-value simulation that advances one calendar day at a time. The same inputs always produce the same results. Everything below is also embedded in every report.

Customersgrow by acquisition, shrink by churn
New requestscustomers × usage ÷ days in month
Pending queuefirst in, first out by arrival day
Attemptslimited by daily capacity
Deliveredrevenue already earned by subscriptions

Retry loop. Failed attempts wait the retry delay, then re-enter the queue and compete for the same capacity.

Service loop (optional). Sustained delay raises churn, reducing customers and future demand.

What happens each day

1.Activate capacity additions whose activation day is today; record one-time costs for additions committed today.
2.Apply churn to start-of-day customers, then add the day’s share of monthly acquisition.
3.Generate new requests from the resulting active customers.
4.Release retries scheduled for today into the pending queue.
5.Process eligible work first-in, first-out up to daily attempt capacity.
6.Split each attempt into successes, retryable failures (scheduled for a later day), and exhausted failures.
7.Accrue revenue, refunds, payment fees, attempt costs and daily shares of monthly expenses; update cash.

Equations

Daily churn ratefraction per day: d = 1 − (1 − m)^(1 / D)
m is total monthly churn, D is days in the current calendar month. Compounded over the month, d reproduces m exactly.
Customerscustomers: C(t) = C(t−1) × (1 − d) + A / D
A is monthly new customers. Fractional customers are expected values, not people.
New requestsrequests per day: R(t) = C(t) × min(u, L) / D
u is expected monthly requests per customer, capped at the monthly allowance L.
Attemptsattempts per day: X(t) = min(K(t), eligible pending work)
K(t) is daily attempt capacity. Retries consume the same capacity as first attempts.
Attempt outcomesrequests: success = x × (1 − p); failure = x × p
A failure on attempt n < N re-enters the queue r days later (r ≥ 1). A failure on attempt N is terminal.
Subscription revenuecurrency per day: Rev(t) = C(t) × P / D
Accrued daily and assumed collected the same day.
Refundscurrency per day: Ref(t) = Rev(t) × ρ
ρ is a configured allowance.
Payment feescurrency per day: Fee(t) = Rev(t) × φ + (C(t) / D) × f
Assumes one charge per customer per month spread evenly; billing anniversaries are not modeled.
Contribution profitcurrency: CP = Rev − Ref − Fee − X × c
c is cost per attempt. Every attempt incurs cost, including failed ones.
Operating resultcurrency: OR = CP − (fixed + marketing + support + maintenance + added-capacity recurring) / D
Net cash movementcurrency: ΔCash = OR − capacity one-time expenditure − initial setup expenditure
Initial setup is spent on day 1. Capacity one-time costs are spent on the commitment date.
External funding requirementcurrency: F(t) = max(0, −Cash(t))
Operations continue under an assumed funding facility with no interest or limit.
Optional service-feedback churnfraction per month: Δm = min(M, s × max(0, W̄₇ − W*))
W̄₇ is the mean of the previous seven daily delay values. Total churn is capped at 100% per month.

Feedback loops

Growth loop (reinforcing via revenue)

More customers generate more revenue and more requests. Revenue raises cash; requests raise load on capacity.

Backlog loop (balancing via capacity)

When requests exceed capacity, pending work accumulates and waiting time rises. Adding capacity drains the backlog after its activation delay.

Retry loop (reinforcing load)

Failed attempts return as retries that compete with new work for the same capacity, raising cost per delivery and lengthening waits.

Service-feedback loop (optional, balancing growth)

If enabled, waits above your acceptable threshold add churn, which reduces customers and therefore demand.

Conventions

Time advances in whole daily steps across actual calendar months (28–31 days).
Monthly acquisition, usage, and expenses are spread evenly across the days of each month.
All quantities are deterministic expected values. Fractional customers and requests are permitted internally; displayed values are rounded only at presentation.
Requests are processed first-in, first-out by original arrival day. Within the same arrival day, requests with more prior attempts are processed first.
Retries become eligible no earlier than the next daily step (retry delay ≥ 1 day).
Waiting time is the number of whole days between arrival and successful delivery; same-day delivery counts as 0 days.
The daily delivery-delay metric is the mean wait of requests delivered that day; if none were delivered, the mean age of outstanding work; if no work is outstanding, 0.
Feedback startup rule: on day 1 no delay history exists and no additional churn applies. Until seven days exist, the available days are averaged.
Scheduled changes take effect on the first day of the stated month. If several changes target the same field and month, the last one listed wins.
Capacity additions commit on day 1 of their month (one-time cost paid then) and activate after the stated delay (recurring cost starts then).
Contribution profit = net revenue − payment fees − attempt costs. Operating result = contribution profit − operating expenses. Net cash movement = operating result − capacity one-time expenditure − initial setup.
Undefined ratios (for example cost per delivery with zero deliveries) are reported as undefined, never as zero.

Limitations

This is a simplified scenario model. It does not predict bank balances and is not financial reporting.
Expected-value modeling ignores variability: real daily demand, failures, and churn fluctuate around these averages.
Lower prices or higher marketing spend do not change acquisition unless you change acquisition assumptions explicitly.
The service-feedback relationship, when enabled, is your assumption. It is illustrative, not an empirically validated prediction.
Individual billing anniversaries, taxes, interest, receivables timing, and overage billing are not modeled.
Sensitivity ranges are conditional what-if scenarios, not statistical confidence intervals or probabilities.
Numerical correctness (the engine computes these equations faithfully) is distinct from real-world validity (whether the equations describe your business).