Why this exists

First, what it is. LatencyLab is a design-time latency simulator: you describe a planned or existing architecture as a small explicit model (the units of work, the events that trigger them and the shared resources they queue behind) and LatencyLab executes that model thousands of times with realistic timing variation. Out come the numbers a whiteboard cannot give you: how long the flow takes across percentiles, which chain of work actually held each run up and how often each chain is the culprit. It works on the design rather than the code, so it applies to any event-driven software: web backends, desktop and mobile UIs, microservices and embedded pipelines.

Latency discussions are dominated by intuition, confidence and post hoc profiling. By the time a real system can be measured, the decisions about concurrency, feedback, sequencing and delay have already hardened and are expensive to undo. Profilers explain where the time went in a running system; they rarely explain why the user waited.

LatencyLab moves the question to design time. You write an explicit model (tasks, events, queues, delays, resource contention: everything named, nothing inferred) and the engine executes it with deterministic scheduling and seeded randomness, thousands of times. Out come concrete critical paths that name the work, queue-wait figures and percentiles split between UI events and overall makespan, because those answer different questions: UI-event percentiles describe when the interface responded to the user; makespan percentiles describe when the whole piece of work finished. When numbers change it is because the model changed, never because the measurement drifted.

The results routinely betray intuition. In the shipped checkout model most people predict the slowest back end dominates perceived latency; instead a short debounce, added so the interface would feel calm, is the critical path in most runs. The same engine is one of the two instruments behind Relativistic Decision Architecture (the author's book on organisational structure): it produced the book's hierarchy-depth and authority-placement numbers from published models and seeds, so every quantitative claim there can be rerun.

What works now is a local Python CLI reading a JSON execution model, with a desktop UI as a client of the same headless core and plain-file outputs you can plot or diff. Fully keyboard navigable, 100% coverage gated, no account and no server. Your models and results never leave your machine; the desktop app's only outbound call is an anonymous daily ask to GitHub releases for whether a newer version exists. It does not tune code and it does not reassure; it exists so the latency problem is found before it is politically expensive.

Full reasoning at crankthecode.com.