Use Case Library

What it is

Use Case Library takes dense patent records and turns them into searchable pages about practical computer-vision applications. A page starts with a patent title and abstract, then becomes a plain-language explanation of the problem, the AI task, the possible mechanism, implementation steps, benefits, and source citation.

It is not a demo folder. The site is live, the pages are static, and the content comes out of a data-to-publishing pipeline. The codebase is messy in the way a first build usually is, but it works and it's in production.

Why patents entered the picture

I started the project after leaving employment and looking for startup ideas.

Before patents, I was trying to mine ideas from places where people were already launching products, like Hacker News Show, Reddit, and Product Hunt. I wanted to look at a product and work backward. If someone built this, what problem did they think was worth solving? That was useful practice, but not useful enough. Product launches carry too much packaging. The positioning and the landing page language sit on top of whatever the real problem was. Sometimes I could infer it. Often I was just extracting another person's solution in a different form.

I needed rawer material, and patents had a different shape. They were harder to read, but they usually started from a technical problem, even if that problem was buried under legal language. They described mechanisms, and they often sat inside a specific industry. A patent still didn't prove demand, but it gave me something closer to the reason an applied AI product might exist.

The manual loop before patents

The first loop was mostly me reading, extracting, and clustering. I would look at products, write down the problem I thought they solved, group similar patterns, and ask whether any cluster pointed to a market I could understand. It made me think from first principles instead of collecting startup ideas as slogans.

But the loop kept drifting back toward existing product categories, usually another AI wrapper around a known workflow. Those might be good businesses, but the source material didn't expose enough about the underlying pain, and it didn't tell me whether the problem was urgent or just well-packaged. The patent dataset changed the starting point. Instead of asking what a finished product was selling, I could ask what technical problems companies had bothered to describe and protect.

The first bet

The bet was simple. Patents could be a better source of AI use-case signal than launch feeds, and if I could translate them into readable pages, Use Case Library could become a long-tail SEO asset for people exploring applied AI in specific domains.

I wasn't trying to rank for broad queries like AI use cases. I was interested in narrower combinations like computer vision in forestry, depth estimation for food sizing, object detection for industrial inspection, and image segmentation in agriculture. Those searches are smaller, but they are closer to a concrete problem.

So the product became a transformation system. Patent records went in, structured use-case pages came out. LLMs did the language work, but the product question was not about the prompt. It was whether the source, structure, and distribution surface could turn obscure technical records into something useful.

Where the bet came from

I had done this kind of thing before. At Everypixel we grew the audience to around 200,000 users largely through search, so I already knew how long-tail SEO behaves and trusted that patient content could earn distribution over time.

I also did the research before committing. I looked at search demand and low-frequency long-tail queries, and checked that the narrow combinations I cared about, like computer vision in forestry or depth estimation for food sizing, had real volume with low competition. The bet rested on that, not on a hunch.

What was weak in the bet

The weak part was just as simple. A patent is not demand. It doesn't prove that anyone built the solution or made money from it, only that an idea was disclosed in a form someone considered worth protecting. That is useful, but narrow.

SEO was the second weak point. A new site with few links does not become trusted quickly. Google can crawl slowly, index slowly, and test pages slowly. Publishing more pages is not the same thing as earning distribution.

So I had to hold two thoughts at once. Patents were a useful source for mapping possible AI applications, and they were not proof that Use Case Library was a business. That distinction kept the project honest.

What was actually hard

Generation was the part that looked easy from the outside. The hard parts were upstream and downstream.

Upstream meant getting useful patent data at all. The public patent corpus is huge, so I had to learn a new surface area, from BigQuery and Postgres to NAICS and CPC filtering, deduplication, and Supabase as the state layer. Get the selection too broad and the rest of the pipeline turns into expensive garbage. Too narrow and the library misses useful patterns.

The semantic part was hard in a different way. One patent was titled Food material size detection method and cooking equipment. The abstract describes a camera setup that captures multiple images while food is being placed into a cooking device, then uses those images to estimate size. The generated page became Accurate Food Sizing, a case study in depth estimation implementation. It explained why food sizing matters for cooking consistency, mapped the mechanism to depth estimation, and turned the source into sections a non-patent reader could scan.

That example worked, but it also showed the danger. The page read fluently, then the evaluator marked it REVIEW, with 6/10 technical accuracy and 7/10 problem-solution fit. The critique was right. The page blurred depth estimation with full 3D measurement, underplayed calibration and lighting, and made process-control integration sound cleaner than it would be in a real food-production line.

