Why I built a self-hosted schema doc tool I never needed

I did not build this to fix my own problem. I do not spend my evenings staring at a Postgres database wishing its schema were better documented. So this is a slightly different story from my other posts, where the pain was real and mine. Here the pain belonged to other people, and I went looking for it on purpose.

The reason I was looking: my rule is that I should not ship a new product until I have a way to put it in front of people. Distribution first. But building and distribution can run in parallel, and I had time, so I started hunting for the next thing to build while the other products sat there doing their slow thing. Four boilerplates listed, almost no views, no sales. Whatever I built next, I wanted it to start from a real gap, not from a feature I thought was cool.

Looking for a crack, not a pain

So I did not start from “what annoys me.” I started from “where is the self-hosted market thin.” I spent a while going category by category. Most of what I looked at was already crowded. Uptime monitoring, password managers, analytics, all of it has mature free open-source options that people trust. Walking into one of those with a paid product makes no sense. You would be the expensive newcomer next to a tool that has had ten years and a thousand contributors.

Database schema documentation was different. There was a visible crack.

On one side, the free option. It works, but it wants Java, a JDBC driver, and a terminal command to produce a static report. The kind of thing where you read the setup instructions twice and still end up on a forum thread from years ago. The output looks like it was designed in an era I do not miss.

On the other side, the modern tools. They look good, the diagrams are clean, the UX is friendly. But they are cloud. To get that nice diagram, you point them at your database, which means your production schema goes to someone else’s server. For a lot of people that is an instant no. Not because the tools are bad, but because “send us your schema” is a hard sell to anyone who cares about where their data lives.

So the gap was specific: people who want a clean, modern schema doc tool but will not send their database to a third party. Self-hosted, runs on your own machine, no account, no cloud.

The part where I recognised the pattern

Here is the honest bit. I did not invent this insight. I already had one product that sold to almost exactly this buyer.

KeyMint, one of my boilerplates, works because of the same profile: self-hosted, pay once, no API key handed to anyone, your keys stay yours. The people who buy that kind of thing are not looking for the cheapest option or the flashiest one. They are looking for the one they can run themselves without trusting anyone. Once I saw the schema documentation gap, it was the same buyer wearing a different hat. I was not discovering a new audience. I was noticing that an audience I had already met had another unsolved problem.

That is the whole “why.” Not a personal itch. A pattern I had already seen pay off once, showing up again in a category with a clear hole in it.

I called it SchemaLens.

Building it in two days

The product idea was small on purpose, which is the only reason two days was realistic. One job: you paste a connection string, it reads the schema, it draws the ER diagram. That part is table stakes. The thing I actually wanted to be the difference was a layer on top of the diagram, notes and tags that persist, so the documentation is something you keep and update rather than a static report you regenerate and lose. Living documentation instead of a snapshot.

I built it with Claude Code, the way I build everything. Two bugs are worth writing down, because they are the kind of thing nobody warns you about and you only learn by hitting them.

The first was deployment. Vercel could not figure out the project and kept failing with “No entrypoint found.” The build was fine locally. The problem was that Vercel had guessed the Root Directory wrong, so it was looking for the app in the wrong folder. Once I pointed it at the right directory the deploy went through. Obvious in hindsight, an hour of confusion in the moment.

The second was nastier because it looked like the app working. In the ER diagram, clicking a table was supposed to open its detail. From the Tables tab it worked. From the diagram it did nothing. The detail view was reading location.state and getting null, because the click in the diagram called navigate() without passing the router state along, while the Tables tab link did pass it. So one path carried the data and the other quietly dropped it. I fixed it by holding the selected table in a module-level cache instead of leaning on router state, so it did not matter which path you arrived from. That is the kind of bug that teaches you something, even if what it teaches is “stop trusting that the two routes behave the same.”

Where it is now

The demo is live at https://schemalens-api-server.vercel.app and the product is up on Gumroad at https://ibrh96.gumroad.com/l/nybxiw. Self-hosted, no cloud, no monthly fee. You run it, your schema stays with you.

I am not going to pretend this one is different from the others just because it is newer. It starts from the same place they all did, which is a real gap, an honest build, and no idea yet whether anyone will pay for it. If they do, I will tell you the real number. If they do not, I will tell you that too. That is the only version of this I know how to write.