Everything we build for other people, we ran on ourselves first. Four months in, the outputs are countable: 114 documents totalling over a thousand pages, research consolidated in batches — one of them 118 separate entries in a single pass — and a written record of every working session.
None of that is the point. The point is what the accumulated record does when you ask it something.
Three times it told us we were wrong
A founder hypothesis. We were confident that a particular market could be entered on price, because the incumbent tools were expensive. Two studies ran against it. The verdict, in the record: right about the prices, wrong about price being the way in. The strategy changed from selling a cheaper tool to selling an outcome.
A market we assumed was ours. A research pass turned up an established competitor operating in our own city that we had somehow never recorded — with real scale and real revenue. It also concluded that a category we had been treating as a separate line of business was not one. We stopped planning around it.
And the uncomfortable one. A proposal already in front of a client described a feature as something nobody else had. A research pass tested that claim and marked it false, because a very large consumer app had shipped something nearly identical. The document was narrowed and a legal caveat added before the conversation went any further.
The claim was already written. It just had not been checked yet.
Why this is the actual product
Every company has a set of things it believes that were true once. A competitor who has moved. A price that has shifted. A differentiator that stopped being one when somebody else shipped it. These beliefs are load-bearing — they sit in proposals, in pricing, in what the sales team says out loud — and almost nothing in a normal business is designed to challenge them.
A shared knowledge system that only stores things is a filing cabinet. What makes it worth the effort is that it can be pointed at one of your own claims and asked whether it still holds. That is an unglamorous capability and it is the one that pays.
The condition
It only works if the record is honest about itself. Our session logs contain entries where the system corrects a claim it made earlier the same day — including one that reads, plainly, that a statement made mid-session was wrong.
A knowledge base full of tidy successes cannot do this work. It has no way to distinguish a checked claim from a confident one, so everything in it reads equally true, and it will hand you your own optimism back with a citation.
That is the whole design decision, and it is a cultural one before it is a technical one. Record what failed, in the same place and with the same weight as what worked. Then the thing you built can be trusted to tell you something you do not want to hear.