That was the product lesson. Readable wasn't the same as faithful. The pipeline had to stay true to what the patent actually said, limitations and all, because fluent writing was the very thing that could hide weak reasoning.

The current local build has 184 use-case pages and 8 algorithm pages in a 226-file static output. I treated that as a first batch, not a ceiling. The system could produce more, but the harder question was whether the pages would be found and trusted.

The quality problem

Generated content can be structurally complete and still be wrong. That is why I added a separate evaluator. It scores generated pages for technical accuracy and problem-solution fit, then marks them PASS, REVIEW, or REJECT. It wasn't there to make the system look more elaborate. It was there because the food-sizing example exposed the failure mode clearly. A page can sound plausible and still flatten the hard parts.

The evaluator made the pipeline more skeptical. Generation success no longer meant publication success.

The vendor layer

The next question was what a reader could do after finding a use case. An educational page answers one question, which is what this AI application might look like. A buyer, operator, or consultant usually has the next one in mind, which is who could build something like this.

I built a vendor discovery layer for that. It takes a use case, extracts search intent, finds relevant providers, deduplicates domains, filters out non-vendor results, judges relevance with an LLM, and stores ranked matches. That layer is still not fully validated as a product loop, but it changed the direction. Use Case Library did not have to be only an archive. It could point from a technical pattern toward market actors.

That is also the clearest consulting angle in the project. Many clients don't need AI content. They need a way to turn messy domain material into structured research, then connect that research to decisions.

Shipping it

The repo isn't clean, but it shipped, and what made that possible was splitting content generation from presentation. The generation layer writes structured content, object keys, metadata, vendor data, and evaluation fields into Supabase. The presentation layer reads that state and renders static HTML. That split let me regenerate content, adjust templates, and rebuild pages without turning the whole project into one giant script.

The build system added the habits that a notebook never forces. Pages go through pre-build and post-build validation. The checks cover missing content, canonical URLs, JSON integrity, schema output, and discoverability issues. Deployment runs through staging and production on Cloudflare R2, with manifests and rollback paths.

The site itself is intentionally plain. It's static HTML and CSS with almost no client-side work, so there's little for the browser to do once the document loads.

I didn't build a beautiful engineering system on the first try. I built enough of one to ship the product instead of only describing it.

The distribution loop I didn't run

The site has been slowly indexing and getting small organic traffic without much active work from me. That is a signal, but not a conclusion. The stronger distribution loop was designed and then mostly left alone.

The methodology page could become a linkable asset for people who care about how the pages are made. A data export could help researchers or operators reuse the library. Algorithm and industry hubs could support resource-page outreach. Vendor sections could create a natural reason to contact companies mentioned on relevant pages and ask for a link back.

I didn't run that campaign, and that matters, because page generation isn't the bottleneck. Once the pipeline exists, generating more pages is cheap compared with earning trust, links, and indexing. I kept the first public batch around the current scale instead of flooding a new site with thousands of pages no one would find. The next real test is distribution, not more generation.

What this page should show

Use Case Library is a live asset and a proof-of-work project. The thread worth following is the source. I went looking for startup ideas, landed on an odd raw material in patents, and built the pipeline far enough to find out where it broke. The honest result is on the page. Generation works, the quality gate catches the fluent-but-wrong cases, and the distribution question is still open. I kept those weak signals visible instead of dressing the project up as proven.

It also sets my role honestly. This is not senior software engineering, and I am not pretending it is. It is the work of a technical product builder, close enough to the implementation to ship something real and close enough to the product question to know what the artifact does and does not prove.

The reusable part is the shape. Messy domain material on one side, a workflow with state, review, and publishing on the other, and a person deciding what is good enough to go out. Use Case Library is one version of that pattern.

What remains open

The product questions are still open. I don't know yet whether SEO can scale with more pages. I don't know whether deliberate link-building would change the indexing curve. I don't know whether visitors arrive with commercial intent or just curiosity.

The vendor loop is untested too. Vendors might care that they are mentioned on relevant pages. They might link back, or they might ignore it. I have to run the outreach before I can claim anything.

So Use Case Library sits in an honest middle state. It's live, it has a working pipeline, and it has pages in Google, but the validation is unfinished. That is where I want the case to land.