Zero to a k6-and-JMeter competitor in four weeks

The first commit landed at 10:57 on 12 June 2026. By the evening of 6 July — twenty-four working days later, across roughly 180 commits — loadr had seven wire protocols, a QuickJS scripting engine, a WASM-and-native plugin system, distributed agents, a web UI, a signed Electron desktop app, a benchmark harness against the four incumbents, AI test generation, and a one-command algorithmic-DoS finder. This is the honest account of how a single binary went from an empty repo to a credible k6-and-JMeter competitor in four weeks — including the parts of "four weeks" that deserve an asterisk.

Day one was not a hello-world

Most projects spend week one wiring up a build. loadr spent the afternoon of 12 June landing the whole spine. Thirty-one commits went in that day, and they were not scaffolding — they were subsystems:

• feat(config) — the YAML schema, validation, interpolation and a generated JSON Schema (e45d67f).
• feat(core) — engine, executors, metrics, thresholds and the flow interpreter (da2fe24).
• feat(protocols) — an HTTP/1.1+2 timing client, WebSocket, dynamic gRPC, GraphQL, TCP and UDP (57c923f).
• feat(js) — a QuickJS engine with its own sandboxed standard library (8afa4a2).
• feat(plugins) — a WASM (WIT) and native (abi_stable) plugin system with a registry and four example plugins (a3b62bb).
• feat(agent) — distributed controller/agent gRPC coordination with HDR histogram merge (974753b).
• feat(convert) — JMeter .jmx and k6 script importers (591be61).
• feat(cli) — the loadr binary tying it all together: run / validate / convert / controller / agent / plugin / report / schema / completions, plus HTML reports and an e2e suite (2325ef8).

By the end of that first day there was also a full mdBook (b001019), six metrics exporters (f3fe0a2), a web management UI (87d0359), and the marketing site itself (0bbf8dc). The honest caveat: a burst like that is not thirty-one independent ideas invented between lunch and dinner. It is the crystallisation of a clear design that had been thought through before the git init — the commits are the moment it became real, not the moment it was conceived. The velocity that followed is what tells you whether the foundation was any good.

Week one: sharpen the core, ship a release

The days after the initial drop were about making the engine expressive enough to replace a real k6 or JMeter plan. Flow control arrived fast — repeat/while/if/random feeders and throttling (96456d2), then foreach, switch, retry/tryMax, parallel http.batch and a rendezvous barrier (44f76aa). SSE, Redis and a browser protocol landed end-to-end (bde7646, 5d52912).

Crucially, on 14 June the project stopped being a private prototype: 980646c wired up semantic-release with multi-platform SLSA-signed binary releases, cutting v1.0.0. From that point every merge to main that touched real code cut a signed, provenance-attested release automatically. That single decision is most of the story — it turned "is it releasable?" from a weekly event into a property of every commit.

Week two: a plugin ecosystem, not a feature list

The second wave (15–16 June) is where loadr's architecture earned its keep. Rather than compile every database and broker into the binary, protocols became installable native plugins. The plugin install resolver, index and downloader landed (4a9fd65, merged in #9), and then the protocols poured in as separate cdylibs: MongoDB (#6), PostgreSQL and MySQL as split plugins (#10), then Kafka, Redis, Elasticsearch and RabbitMQ (be51f18, 3264a4d, 6954f50, 60a9d4f). A dedicated plugin-release-ci pipeline built, signed and indexed each one (#7), and plugin-v1.0.0 shipped on 15 June.

Then the reach extended past Rust: #19 added a plain C-ABI path so any language can implement a protocol, proven with a Go go-echo plugin (#21). Keeping the core binary small while covering Postgres, Kafka, Cassandra, MQTT and the rest is only affordable because the plugin boundary was there on day one.

Week three: the desktop app and the benchmark that had to be honest

On 19 June the Electron desktop app started, and it went from scaffold to signed release in about forty-eight hours — seven milestones, #29 through #38: a schema-shaped form composer with two-way Monaco sync, drag-and-drop flows, live run metrics, a plugins panel, then packaging with a Playwright-for-Electron acceptance suite and a semantic-release train of its own. desktop-v1.0.0 shipped on 20 June. Two of the messier lessons — a macOS EBADARCH crash for Intel users and release trains stealing each other's releases/latest — cost real debugging (#51, #44), which is what you'd expect when three independent release trains share one repo.

The benchmark harness (#37) was written to be falsifiable, not flattering: all five tools drive the same Dockerized Go target, one at a time, over the same closed-model scenario, each parsed from its own native output. On one developer machine:

The README says it plainly: absolute numbers vary by host — compare tools within a single run, not across machines. But the shape holds, and the harness is in the repo for anyone to re-run.

The same week added HAR import with heuristic auto-correlation (#27), Homebrew and Scoop packaging (#46), a first-party GitHub Action with JUnit reports (#48), and the standout no other load tool ships: generate a validated plan from plain English or a whole repository (#47) — generate, run loadr validate, one repair round, behind a mocked LLM seam with 139 unit tests.

Week four: from load generator to performance workbench

The final stretch stopped adding protocols and started adding judgement. The workflow release (#71, 4 July) shipped six features in one wave:

• loadr compare baseline current — per-metric regression verdicts with tolerance rules and an --assert gate that exits 99 for CI.
• loadr sweep --var vus=10,50,100 — a parameter-matrix runner with a combined comparison matrix.
• SLO thresholds in SRE language: http_req_duration: [ "slo(99%) < 300ms" ].
• observe: [{ type: system }] — a background /proc sampler on the load timeline.
• loadr convert access.log — nginx/apache logs into a weighted arrival-rate plan.
• Chaos faults: — latency jitter and drop-rate injection; a 0.3 drop-rate run observed 32.5% http_req_failed and faults_injected=1346.

Then the capstone (#74, 6 July): a new loadr-payload crate with 18 adversarial generators and loadr sweep --complexity, which fits response time against input size on a log-log least-squares line, labels the order, and exits 99 when it exceeds a bound. Pointed at Gitea's /api/v1/markup, it fits O(n^1.6) and fails a --max-exponent 1.2 gate — detecting goldmark's super-linear blowup automatically. A load tester that finds DoS bugs.

What "four weeks" actually bought — and cost

Four weeks of calendar time is real, but it is not magic. Three deliberate choices did the heavy lifting. First, a small, sharp surface: one binary, snake_case typed outputs, a plugin boundary that kept the core from bloating. Second, a Rust workspace — eleven crates (loadr-core, loadr-config, loadr-js, loadr-protocols, loadr-outputs, loadr-plugin-api, loadr-agent, loadr-convert, loadr-payload, loadr-browser, loadr-cli) that let protocols, engine and CLI move independently without a monolith's merge pain. Third, heavy CI: semantic-release plus SLSA provenance meant releases were a side effect of merging, not a task — the price paid up front in 980646c and the release-train fixes (#45, #52) bought free shipping for the rest of the month.

The honest debits: much of the log's tail is CI plumbing, brand churn, and de-flaking web UI pollers (27fa6fc) — the tax of running three release trains from one repo. Some days were huge (33 commits on 15 June); some were a single fix. The benchmark is one target on one machine, not a lab. And "day one landed everything" is true of the commits, not the design behind them.

None of that undercuts the result. In four weeks loadr went from nothing to a single binary that imports your JMeter and k6 scripts, speaks seven-plus protocols, scales across agents, ships a desktop GUI, generates tests from English, and finds algorithmic-complexity bugs — each capability landed on a foundation that was built to carry it. The velocity wasn't the point. It was the receipt.