Sign inJoin

Know what to build. Prove it was built well.

This product researches its own market, ranks what to build next, and has a suite of AI reviewers go over every run. Everything below came out of those runs, including the parts that do not flatter it.

See what it producedWhy the ranking holds
reviewers, from market research to security to marketing copy
findings filed, each with how it was known
pull requests opened from queued roadmap and backlog items
products reviewed end to end
What to build

A ranked list of what to build next.

The fastest way to waste speed is to point it at the wrong thing. Findings are measurements; a roadmap is the judgment laid over them: the few things worth doing next, each carrying the outcome it buys and the reason it beat everything else in the queue. That judgment is the part that does not get cheaper, so it is the part worth showing. The items below are real, pulled from the latest roadmap review as it stands today.

These are not a wish list. Mark an item to be built and an agent claims it where the repository actually lives, checks it still describes something real, and opens a pull request. The item, the review that produced it, and the change that answered it stay on one board.
What changed

It tells you what changed, and what only looks like it did.

Move quickly and the numbers move constantly, and most of that movement is not the product. Run the same reviewers over the same code twice and the raw counts shift, sometimes by a lot. So every review records which product it measured and which version of the reviewers did the measuring, and fingerprints the source. When the numbers move but the product did not, What Matters says so plainly, instead of reporting a change that never happened. A ranking is worth no more than the measurements under it.

01
The product measured. A fingerprint of the source alone, so a commit that only touched config never reads as a regression.
02
The reviewers that measured it. Two suites only compare if the reviewers were the same version both times. Uncommitted edits flag as a version that exists nowhere else.
03
How each finding was known. Seen in the running app, measured on the page, or only inferred from source. Never dressed up as more than it was.
Every dimension

Every dimension, in one language.

A fast build rarely decides to be sloppy. It skips the dimension nobody had time to check. So every reviewer runs every time, each looking at the product from a different angle and filing its findings the same way, with the same meaning for how serious a thing is. A security flaw and a broken journey end up on one page, ranked against each other, instead of in a pile of unrelated reports nobody reads.

And it reviews itself. A meta-critic checks the reviewers each run, and every defect it finds is recorded and tracked, not quietly forgotten.
Not only for engineers

Design, docs and product marketing, on the same run.

Speed is usually paid for out of someone else’s budget. The design system drifts, the docs describe a version that shipped two quarters ago, and the launch copy gets written the night before. These are the teams a fast build skips, so here they go on the same run as the code, in the same language. For two of them it does not stop at reviewing. It writes the first draft.

How it works

Reviewers produce. What Matters reconciles. You decide what gets built.

None of it is an event you schedule. It runs with the work, every time, which is the only reason the standard survives contact with a timeline.

STEP 01

The reviewers run

The reviewers inspect the product, each in its own way, and each files a report plus a small machine-readable summary in the one shared format.

STEP 02

What Matters takes them in

It stores what each reviewer declared, records the product and reviewer versions, and renders every review the same way, so any two can sit side by side.

STEP 03

You see the state, and the trend

One page for where the product sits today, and an honest comparison over time that separates a real change from a shift in the measurement.

STEP 04

You send work back out

Mark a roadmap item, a backlog item or an open defect to be built. An agent working where the repository actually lives claims it, checks it still describes something real, and opens a pull request. Each step is reported back onto the same board.

Held to its own standard

Every finding is a measurement, and confidence is shown wherever the signal is thin.

The suite has yet to return a clean run of itself, and its own open defects sit in the same queue at the same severities as every product’s. A reviewer that graded itself perfect would be the one to distrust.

10 products reviewed so far, each surfacing gaps in the reviewers the last one did not. That is why they are pointed at more than one.

Run it yourself

Point it at your own product.

Access is by invitation while this is early: say what you are working on, and it goes on a list I read myself. The page below walks through what happens after that, from signing in to the first review landing.

Join the waiting list

Why this is here

Building got cheap. Judgment didn’t.

What Matters tells a team building fast what to build next and whether it was built well: market research and a ranked roadmap before the work, and review across every dimension after it.

Decide what matters, build it, get something real back you can judge. The research and the roadmap say what is worth the effort; the reviewers say whether the effort landed. Neither half is worth much without the other, and the rigour does not come off either way to make the date.

Everything on this page is real output. Access is by invitation while it is early, and a person reads every request. The people using it now are running the same loop on their own repositories.

Join the waiting listHow it works