Docs · Understand · Case study: dropyour

Case study: dropyour, shipped with runward.

dropyour, a live product built with runward end to end: 17 ADRs, 60 tests, measured on real traffic, a green gate. The proof a method holds, gate by gate.

A method is proven by a product that shipped, not by a demo. dropyour was built with runward end to end — from framing to production, the full chain in a day. That day is a function of scope, deliberately small here (three ports, one operator): on a client mission the same chain takes the weeks the mission contract states — the depth is chosen, the gates are the same. What follows is the trail, gate by gate.

The six gated phases, from idea to production

The product

dropyour instantly hosts the standalone HTML files that AI harnesses produce (Claude, ChatGPT, Cursor, v0). Drop a .html, get a link in under 5 seconds, no account. Deployed on the Cloudflare edge, two origins, EU storage, an MCP server for agents. Live at dropyour.io.

A running product, with anti-abuse, GDPR, and an address promised to last to its users. A product, not a slide.

The method, gate by gate

The agent builds the system; runward is the path it takes, and every gate is crossed on evidence, never on a claim. Here is where each gate landed for dropyour.

Phase	What dropyour did	The proof at the gate
Frame	Problem (two observed personas), value (10 min of deploy cut to 5 s), one observable success criterion	Criterion written down: median time-to-link under 5 s, on ≥ 10 real drops, on the deployed system
Architect	Three domain ports (storage, metadata, scan), two Worker entrypoints, the model kept out of the decision path	Boundaries decided, stack still open; the LLM scan sits behind a port and can only quarantine
Floor	The smallest running system that proves the gesture, on real traffic	Median time-to-link 420 ms, 10 real drops out of 10, replacement at a constant URL demonstrated
Govern	Threat model (the lethal trifecta kept broken), evaluation rubric, observability schema	Instrumented from day zero; anti-abuse laid at the foundation, not retrofitted
Iterate	Paste, QR, view counter, settings, then the real domains (one origin per drop)	Each addition tied to an objective trigger, not to a whim
Hand over	Executable runbook (takedown, recovery, launch checklist); the succession demonstrated	The sponsor — the human operator, where the agent had built the system — replayed the proof without the agent, following the runbook alone: 10 drops out of 10, median time-to-link 524 ms. Mission closed

The decision that matters most is in Architect: the model stays out of the path. Deterministic code decides first; the model proposes, the domain disposes. That is the same boundary runward's own gate keeps — the model lives upstream, never in the verdict.

What the trail leaves

A method is judged by what it leaves behind. dropyour left an auditable record, not a memory:

Artifact	What it is
17 ADRs	Each dated, with its discarded alternatives and a re-evaluation trigger. Six weeks later, "why this choice?" has a written answer
60 deterministic tests	Plus a re-runnable measurement script — the numbers above can be reproduced, not taken on trust
A gap analysis	What shipped mapped against the full V1: every gap with its trigger, zero hidden debt, zero decision left to ratify
A green `runward check --strict`	Plain, deterministic code — the decisions that keep the system alive were made and written down, verified and sealed, impossible to talk into passing with a prompt

One artifact, opened

Counts are claims; here is what one line of the record looks like. ADR-0005, the day-zero anti-abuse decision, in translated excerpt (the dropyour repository is private — the trail ships with the product, so the record is quoted here rather than linked):

ADR-0005 — Day-zero anti-abuse: deterministic fail-closed scan behind ScanPort, pseudonymized rate limiting, badge injected at serve time (original blob intact) · dated, status: accepted

Decision — three day-zero defenses, all deterministic and testable: a fail-closed ScanPort verdict at upload ("any scan error means reject: publishing is an action, not a read"); per-IP rate limiting on a daily-salted hash, the raw IP never stored; badge and security headers injected at serve time, so the stored file stays the user's original.

Alternatives discarded, on the record — an LLM scan in the publish path from day one: "a probabilistic scan in the publish path with no evaluation rubric would be ungovernable — the deterministic first, the model on trigger" (deferred, with the trigger written down). A badge sewn into the blob: corrupts the original, rejected. A day-zero captcha: friction with no measured abuse signal, deferred with its trigger.

Consequences, accepted in writing — static rules will miss some cases; accepted at the floor, and said so.

Every one of the 17 ADRs has that shape: dated, decided, alternatives discarded on the record, consequences accepted in writing. runward check --strict verifies the presence, pointers and integrity of that record — never its quality; the quality is what you just read, and judging it stays a human's job.

Dosing the discipline

The stopping tier sets how far the method runs: framing only, the floor, or the full chain. dropyour took the full chain because it had to hold — existential anti-abuse, firm GDPR, an address promised to last, real users. That is where the discipline pays for itself. A 500-line throwaway would take far less; the point is that you choose the depth on purpose.

The point

dropyour shipped, runs in production, and could be picked up by another team without its original author, because every decision is traced. That is the proof a method holds — and it is the same audit-ready evidence runward leaves on any mission.

dropyour.io for the product. npx runward init for the method. The full argument sits in After the spec: the comparison.

← Docs