Frontier Products Have No Priors.

A frontier product ships a capability that did not exist last quarter. That single fact removes almost everything a product team normally leans on: the expectation users arrive with, the competitor screen to borrow from, the pattern library, the research base, the best practice.

You are not reading the case study out here. You are writing it, in public, with your own money.

At the frontier there is no prior art. There is only the bet and the instrument you point at it.

What actually makes a product frontier?

One test: could this have shipped 12 months ago, at any budget, with a bigger team?

If the answer is yes, you have a good product and a normal one. Competition is about execution, and the playbook applies.

If the answer is no, the capability itself is the new thing, and every input you would normally use to de-risk it was generated in a world where the capability did not exist. That is the whole difficulty, and most teams meet it by pretending the first case is true.

Why can't you research your way there?

Because people evaluate the unfamiliar against the nearest thing they know, so they ask you for the nearest thing they know.

Show someone a capability with no analog and they will describe the analog. That feedback is honest. It is also a description of the past, and acting on it produces a faster version of what already exists.

What research still does well is find the job and the suffering. Where does this person lose 40 minutes today? What do they do twice because the tool cannot do it once? Those answers are durable. Ask instead whether they want the thing that has never existed, and you are asking someone to rate a memory they do not have.

So the discovery loop changes shape. You form a thesis about the job, ship the smallest complete version of the capability, and instrument it with the measurement that will prove you wrong. The bet is unavoidable. The only question is whether you took it with an instrument attached.

What replaces the playbook?

Three things, in order.

Analogy discipline. Borrow the interaction model, never the layout. People know how to scan a list, undo an action, and trust a progress indicator. Those are transferable. The screen from a product that solves a different problem is not.

Instrumented bets. Every frontier feature ships with the number that would falsify it, chosen before launch. I ran a visibility probe of one model that found no answer naming Orbyt and I published it anyway, because a zero with a method beats a feeling with a narrative.

Smallest complete capability. Not a demo of a big idea. One job, finished all the way through, including the failure states. A frontier demo that impresses and then breaks teaches the market that the capability does not work yet.

What happens when the capability commoditizes?

It will, and faster than your roadmap assumes.

In one quarter my best model was released, export-controlled out of every account for 19 days, and restored, a rival lab shipped open weights at frontier level, and a silent default change repriced every token budget I had. Four forced decisions in 12 weeks, none with notice.

A feature that is the entire product in March is a checkbox by September. So the durable asset is never the capability. It is what the capability sits inside: the workflow, the trust, the data you originated, and the fact that you were the source rather than the echo.

My version of that is a compensation dataset covering 15 million data points across 3,445 roles and 81 cities, deposited under a registered DOI (opens in a new tab) with an open license. The model that generates the analysis is rented. The dataset is mine, it is citable, and it does not deprecate.

Rent the capability. Own the thing it produces.

What do users need most out here?

Legibility and reversibility, well ahead of polish.

New capability plus opaque behavior is how a product burns its trust in a single incident. Show what the system did and why. Make consequential actions undoable. When verification is ambiguous, deny rather than proceed, because at the frontier your users have no intuition for what the product should have done, which means they cannot catch it being wrong.

That is why I built Orbyt with the harness first: 850K lines and 57,380 tests behind a product I built solo in 32 days. Speed at the frontier is only survivable when something other than your attention is checking the work.

What to do Next

Write down the capability your product depends on and date it. When did it become possible? If the answer is more than 18 months ago, you are competing on execution and this post is not about you.

If it is recent, do three things. Name the job, not the feature. Pick the number that would tell you the bet failed, and ship it with the feature rather than after. And write the sentence that explains what happens when the capability is wrong, because that sentence is your product, on the day it matters most.

Then publish what you learn. The operator behind you is looking for exactly the write-up that does not exist yet, and being the source is the part that compounds after the capability is everywhere.

At the frontier, the study you want to read does not exist. You are the study.

Related reading:

• The Frontier Isn't a Place. It's a Pace. what the churn costs, quarter by quarter
• AI-Native Frontier Building: Core Concepts the definitional version of this argument
• I Built an AI Visibility Probe. It Said Zero. an instrumented bet, published honestly
• Invisible UX Is the Future of AI what legibility looks like when the capability is doing the work
• The Best AI Products Go Unnoticed why the products worth copying stay invisible