I fact checked my own launch copy against the codebase. Two of three claims were dead code.
I had a launch brief. Three headline claims, each one a moat, each one written by someone who had read the docs and the code layout.
Before shipping it I ran one boring check on each claim: grep for the call sites. Not "does this module exist". Does anything in the live path actually call it.
Two of the three did not survive the hour.
Claim 1, killed: "we refuse to spend your application on a ghost job"
Great line. There is a whole service directory for posting legitimacy. It is documented. It has modules for reposting detection, hiring velocity, layoff cross-checks.
It has zero callers in the apply path. No gate, no skip, no check. There is no code path in which a legitimacy verdict prevents an application from being sent.
It got worse the further I looked. Three of its eight modules have no production callers at all. One module's only caller itself has no callers. The database column that stores the verdict is usually null, because the report that computes it is generated on demand in a tab most people never open. And the discovery feed had been deliberately changed months earlier, by my own decision, to admit stale rows.
The score that does get computed is: posted recently, salary disclosed, description over a length threshold. That is recency, pay transparency and word count. It is a reasonable heuristic. It is not ghost-job detection, and marketing it as a moat would have been a claim I could not defend the first time somebody asked.
Claim 2, killed: "native iOS and Android apps"
There is a mobile app in the repo. It builds. It runs.
It has never been submitted to either store. No App Store Connect identifiers in the build config. Both developer accounts still pending. The claim was going to appear on a launch page next to a screenshot of something nobody could install.
Claim 3, survived: "you are never charged twice for the same posting"
Real. Enforced in code, with a ledger, on the path that actually charges people.
So the honest launch has one moat, not three. That is a worse brief and a much better product page, because it is the one I can still stand behind in a comment thread six months from now.
The check itself, since it takes ten minutes
For every claim in your launch copy:
- Find the function that would have to run for the claim to be true.
grep -rn "functionName" src/and look at what calls it, then what calls that.- If the chain does not reach a real request path, the feature exists and the claim does not.
- Bonus: check the database column it writes. If it is null in production, nothing has been running it.
A feature that exists is not a feature that runs. I wrote all of that code. I still got two out of three wrong, because "I built it" and "it is in the path" feel identical from memory and are completely different in the repo.
The uncomfortable part
The brief was produced by a serious research pass over my own documentation. The documentation was accurate. Every module it named exists exactly where it said.
Documentation describes what was built. Only call sites describe what runs. If your marketing is generated from your docs, and your docs describe intent, you will confidently ship claims about code that has never executed for a single user.
Grep before you launch. It is the cheapest fact-check available and it is the one nobody runs on themselves.
Solo founder. Not linking the product here, but happy to answer anything about the audit in the comments.
The deepest line here is one you almost throw away: "I built it" and "it is in the path" feel identical from memory. That's not a docs problem, it's epistemics. The person who wrote the code is the worst-positioned to fact-check claims about it, because memory encodes intent as fact. The grep works precisely because it removes you from the loop, an external witness on your own work.
But I'd push on the framing: this isn't a fact-check, it's a positioning filter, and a better one than most founders use. "Which claim can I defend in a comment thread six months from now" beats "which sounds most impressive," because it selects for the moat that's real AND that you'll never walk back.
Which raises the real one: does the surviving claim (charged once, ledger-enforced) actually differentiate you, or is it just table stakes that happens to be true? Defensible and distinctive aren't the same, and a launch needs both.
"Memory encodes intent as fact" is the sentence I was reaching for and did not find. That is exactly the failure. I did not misremember whether the code existed, I remembered deciding it mattered, and those feel identical from the inside years later.
You are right that it is a positioning filter rather than a fact-check, and reframing it that way makes it cheaper to run, because a fact-check feels like an audit you schedule and a filter is just how you write.
On the surviving claim: yes, and it survives for a duller reason than I would like. It holds because it is the thing the product physically cannot avoid doing. The agent has to reach the employer's form and press the employer's button, so either something arrives on their side or nothing does, and that is observable without our cooperation. The two that died were both features I could have shipped or not shipped without the product noticing. That is the actual pattern, I think: a defensible claim is usually one where the mechanism has no way to skip the work.
The uncomfortable corollary is that it is defensible and not unique. Anyone willing to drive a real browser can say it. I would rather stand on a claim that is true and copyable than one that is distinctive and quietly false, but I do not want to pretend that is a moat.
You've landed one inch short of the actual moat, and it's hiding in your own best line: "a defensible claim is one where the mechanism has no way to skip the work." You're treating that as a description of one claim. It's a positioning discipline, and the discipline is the moat, not the sentence.
Any single claim is copyable, sure. But look at what just happened to you: two claims died because they were marketing intent, features that could ship or not ship without the product noticing. The one that survived was marketing mechanism, something the product physically cannot avoid doing. Your competitors are making the first kind of claim right now, and theirs will rot exactly the way yours did, silently, until someone greps. You've found a rule that only lets you make the second kind. That rule is durable even though its outputs are individually copyable, because it's a process advantage, not a feature.
And in this category specifically it compounds. You said it yourself, most of this space markets a number that requires never looking. If every claim you make is mechanism-guaranteed and every claim they make is intent-that-quietly-rots, "the one whose claims are all still true six months later" becomes the brand. Not one moat, a reputation that's expensive for them to match because matching it means auditing themselves the way you just did, and most won't.
So it's not "defensible but not unique." The claim isn't unique; the discipline that generates only unskippable claims is. Which of your roadmap features can you actually build on an unskippable mechanism, versus which are intent you'd have to promise to enforce?
That question splits my roadmap cleanly enough that it was uncomfortable to write out, so here it is.
Unskippable, because the mechanism cannot avoid producing the evidence:
The employer confirmation, for the reason above. Duplicate protection, which is a unique index on the user plus the normalised posting URL, so the database rejects the second write whether or not anyone remembered to check. Billing, because a charge either exists in the ledger or it does not.
Intent I would have to promise to enforce:
Ghost-job detection. Match ranking. Anything where the output is a score. I killed the first one for exactly this reason. I could not write a test that would fail if it were wrong, which means I had not built a check, I had built a number that goes up.
The line between the two columns turned out to be simpler than I expected, and it is not difficulty. It is who produces the evidence. If the only witness is us, describing our own work, it is intent no matter how much machinery sits behind it. If the evidence comes from something that does not care whether we look good, a database constraint, a payment record, a hiring system replying, it is mechanism.
The part I do not have an answer to: that rule is easy to apply to a feature and hard to apply to a roadmap. Almost everything a customer asks for is a score, because scores are what feel intelligent. So the discipline you are describing is not free. It costs you the features people request most, and it does that quietly, one no at a time, before anyone can see what you got in exchange.
The "does anything in the live path call it" test is the part most people skip, because a module that exists and is documented feels shipped. I did the same thing with a scoring feature: the code was there, the column was there, and it turned out only a nightly job nobody triggered ever populated it.
One addition that saved me later: after grep, write the one-sentence demo of the claim — "here is me, on a fresh account, seeing this happen." If you can't do that live in 60 seconds, the claim goes below the fold no matter what the code says. Killed a lot of ambiguity for me between "implemented" and "reachable by a real user."
And your last point is the actual ROI: one claim you can defend in a thread six months out beats three you have to quietly walk back. The walk-back costs more trust than the extra features ever bought.
The 60-second live demo is a better test than mine and I am stealing it, because grep proves reachability in the code and yours proves reachability by a person, which is the thing anyone reading the claim actually cares about.
Your scoring feature is the same shape as one of ours almost exactly: code present, column present, populated only by a job nobody ran. The part that makes this class of bug so durable is that every artifact you would check tells you the truth. The module is there. The column is there. The docs are accurate. Nothing is lying, and the feature still does not exist for a user.
The one I would add underneath yours: if you cannot demo it in 60 seconds, also check whether anything writes the field the demo would read. We had a gate that could never fail because the column it checked had four readers and zero writers. It passed every test, because a check that reads an always-empty field cannot produce a failure to test against.
So the ladder ends up being: does the code exist, does the live path call it, does anything write what it reads, and can a stranger see it happen in a minute. Only the last one is visible to a customer, which is probably why it is the one worth putting in the copy.