Systems‑First Prototyping: The 3 Rules That Save Sprints

Why systems beat features (especially early).

Features impress in demos; systems compound across the project. When you front‑load system clarity, every feature you add later is cheaper and safer because it plugs into a known contract. This is how we keep 7–14 day sprints honest at TARC: tiny, clean slices anchored to a few non‑negotiable rules.

Rule 1 — Define Inputs & State (before writing code)

If inputs are ambiguous, every fix is a fork.

List the external inputs (player commands, network packets, config flags) and the authoritative state your system owns. Document the state transitions as plainly as possible.

Checklist

1. What are the inputs? Where do they come from? (device, RPC, file)
2. What state do we own? What can mutate it? (tick, event, user)
3. What are the valid transitions? (diagram arrows > prose)
4. What happens on bad input? (drop, clamp, queue)

Example (game): In a deterministic combat slice, inputs are intent events (e.g., Attack(A) at tick N). Authoritative state is the battle timeline (ticks, statuses). Transitions are formal: intent → validation → queued action → resolution tick. No side effects outside the resolver.

Example (web): In a Next.js + NestJS WebGL backend, inputs are HTTP requests with JWT and CSRF headers; state is user session and match queue. Transitions: login → issue tokens → refresh → revoke. Undefined transitions (e.g., refresh without cookie) return a single, consistent error.

Rule 2 — Prove Loops in Isolation (not the whole feature)

The smallest useful slice is a loop that closes.

Every system has a loop: input → process → output → feedback. Build and test that loop alone, without UI chrome or content. You want to know if the mechanism works before you decorate it.

Checklist

1. What is the loop’s success signal? (value changed, event fired, frame stable)
2. Can we run it headless? (editor tool, test harness)
3. Can we simulate edge conditions cheaply? (seeded RNG, fake latency)
4. What metrics prove it’s stable? (time, allocations, error rate)

Example (game): For a lighting pass, the loop is power‑on sequence: fuse → volumes → flicker → steady state. You don’t need final textures—just a readable transition curve and timings.

Example (web): For a refresh‑token flow, the loop is obtain → store → rotate → revoke. A Postman collection + a tiny CLI can prove it works under rotation and expiry without a single pixel of UI.

Rule 3 — Log Deterministically (so reality is debuggable)

“Works on my machine” dies when every run is the same run.

Deterministic logging means two principles: stable order and replayability. If you can replay inputs and get the same outputs, you can debug, QA, and scale with confidence.

Checklist

1. Capture inputs with a timestamp/tick.
2. Keep a canonical order of events (sort and store).
3. Make logs machine‑parsable (JSON lines) with version tags.
4. Add a cheap replay harness that reads logs and re‑simulates.

Example (game): Record Intent@Tick and state diffs. A headless ReplayRunner consumes the log and renders overlays (tick, RNG seed, diff count). Bugs become data, not opinion.

Example (web): Log auth transitions (issue, refresh, revoke) with request IDs. Replayed transactions should result in identical DB state under the same seed/clock.

Pulling it together: a 7–14 day Systems Sprint

We structure early sprints around these rules:

Day 1–2 — System Map & Contracts

1. Inputs & state defined, transitions diagrammed.
2. Risks listed; success signals chosen.

Day 3–5 — Loop in Isolation

1. Headless harness/tests proving the loop.
2. Metrics captured; early edges simulated.

Day 6–7 — Deterministic Logging & Replay

1. Canonical log format + basic replay runner.
2. Debug overlays;

Day 8–10 — Thin UI + Integration

1. Minimal UI to visualize the loop.
2. Fit into the broader slice (e.g., menu → fuse panel → door open).

Day 11–14 — Polish & Handoff

1. Settings exposed;
2. Short doc: decisions, contracts, and “what breaks determinism.”

This sprint produces something shippable and explainable. Even if you pivot features, the system keeps paying rent.

Common anti‑patterns (and fixes)

1. Fidelity first. Fix: draw the loop; ship the mechanism; skin later.
2. Implicit contracts. Fix: write the inputs/state; treat UI like a client of your system.
3. Randomized QA. Fix: seed your RNG; capture intent logs; replay.
4. Hero debugging. Fix: make logs legible to anyone; publish a one‑pager.

Starter toolkit (grab‑and‑go)

1. One‑page System Map (PNG): inputs, state, transitions.
2. Replay Runner (CLI or EditorWindow).
3. Metrics Table: frame time, allocs, error rate.
4. Settings Scriptable: expose only what matters.

Conclusion

Chasing features leads to impressive demos and fragile code. Designing systems gives you durable progress. Define inputs & state, prove loops in isolation, and log deterministically. Do this for two weeks and you’ll feel the velocity shift.

CTA

If you want my Systems Sprint Outline (1‑pager) or a sanity check on your prototype, DM me “SYSTEMS” on LinkedIn. Teams that need help implementing deterministic replays can DM “REPLAY.”