An in-progress confession, written with revenue at zero.
We asked an AI to list the most valuable unsolved problems in technology. The model produced a strong list — provenance for AI-generated content, reputation scoring for autonomous agents, an underwriting data layer for AI insurance — each tagged with a commercial value estimate that ran into the billions. We read it carefully because the AI was thoughtful and the framing was the kind of cross-domain synthesis we had been hoping to get.
Then we noticed something. Three of the items on the AI's list of unsolved problems were products we had already built. Not vaporware. Not slide decks. Working code, published packages, signed documentation, downloadable artifacts.
The AI listed them as unsolved because, from the outside, they were unsolved. The solutions existed in the world's databases — PyPI, Zenodo, our own blog — but were invisible enough that the AI, trained on a corpus that includes most of those databases, could not see them. We had built the things. We had not been found.
This essay is about why that happens, why it happens so reliably, and what the data says about the choice the discovery left us with.
It is easier to write the rest of this paragraph than to write the next sentence. The honest numbers as of this writing: 70 published essays. 7 protocols on PyPI. 9 papers on Zenodo. A working cryptographic provenance stack. An EDGAR filing scanner. 509 cumulative views on a quantum-cryptography specification. 185 downloads of one of the compliance tools in a single day. Total paying customers: zero.
The first thing to say about this is that it is not unusual. Roughly 95% of startups fail, a figure consistent across multiple decades of CB Insights and similar venture data. Of the failures, more than 40% are attributed to lack of market demand rather than to product quality — the products were fine, the customers were absent. The median solo founder in 2026 earns approximately $3,000 per month, below the U.S. household median, and the visible $1M-plus founders represent something like the top 0.03% of the distribution. The headlines are survivorship bias on a 2,800:1 ratio. The pattern we are describing is the median, not the exception.
The second thing to say is that knowing this does not, by itself, change anything. The data has been available to anyone for a decade. Founders read it, nod, and keep building. There is a structural reason this is hard to act on, and naming the reason is the rest of the essay.
The cognitive style that makes someone excellent at building software is approximately the opposite of the cognitive style that makes someone excellent at being noticed. This is not a moral claim, and it is not a laziness diagnosis. It is a fact about the rewards each activity returns.
| Building rewards | Being noticed rewards |
|---|---|
| Depth | Simplicity |
| Precision | Emotion |
| Correctness | Timing |
| Completeness | Controversy |
| Documentation | Repetition |
| Testing | Luck |
These are not preferences. They are operational requirements. Code that ships requires precision because imprecision produces bugs. A tweet that spreads requires emotion because dispassion produces silence. The same individual can perform both modes in principle; in practice, the modes interfere with each other, and the person who has built the discipline for one has trained themselves out of the discipline for the other. The deeper the engineering excellence, the harder the pivot to attention.
Peter Thiel framed this in Zero to One as a category fact: “Poor sales — rather than bad product — is the most common cause of failure in most businesses.” The framing reads aggressively in person and turns out to be correct in aggregate. One distribution strategy usually dominates all others for any given company. The hard work is identifying and committing to that one strategy. The strategy is rarely “build a better version of the product.” It is almost always something that does not feel, to the builder, like real work.
A specific 2026 sharpening of this problem: AI has collapsed the cost of building to near zero, and one consequence is that building has become a procrastination strategy. Aldi Jayadi called this the “Prototype Paradox” in February 2026 — teams can now generate multiple homepage variations, onboarding flows, and dashboard mockups in hours, but “no real decision has been made, no assumption has been tested, and no user has seen any of it.” For a builder, this is intoxicating. You feel productive. The version control commits stack up. Nothing is wrong with the work. Nothing happens, either.
We have 7 protocols on PyPI. The honest question is how many of them were built after talking to a potential customer who said they would pay for the thing. We do not love the answer.
The framework Andreessen Horowitz formalized for this is distribution versus innovation. The line: “The battle between every startup and incumbent comes down to whether the startup gets distribution before the incumbent gets innovation.” Incumbents have customers, channels, and brand but need innovation. Startups have innovation but need distribution. Whoever closes their gap first wins.
The framework predicts our exact situation. Maximum innovation, zero distribution. An incumbent with a mediocre trust stack and 10,000 existing customers wins the trust-stack market by default, because closing their innovation gap takes one quarter and closing our distribution gap takes years. We are the cleanest possible case study of the asymmetry, because we have nothing to confound the analysis. No half-distribution. No accidental virality. No celebrity early adopter. Just a clean, dry, decisive zero on the distribution axis.
There is a famous counterexample to lay on the table. Cursor, the AI code editor, reportedly reached $100 million in annualized revenue in roughly one year with essentially no marketing spend. This sounds, on the face of it, like a refutation. Just build a great product. The customers find it. Stop overthinking.
The counterexample doesn't survive examination. Cursor served the one population in the world that discovers tools organically at scale — developers. Developers run GitHub, write tweets, post HackerNews submissions, record YouTube tutorials, and convert tool discovery into a social activity that resembles distribution even when no one is paid to do it. Cursor also launched into a market that was already desperate — millions of developers were actively searching for exactly an AI coding assistant. Demand preceded the supply. The product fit a hole that had been actively widening for two years.
If your customers are insurance executives, county treasurers, FDIC compliance officers, or anyone else who does not spend their evenings on HackerNews, the Cursor playbook does not apply to you. Cursor is the exception that proves the rule, and the rule is the part most builders need to hear: organic discovery is a property of the audience, not a property of the product. You can build the best version of a thing in the world. If the audience does not have a habit of discovering things, the thing does not get discovered.
Our products serve the AI-agent trust market. That market is real — the agent economy is reportedly $7.6 billion in 2025 and projected past $50 billion by 2030, growing fast enough that the unsolved-problems-worth-billions framing is literally accurate, not hyperbolic. The audience is also not on HackerNews in the same density as Cursor's audience. We are in the second category by default.
It is useful to look at the products that escaped the same bind we are in, because the moves they made were not improvements to the product.
Slack in 2013 was Stewart Butterfield's internal tool for a failed video game studio, with zero external users. The distribution move was that Butterfield personally emailed companies and asked them to try it. The first 8,000 users came from direct outreach. Slack was eventually acquired by Salesforce for $27.7 billion in 2021 — none of which happened until Butterfield started manually placing the product in front of users, one company at a time.
Dropbox in 2007 was Drew Houston's working file-syncing product that could not get traction. The breakthrough was a three-minute demo video posted to HackerNews that generated 70,000 signups overnight. The product had been done for months. The video changed; the product did not.
Tesla in 2008 had a Roadster that almost killed the company because nobody could test-drive an electric sports car. The breakthrough was celebrity test drives (Clooney, DiCaprio) and a referral program. The car was the same. The visibility changed.
The pattern across all three: excellent product, near-zero initial distribution, survival through a specific move that had nothing to do with improving the product. Manual outreach. A video. A celebrity drive. Heterogeneous interventions, one shared structural property — the founder accepted that more building was not the answer, and started doing the work that did not feel like the work.
Our quantum-cryptography specification has 509 views. The next 50,000 views are not going to come from a fourth specification. They will come from something Butterfield did, or something Houston did, or something we have not yet identified. They will come from a category of effort that, to a builder, does not feel like progress while it is happening.
There is a contemporary version of this that has produced documented outcomes, and is worth naming because the essay you are reading is, itself, an example of it.
Build in public is the practice of sharing revenue numbers, development progress, mistakes, and learnings openly while you build. Pieter Levels grew Nomad List and Photo AI past $2 million ARR while publishing his revenue dashboard live. Jon Yongfook took Bannerbear from zero to roughly $30,000 in monthly recurring revenue while documenting the journey on Twitter. Buffer published its full revenue dashboard publicly and converted transparency into a brand attribute that became the differentiator in a crowded social-media-tooling market.
The pattern, said clean: transparency about the struggle is the distribution strategy. The content that emerges from the building process — the mistakes, the metrics, the dead ends, the honest revenue — is the part the algorithm rewards. The product is downstream of the audience. The audience is downstream of the writing. The writing is downstream of being honest, in a market where most startup content is fictional metric reporting that readers have learned to discount.
This essay is doing the thing. We have just published our revenue (zero), our customer count (zero), and the fact that our own analytical AI did not recognize our products as solutions. We are inside a distribution strategy. If you are reading this, the strategy is, at the margin, working. If you are not reading this, the framing of the essay does not even register as a sentence, which is a different category of joke.
There is a particular self-referential structure to this situation that is worth naming explicitly, because once you name it you cannot un-see it.
Layer one: the team builds products that address unsolved problems. Layer two: the team's own AI classifies the products as unsolved, because they are invisible to the market that the AI was trained on. Layer three: the team writes about the discovery, using the irony as a distribution mechanism, attempting to make the products visible — and in doing so, attempting to falsify the very premise the essay is built on. If the essay succeeds in making the products visible, the essay's central claim (“our products are invisible”) becomes retroactively inaccurate. The essay is true while it is failing. It becomes false at the moment it succeeds.
This is a real logical loop, not a stylistic flourish. It is also, we think, the most defensible distribution advantage we have, because almost no startup content occupies this register. The two dominant registers are aspirational success stories (90% of startup writing — “how we hit $1M ARR”) and post-mortems (10% of startup writing — “why we failed and shut down”). The first is selection-biased. The second is written after the fact, with the emotional distance of closure.
What is rare is the in-progress confession — written while the outcome is unknown, with the company still alive, still building, and openly admitting that the current strategy is not yet working. Almost no one writes this. It is the most useful kind of writing for builders to read, and the least produced. It is rare for the same reason it is valuable: it requires writing it while you still have things to lose, and most founders cannot bring themselves to do that. We have zero customers, zero revenue, and zero outside investment, which is most of what there is to lose. That makes us, paradoxically, the right entity to write the document the category was missing.
If you are a builder reading this and recognizing yourself in the description, three moves follow.
The first is to write down the distribution function you are running. Not the product roadmap. Not the technical architecture. The specific sequence of operations by which a stranger turns into a paying customer. If you cannot describe it in three sentences, you do not have one. The first version will be embarrassing. Write it down anyway — the version on paper is the version you can iterate on. Builders are good at writing things down. Use the skill.
The second is to count attention as you count code. If you have a metrics dashboard for your service, build one for your audience. Views, downloads, replies, conversations initiated. Track it weekly. The metrics being small is fine. The metrics being uncounted is the problem.
The third, and the one that took us longest to accept, is to build less. AI has made the cost of building so close to free that building has become a way to avoid the harder work. The next feature, the next protocol, the next paper — each feels like progress and none is progress on the binding constraint, which is distribution. The discipline is to recognize the moment when the build is no longer the constraint, and to redirect the time. The essay you are reading is, in part, the redirection.
The closing question is the one we cannot answer yet. How does a small team and an AI agent system become loud enough for the world to hear? We do not know. We are running the experiment. The essay is the experiment.
If our products are still on the AI's unsolved-problems list a year from now, we did not figure it out. If they are not, whatever we did to take them off is the answer. We will publish either way.
Revenue: $0. Customers: 0. Products that work: 3. Products that matter: TBD.
The three products the AI said were unsolved.
Provenance for AI-generated content: Chain of Consciousness. Reputation scoring for autonomous agents: Agent Rating Protocol. The underwriting data layer that wraps both: Agent Trust Stack. All three are working code. All three have downloadable artifacts. Whether the next person who reads this essay tries them is the experiment the essay is running.
pip install chain-of-consciousness · npm install chain-of-consciousness
pip install agent-rating-protocol · npm install agent-rating-protocol
pip install agent-trust-stack · npm install agent-trust-stack
Hosted Chain of Consciousness → · See a verified provenance chain