We shipped a working, paying-grade SaaS product — accounts, billing, terms of service, an audit trail, the whole spine — for a specific kind of customer: the engineering expert witness who has to draft a federal Rule 26(a)(2)(B) report. It runs. You can sign in, set up your cumulative record, dump your working notes for a case, and get a structured draft back with its citations checked. Then we looked hard at how that customer would ever find it, decided the paid-search channel was too thin to carry the product, and cut it.
That sounds like a failure. It mostly isn't. The expensive lesson was about demand, and it's the kind of lesson that's only convincing once you've actually built the thing. This is the write-up.
What it does (so the rest makes sense)
The product is called rule26, and its job is narrow on purpose: an independent testifying expert in a federal civil case has to produce a written report under Rule 26(a)(2)(B). rule26 keeps the expert's cumulative record across cases (the CV, the rolling four-year list of prior testimony), takes the notes for a new case, and assembles a structured draft the expert then reviews, edits, and signs. A few design choices mattered more than the feature list:
- The tool drafts; the expert authors. Nothing is presented as the expert's opinion until a human reviews it and confirms. The report has to be the expert's own work, and a report that reads like a machine wrote it is its own cross-examination problem — so the finalize step is a deliberate human gate, not a formality.
- Citations fail safe. A tool that quietly invents or mis-states a citation isn't useless, it's a liability. The citation layer is built to flag, never to silently include: an unverifiable source surfaces as a problem to resolve, not a sentence that slips into a signed document.
- It keeps an audit trail. Who changed what, when it was confirmed. For a document that may be challenged in a deposition, the record of how it was assembled is part of the product.
None of that is glamorous. All of it is the kind of engineering that's the actual job when the output is going into a court file. We're describing it, not recommending a course of action for any particular case — this is a build-log post, not legal advice.
The build worked. The market math didn't.
Here's the part worth the read. The product is real and it does its job. But a product is only half of a business; the other half is a path to the people who need it, at a cost that works. And for this product, the most obvious path — pay to show up when someone searches — turned out not to exist in any usable size.
We tested it. We ran a tightly-scoped paid-search campaign and read the search-terms data directly, which is the only honest way to learn this. Three things came back, and they compounded:
The buyer universe is genuinely small. Triangulating the public directories and the federal caseload statistics, the population of independent testifying experts who draft these reports is in the low tens of thousands — and each of them has the need only a handful of times a year.
The search demand on the topic is almost all the wrong audience. "Rule 26" is a busy query, but the people typing it are overwhelmingly attorneys, paralegals, and law students reading the rule — research intent, not buying intent. (There's a second trap: "citation checker" is a homograph, and the vast majority of those searchers want academic bibliography formatting, not legal cite-checking.) When we isolated the genuinely buyer-intent searches — an expert actually looking for help drafting a report — it was a trickle.
There's no category to capture. This is the decisive one. The expert who needs to draft a report doesn't search for "Rule 26 report drafting software," because that category is new and they already solve the problem another way — their own prior template, or the retaining attorney's format, or a well-known book on the subject. You can't buy your way into demand that the buyer doesn't express as a search.
So we cut paid search. Not because the clicks were expensive — they were actually cheap, because almost nobody with a budget competes for informational rule-text queries — but because there weren't enough of the right clicks to buy at any price. That's a fit problem, not a cost problem. No amount of spend fixes a channel pointed at the wrong population.
Why "cut the channel" isn't "kill the product"
This is the distinction that took us a while to hold cleanly, so it's worth stating plainly: a channel verdict is not a product verdict. Paid search being too thin tells you one specific thing — that this particular path to the buyer doesn't carry. It doesn't tell you the buyer doesn't exist, or that the product doesn't work, or that a different path (a directory listing, an attorney-side referral, organic content that the rare in-market searcher finds) wouldn't reach them.
So the product stays live. It costs effectively nothing to keep running, it does what it claims, and a customer who arrives some other way costs us nothing to serve. What we stopped was pouring acquisition effort into a channel the evidence said couldn't return it. The next question — does any channel reach these experts efficiently — is a separate experiment, and we'd rather answer it deliberately than assume it.
The transferable lesson
If you're building for a narrow professional niche, the order most of us instinctively use is backwards. We build the thing, then go looking for the channel. The cheaper sequence is to ask, before you build: does the buyer express this need as something I can reach — a search, a forum they live in, a directory they already pay for? If the need is real but invisible to your channels — solved quietly with a template and a book, never typed into a search bar — that's a finding you want on day one.
We learned it after shipping, which is more expensive than learning it before. But the build was sound, the record is honest, and it's the kind of lesson you only fully trust once you've paid for it. We'd rather pay once, in public, and write it down — so the next bet starts with the channel question, not the build.