diff --git a/todo/sendoff/_index.md b/todo/sendoff/_index.md
new file mode 100644
index 00000000..a2f29d3c
--- /dev/null
+++ b/todo/sendoff/_index.md
@@ -0,0 +1,8 @@
+---
+theme: sendoff
+heading: 'SendOff'
+kind: theme
+---
+
+Sending files to your own machines, and to accounts that have allowed you. Landed 2026-08-23 as a folder
+convention plus one endpoint — `docs/sendoff.md` is the design, `src/servers/api/sendoff/` the code.
diff --git a/todo/sendoff/per-user-size-limit.md b/todo/sendoff/per-user-size-limit.md
new file mode 100644
index 00000000..bc812ffe
--- /dev/null
+++ b/todo/sendoff/per-user-size-limit.md
@@ -0,0 +1,30 @@
+---
+id: sendoff/per-user-size-limit
+title: 'The SendOff file size limit is one constant for everybody'
+theme: sendoff
+status: open
+created: 2026-08-23
+date_source: stated
+order: 1
+---
+
+**`MAX_FILE_SIZE` in `src/servers/api/sendoff/router.ts` is a hard-coded 512 MB and applies to every
+account equally.** The owner asked for it to be configurable per user, from settings, on the day the
+feature landed — 512 MB was chosen as "enough for now" rather than as a considered ceiling.
+
+Why it wants to be per-user rather than one server-wide number: the accounts differ in what they are for.
+The owner sending themselves a video off a phone and a member being allowed to drop a document are not the
+same size of thing, and the honest limit for one is an insult or a hazard for the other. A single number
+has to be set for the most generous case, which is exactly the case you would want to bound.
+
+Shape, when it is built:
+
+- An owner-only setting, per account, defaulting to the current 512 MB when unset. Absence means default,
+  not unlimited — the same posture the permission model already takes.
+- Enforced in `POST /sendoff/send` where the constant is read today, so there is one place it can be wrong.
+- The refusal has to say the limit it applied. A 400 reading "too big" against an invisible per-account
+  number is the kind of error somebody retries three times before asking.
+
+Worth deciding at the same time, because it is the same question one layer out: whether a **disk quota**
+belongs here too. A size limit bounds one send; nothing currently bounds how much a sender may accumulate
+in somebody's tree over a month, and the recipient's only tool is revoking them afterwards.