AI made building software easier. It did not make anyone need your software.
Many developers now spend weeks shipping tools before asking whether anyone has the problem. The result is an internet full of impressive projects with no users.
The numbers nobody publishes
Traffic is slower than many expect, even for small, useful tools. I can show you: yesterday this site had 488 unique visitors, and 11 of them came from a Google search. That ratio is what a launch day looks like. The spike is people you reached yourself; the search tail takes months, and it only comes if the page answers a question someone types at 11pm.
Search itself is changing while we wait. Fewer people click ten blue links. More people ask an AI assistant what to use. Alongside SEO there is now GEO, how language models discover and recommend software, and it is starting to matter as much. This is not theory for me: vahtian.com ships a page written for agents, plain descriptions of what each tool does and does not do, because an honest limitation is the one thing a model can safely repeat.
That changes how I think about software.
Built because I needed it
I build research tools because I use them myself. Every tool starts with a problem I have met in clinical research, systematic reviews, or supervising students. An experienced researcher should get time back. A doctoral student should learn something from the report itself.
My tools are local first, on purpose. No accounts. No new cloud database. No collecting research data because collecting is possible. If a document can stay on your computer, it should.
If Vahtian ever becomes a recognizable brand, it will be because researchers associate it with this design philosophy rather than with any single tool. The tools cover a workflow, from design to citation to audit trail; the philosophy is what holds them together.
Local-first research tools that strengthen scientific judgment without taking ownership of the data.
My heroes are young researchers and their supervisors. The work I most want these tools to do is mentoring: walking someone from the late-night pain of a broken bibliography toward radical creativity and epistemic integrity.
Occasionally my analytics make me laugh. Someone arrives after searching for a software architecture question only another researcher would think to ask. They stay, explore a citation checker or a qualitative analysis tool, and disappear again.
Welcome. I hope the tools you build respect science and privacy as much as the ones I am trying to build.
The simple stack
My own architecture is intentionally simple:
- Git and GitHub for version control;
- Cloudflare Pages for static websites;
- Vercel for browser applications;
- Render for the rare service that needs a backend;
- local processing whenever possible;
- no database unless there is a compelling reason.
Running costs stay low. Complexity stays low. Privacy stays high.
If you have a tool in a drawer
If you are a researcher with a tool in a drawer: buy a domain, write about the problem it solves, publish your real numbers. I intend to follow my own advice all the way to short videos, when I have enough courage. The next posts here will be the practical part, one question per post: five steps to your first tool website, Git for researchers, being found in 2026, and where to run the thing.
The interesting question is no longer how quickly we can build software. It is whether we are building something that deserves to be recommended by another researcher, or by an AI acting on that researcher's behalf.
Heidi