Ask an engineering team what they shipped last quarter and you’ll get a crisp answer: a changelog, a burndown, a wall of merged pull requests. Ask the same team what any of it did — whether users signed up faster, activated more, stayed longer, paid — and the room goes quiet. Somebody opens a dashboard. Somebody else says “hard to isolate.” The honest answer, most of the time, is that nobody knows.
This is strange, when you say it out loud. We instrument everything up to the moment code lands. Tests, CI, code review, deploy tracking, error rates, latency graphs. Then the code reaches real users — the entire point of writing it — and the instrumentation stops. The feedback loop that runs so tightly through development quietly dies at the merge button.
Output is easy to measure. Outcome is the thing that matters.
The reason we drift here isn’t laziness. It’s that output is trivially countable and outcome is not. Pull requests merged, story points closed, deploys per day — these are right there, already logged, and they feel like progress. So they become the metrics, and a team can run for years on a scoreboard that measures effort while never once checking the result.
The trouble is that a company doesn’t run on velocity. It runs on sign-ups, activation, revenue, retention — the numbers it would actually notice if they moved. A quarter can be enormously productive by the output scoreboard and completely flat by the one that pays rent. If you only watch the first, you can’t tell the difference between shipping a lot and shipping things that worked. Those are not the same skill, and confusing them is how teams get very busy going nowhere.
Velocity measures how hard the team is rowing. It says nothing about whether the boat is pointed at the shore.
Every deploy is a hypothesis
Here’s the reframe we keep coming back to: a deploy is not the end of a task, it’s the start of an experiment. You believed that redesigned onboarding would lift activation. You believed the new pricing page would convert. You believed removing that step would cut drop-off. Each of those is a claim about the world, and the moment you ship, the world starts answering.
Almost nobody stays to hear the answer. The ticket is closed, the PR is merged, the team is three features down the road before the numbers even settle. So the belief that justified the work is never checked. You keep shipping on instinct, and instinct never gets corrected, because correction requires looking back at a specific change and asking what happened after it. That’s the exact loop most tooling refuses to close.
What we built to close it
This is the gap code-results exists to fill. It’s a simple, stubborn idea: take a deploy — a real, dated event, not a guess — and line it up against the handful of business metrics a company genuinely watches. Sign-ups, activation, revenue, retention. Every metric has a before and an after. code-results puts the deploy on that timeline and shows you what moved once your change reached production, read by the same team that shipped it.
The discipline is in what it refuses to do. A deploy and a metric moving at the same time is a correlation, not a proof, and we don’t dress it up as one. Ship into a holiday spike and revenue climbs for reasons that have nothing to do with you; a genuinely great feature can land the week a competitor undercuts you and read as flat. code-results draws the line clearly and lets you read it like an adult — a strong signal you go investigate, not a gold star it hands out. Honest correlation you can act on beats fabricated causation every time. The goal isn’t to declare victory. It’s to make the question askable at all.
Why a tiny studio cares about this
We didn’t come to this from theory. We came to it from operating our own products, which is the one rule this studio runs on: we only build what we run. Operating a product is where you learn that shipping and succeeding are different events, sometimes by weeks. We wanted the shape of that answer for our own work — did that change do anything? — and found that the tooling to see it barely existed.
So we built the thing we needed, the same way ganttchart.ai came out of wanting a plan in the ten minutes before a meeting. code-results is what it looks like to take the studio’s oldest belief — a launch is the start of finding out if you were right — and turn it into something you can actually watch happen.
The scoreboard that counts what you shipped will always be easier to keep. It’s also the one that lets you fool yourself. The harder scoreboard — did it work? — is the only one the business is actually keeping, whether you look at it or not. You may as well look.