Software build cost is collapsing toward zero. The scarce resource is no longer engineering capacity; it is knowing what to build. I designed a protocol that turns market judgment into evidence the team can inspect, update, and reuse.
AI is compressing software build cost toward zero. A working prototype that used to require a small team and a quarter can now be shipped in an afternoon by one person with a model and a credit card. The bottleneck has moved.
When anyone can ship a product in a few hours, engineering capacity is no longer the constraint. The constraint is knowing what to build — which need is real, which is loud but shallow, which window is open for six weeks, which is already closed.
After watching that gap for a year, I built the instrument I kept wishing I had: a venture-studio engine that treats market judgment as a system, not a personality trait.
Watch how decisions actually get made in most product orgs and you see two failure modes, dressed up as the same thing.
Mode one: intuition. A charismatic founder argues by personality. The strongest voice in the room wins; the evidence trail behind the bet is selection bias plus a few screenshots. When the bet fails, no one can reconstruct why it was placed — so no one learns.
Mode two: the one-shot deck. A six-week research engagement produces 80 polished slides. The deck is read once, frozen, and quietly contradicted by every signal that arrives the following month. There is no protocol to update it, no protocol to compare it against a competing claim, no protocol to say where this argument is thin.
What both modes lack is the same thing: a way to take heterogeneous evidence from any source, compare it to a hypothesis, and tell you specifically where the evidence is thin, where it contradicts itself, and what to validate next. Not a verdict — a workbench.
The core abstraction is a five-entity data flow. Everything the system does — capture, evaluation, validation — sits on top of these objects.
External data platforms — public review sites, developer communities, search-trend services, product directories. A source is the upstream world the system listens to. It is described abstractly so the system stays steerable: I can swap or weight sources without rewriting the rest.
A collection rule bound to a source. A probe defines what to look for (keywords, scope) and how to look (cadence, threshold). One source carries many probes. Probes are how a vague interest like “watch the analytics category” becomes a concrete, schedulable instruction.
One piece of raw evidence captured by a probe — one post, one complaint, one issue, one query trend point. A signal is the atom: it cannot be split further and it always carries a link back to its source.
The key object. Multiple signals aggregate into an evaluable demand direction. Each opportunity carries a type: gap (supply-demand mismatch), trend (rapid attention spike worth a positioning move), or trigger (an external event — a competitor raising prices, an API shutting down — opening a window).
Opportunities that survive scoring enter a validation flow: landing page, user interviews, MVP, paid validation. Validation is not a slide deck; it is a sequence of cheap reality checks that either kill the opportunity early or hand it to an independent operator.
On top of the five entities sits an Evidence-Opportunity Match protocol. EOM does not make the decision for you. It compares explicit materials against a target hypothesis — a gap, a PRD, a product thesis — and returns the evidence trail: what supports the claim, what contradicts it, what is missing, and what should be validated next.
The scoring layer is deliberately conservative. It cares about evidence quality — specificity, freshness, source diversity, target fit, and visible contradictions — but the most important rule is the refusal rule:
A large market does not pass just because it is large. If the evidence does not show a credible path for users to switch, the system treats the opportunity as unproven, not ready to pursue.
That design choice keeps the system from rewarding the most seductive slide. The output that matters is not a magic score; it is the receipt underneath the score.
Sitting on the diagram above, I designed and shipped:
Software build cost is being compressed toward zero. When anyone can ship a product in hours, the scarce resource isn’t engineering capacity — it’s knowing what to build. The engine exists to make that judgment reproducible.
What the system actually changes about day-to-day operator work is concrete and unglamorous. In the demo corpus, the engine had already organized roughly 7.7K signals, 5.5K products, 80 tracked probes, and 16 identified opportunities. The point was not the raw count; it was that the market map could keep updating after the first research pass.
More importantly, the unit of argument changes. “I think this is a big market” gets replaced by an evidence trail: here is the evidence behind the claim, here is where it contradicts itself, here is the missing evidence that would change the decision. The argument is no longer about who is more confident; it is about whose evidence chain holds up.
I started this work thinking the value of a research system was the ranked list it produced — a clean ordering of opportunities, big to small, with a number next to each one. I was wrong about which part mattered. The ranked list is the byproduct. The actual product is everything that sits underneath the number.
What an operator actually uses, day after day, is not the score. It is the list of named contradictions the system surfaces — places where two pieces of evidence say opposite things and someone has to choose which one to trust. And it is the missing-evidence list — the specific gaps that, if filled, would move the score enough to change the decision. Those two outputs are what turn a vague feeling into a falsifiable plan.
The score is the wrapper. The contradictions and missing-evidence list are the real substance.
The lesson: a research system that only outputs an answer is theater. A research system that outputs an answer plus the specific shape of its own uncertainty is an instrument. Build the second one, even though it makes you look less decisive in the meeting where you present it.