Four public tools on this blog. An llms.txt generator. A generative image system. A graph search engine. An interactive card game with GEO concepts. None was planned as a product. All started as something I needed to solve for myself.

The difference between building for others and building for yourself is that when you build for yourself you do not need to justify the existence of what you make. You need it. You build it. If it turns out useful for others, you publish it. If not, it keeps solving your problem.

llms.txt Generator: hypocrisy as engine

I was writing posts about GEO and llms.txt when I realized something uncomfortable: I was talking about a standard I did not know worked. I was recommending it without having implemented it. I was explaining it without understanding its real limitations.

I felt like a hypocrite. So I stopped writing and started building.

The first llms.txt I generated looks nothing like the current one. It was a fight to see how far we could push data in a format that AIs could actually parse. We tried structures. We broke things. We discovered that what the specification said and what models actually read did not always match.

When the file worked on my own blog, the next step was natural: if I had to solve all of this by hand, others will too. That is how the generator was born. An interface where you enter your URL and it generates the file. No registration. No cost. Because the value is not in the tool. It is in not having to go through the same fights I went through.

The tool exists because I refused to talk about something I had not tested. Cogitare Debes applied to my own content.

Generative Identity: stock photos are dead

Every blog needs images. And every blog ends up in the same place: stock photo banks where the same images appear on thousands of sites. A reader who sees a stock photo they already saw on another site thinks "I already know this" even though they have never read your content. The image says "generic" before the text says "original."

I wanted something that felt alive. Something unique per post, fast to load, and that did not depend on manually searching for images for every article.

The solution was to make the content generate its own image. The title is hashed with MD5. The hash fills a 32x32 grid. The content length determines the color. The result is a unique visual pattern for each post. Change one word in the title and the entire pattern changes. Each image weighs between 2 and 8KB in SVG.

It did not start as a generative art project. It started as frustration with stock photos. The generate-image.php function solved my problem. When I put it on GitHub as an interactive demo, I discovered others had the same problem.

Graph Search: search engines are broken

This one is personal. I do not understand search engines. I use them because there is no alternative, but I feel they are badly made. You type a term, you get a list ordered by textual relevance. If the term does not appear literally in a post, that post does not exist for the search engine. Even if it is deeply related.

I do not think that way. I think in connections. A post about JSON-LD is connected to a post about Cloudflare Agent Readiness which is connected to a post about llms.txt. When I search for "JSON-LD", I want to see that chain, not just the posts that contain the word.

The graph search started as the post_connections table that feeds the auto-linker. 80 connections across 52 posts. Those connections existed so a cron script could add internal links every morning at 6AM. They were never intended as visible navigation.

When I connected those relationships with a recursive CTE in MariaDB and put an interface on top, what appeared was a search engine that searches the way I think. It is not complete. But it is closer to how I connect ideas than any traditional search box.

GEO Tarot: I wanted to play with GEO

I had 22 Generative Engine Optimization concepts I needed to explain. Technical definitions. Specific implementations. Supporting data. The obvious format was a list or a long guide. But I did not want to write another long guide nobody finishes reading.

I was thinking about how to explain complex concepts simply when I found that card games are one of the oldest forms of transmitting knowledge in human history. Tarot cards are not just a game. They are a system of archetypes that encodes complex ideas in simple images.

I connected the two things. 22 GEO concepts. 22 major arcana. Each card maps a concept to an archetype. The Hierophant is llms.txt (the guardian of knowledge). The Emperor is the Knowledge Graph (the structure that organizes). The Lovers are Content Negotiation (the relationship between formats).

It is not a productivity tool. It is a way to play with technical concepts. To explore them one at a time instead of reading them all in sequence. It was born because I wanted to make learning GEO fun. First for me. Then for whoever finds it.

The pattern

All four tools follow the same path. A personal problem that frustrates me. A solution built to solve it. A moment where I discover the problem is not just mine. A decision to publish the solution without charging or requiring registration.

None had a business plan. None had a market study. None was validated with users before being built. They were built because I needed them. That others use them is a side effect, not an objective.

I believe the best tools are born this way. Not from "what can I sell?" but from "what do I need that does not exist?" The difference is that the first question requires external validation before building. The second requires only that the problem be real. And if the problem is real for you, it is probably real for someone else.

What is not a tool yet

There are functions on this blog that remain internal. The AI Radar that logs which bots visit the site. The auto-linker that connects posts every morning. The adaptive content system that shows different versions depending on who reads. The WebMCP endpoint that returns the graph in JSON-RPC 2.0.

All are internal functions that solve my problems. Some will become public tools. Which ones and when depends on whether the problem they solve is just mine or someone else's too. I am in no rush to find out.

Tools worth building are not planned. They are discovered. You build for yourself. If it works, you publish it. If not, you learned something. Either way, the problem got solved.