trolls.dev
05 The workbench — case study

code-results

See the impact of your code on your business.

code-results ties every deploy to the numbers that moved after it — sign-ups, activation, revenue — so the team that shipped a change is the first to see whether it worked, not the last. The feedback loop that used to end at the pull request finally reaches all the way to the business.

Status
Live
Platform
Web
Field
Product analytics · Engineering
Cadence
Every deploy
Open code-results ↗ All work
code-results.com Live
The ship
deploying… ✓ deployed a1f3c92 · ship checkout redesign
The result
Sign-ups
+18%
Activation
+12%
Revenue
+9%
a1f3c92 → +18% sign-ups attributed
dashboards opened · 0 the team that shipped it saw it first
Every deploy is a hypothesis. The business is where it's proven. The bet behind it

Why we built it

The feedback loop ends at the pull request.

A change goes green, gets merged, and deploys. And then, for the people who built it, it mostly goes quiet. The tests passed, the error rate held, nobody paged — so on to the next ticket. The one question that started the work — did this actually move anything for the business? — quietly goes unanswered.

It isn't that nobody's measuring. It's that the measuring lives somewhere else: a BI tool owned by another team, on a monthly cadence, in a review three weeks out where a hundred changes get averaged into one blurry line. By the time a number lands, no one can say which deploy earned it. The people who could learn the most from the result are the furthest from it.

So teams ship on faith and vanity charts — pageviews that always climb, clicks that mean nothing. The loop that makes engineering a craft, where you see the result and adjust, gets severed at the exact seam where code meets consequence.

Shipping without seeing the result isn't iteration — it's just motion.

What we made

Four moves, one line.

  1. 01

    A deploy is an event, not a guess

    code-results marks the exact moment each change goes live and watches the numbers from there. Instead of asking whether the quarter went well, you can ask whether Tuesday's checkout rewrite went well — because the release has a timestamp and the metrics have a before and an after.

  2. 02

    The metrics that pay rent

    Sign-ups, activation, revenue, retention — the numbers the business actually watches, not the vanity counters that only ever go up. Each deploy is read against the handful of outcomes a company would notice if they moved, so a green line means something.

  3. 03

    Attribution you can argue with

    Every change is shown against its own baseline — the trend before it shipped — so you can tell a real lift from ordinary noise. And the number traces back to the commit, so a claim about impact points at the exact code that made it.

  4. 04

    Built for the people who shipped it

    The readout lives where engineers already are and moves at the speed they already ship — not buried in a BI tool owned by another team on a monthly clock. The person who wrote the change is the first to see what it did, while they still remember writing it.

What we decided

The calls that shaped it.

A tool that measures impact can lie as easily as it can inform. Most of the work was in the restraint.

  1. 01

    Correlation, honestly labeled

    We show what moved after a deploy; we don't dress correlation up as proof. The tool draws the line clearly and leaves the last inch — was it really the change, or the season? — to the judgment of the person who knows the code. A dashboard that overclaims is worse than none.

  2. 02

    One number per change, not a maze

    It would be easy to ship a wall of forty charts and call it powerful. We didn't. Each release gets the one honest read on whether it earned its place, because a signal you have to hunt for is a signal nobody checks.

  3. 03

    Business metrics, not busywork ones

    Clicks and pageviews are cheap to move and easy to fool yourself with. We pointed the tool at the outcomes that actually keep the lights on, so shipping toward the number can't drift into shipping toward the flattering one.

Further reading from the journal

Why we only ship products we run ourselves — and read every result — is in Why we only build what we run, and the case for keeping a tool small enough to tell the truth is in In defense of small software.

code-results reports what moved after a change shipped. It's built to surface an honest signal, not to settle causation — the judgment of the person who knows the code closes the last inch.

Colophon End of Case Study 05

See what your last deploy actually did.

Connect the code you ship to the numbers your business watches, and let the team that wrote the change be the first to see whether it worked.

Open code-results ↗ More case studies →