Finding Use Cases and Working Them Off
A capability nobody can see is a capability nobody believes.
I maintain a catalog of more than 500 data sources. Together they expose over 2,000 tools an AI agent can call. For months I could describe that catalog in one sentence. I could not point a single person at it. This post is about closing that gap, and the method that worked was not “ship everything.” It was find one use case and work it off until it was real enough to show.
A list of 500 things explains nothing
A catalog is an index. An index is not a demonstration. When someone asks what the thing does, “it has 500 data sources” is a number without a picture. The blunt internal note at the time said it best: we need something online, or we cannot explain it. That sentence set the direction for everything after.
A bigger catalog would not have helped. A larger index is still an index. The missing piece was something a stranger could open, click, and understand in under a minute.
Pick one slice instead of boiling the ocean
The catalog spans science APIs, geodata, crypto data, and plenty more. The instinct is to represent all of it at once, fairly, in a single view. That instinct is the trap. A fair sample of everything demonstrates nothing.
So I picked one slice: open data from a single city, Berlin. Civic data reaches a broader audience than crypto tooling. It is concrete. It carries weight an API list never will. Berlin’s open data covers protected trees, memorials, war graves, and the records of its district councils. You can point at any one of those and a person nods.
The metaphor that made it click: a shopping cart for tools
The product is a shopping cart, but for capabilities. You browse data sources. You pick the tools you actually need. Your selection becomes an agent’s toolset, which you export and hand to your agent. Nothing is for sale, because the data is open. The cart is the demo: selection in, agent out.
That framing did more than explain the product. It told me what the one slice had to contain. Enough real sources that a visitor could assemble a believable toolset and feel the point land.
The same use case, worked three times
I worked the Berlin slice three times, each pass at a different altitude.
First pass: make it real and testable. About nineteen Berlin sources were still unfinished. Each had to clear a deterministic test to count: a live request returning HTTP 200 with real, non-empty data, at least two working checks per tool. No test, no source. Seven went green, one needed an API key I could get, one was blocked by its own terms of service, which I recorded as a fact rather than a maybe. Then a generator pulled the source names, tool counts, and test status straight from the real schemas, replacing hand-maintained demo data that had drifted into six small inaccuracies: invented tool names, a wrong count. The rebuild erased them and kept the drift from returning.
Take one source concretely. Berlin’s police-assemblies feed lists every registered demonstration in the city and refreshes daily. That is a single tool with an obvious civic use. Multiply it by a few dozen and the abstract catalog becomes something you can hold.
Second pass: polish it by using it. I clicked through the built page and wrote down every rough edge. Thirteen concrete items came out of one session, found by using the thing, not imagined at a whiteboard. One rule ran through most of them: every list row stays on a single line and truncates instead of wrapping. Applied everywhere, it stops the page feeling noisy.
Third pass: make it honest enough to show a stranger. The last pass readied the page for real conversations with Berlin’s open-data office and civic-tech groups. That meant filling the genuine gaps, showing each source’s origin and license without overclaiming, and framing the whole thing as what it is: a demo. Finished-but-unreleased buttons got a coming-soon overlay rather than being hidden or faked. The image I kept returning to was an open house with the register unstaffed: walk in and look, but you cannot check out yet.
The numbers moved as the slice filled out. At one build I measured, the page carried 31 data sources and 183 tools; the full site build produced 196 pages at that point. A later round of live checks passed 30 of 30 across both language versions, with zero page errors.
The method, not the city, is the point
None of this is specific to Berlin, or to my catalog. The pattern is the takeaway. When you sit on a capability nobody can see, do not migrate everything and do not build more index. Choose one concrete slice a real person would find useful. Then refuse to stop at “built.” The three passes above are how you get from a working thing to a showable one.
The reason the slice beats the whole is uncomfortable but simple. Completeness is invisible. A stranger cannot see that you covered every case. They can only see the one they opened. So the one they open has to be real, used, and honest before the rest is worth a line of code.
Where to start
If you are holding a capability nobody can see, here is the cheapest first move. Pick the smallest slice a real person would find useful. Get every piece of it to a green, honest test before you dress it up. Then put it in front of someone who does not already believe you, and watch where they get lost. One tangible slice beats a complete catalog nobody can open.