Breaking free with my own tools

I live in China. For years, my tasks were in Google Tasks and my notes in Notion. Here, I can only reach both through a VPN. It worked, but it was slow, and without a connection, I had nothing.

Today, I keep my tasks, my notes and my secrets in a tool I built for myself. And this blog is no longer on Hashnode: it runs on a site I built too. Here is why, what made it possible, and what it costs.

Two moves

From Google Tasks, Notion and Obsidian to my own tool

First, I tried to move my tasks and my notes to Obsidian, which keeps everything in local files.

But I did not find the features I was used to, mostly two things: a kanban board, and a way to capture my emails as tasks or notes. To get there, you have to add a lot of community plugins. They are more or less maintained, and Obsidian itself keeps changing under them.

The graph view never really helped me. Maybe there are not enough links between my notes. I tend to organize things in a hierarchy: I used the PARA method, then a hybrid of ACE (Atlas, Calendar, Effort) and PARA. I am still not sure about that choice.

Then came the real problem: replication. I used Syncthing to keep Obsidian in sync with my phone. One day, Syncthing hit a conflict on the file of my kanban plugin, and my kanban was gone. All my tasks, with no real backup. I rebuilt some of it from memory and by digging here and there, but I lost at least half of it. To be honest, a good part of it was things that had been lying around for too long, so I restarted from a clean slate. But I had lost my trust in Obsidian and Syncthing.

So I built my own tool. It has a kanban board for my tasks, with recurring tasks, and documents like in Obsidian, with a WYSIWYG Markdown editor. It works locally and offline. It also keeps my secrets and passwords, encrypted with standard building blocks, not with my own cryptography. Everything I consider my most private data now lives in software that I control.

There is a second user: my wife. Getting her to use Google Tasks or Notion was impossible. Google Tasks does not work here without a VPN, and I think Notion needs one too, or is slow at best. On an Android phone without the Google Play Store, Notion is also hard to keep up to date. Obsidian was too technical for her, and on a phone, the experience was far from what I had on my PC. My tool works for her, on her phone, and without a VPN. And since there is no store to update it, the Android app updates itself: it downloads the latest version on its own.

From Hashnode to this site

Leaving Hashnode, I honestly lose very little. At the beginning, I think I benefited a bit from their network. But quickly, I was not mainstream enough for it. Hashnode is very focused on development, and on the most popular topics. When I wrote about LÖVE, a game engine in Lua, or about something other than code, like HNRNPH2, I don't think their platform gave me any visibility. I have a few followers and a few newsletter subscribers, mostly former colleagues, and maybe some people who found me on their own.

What I gain is control. I can raise the quality of my articles and their visuals, embed what I want, like YouTube videos, and go further than their Markdown allowed.

There is another reason, and it is about legitimacy. This site is where I can show my past work properly. And how could I claim to know the web without having my own site?

What made it practical

I had wanted these tools for a long time. What changed is that LLMs made building them practical, in a way it was not before.

This site is an example. My 42 articles were converted from the Hashnode backup. The 70 old Hashnode addresses still lead to the right pages, and a script checks all of them after every deployment. The site deploys from my own machine, without any secret shared with a build service.

What it costs

Building is not free. I have to maintain these tools, keep my data safe, and decide what happens when a dependency breaks. A tool made for one person can fit that person very well; it also has one person responsible for it.

My Syncthing story is also a warning for my own tool. Sync is not a backup: a deletion propagates like any other change. In my tool, though, the relay keeps every change it receives, encrypted, and never deletes any. So the history is there, and I could go back in time. I still have to build the tool that does it, and to keep a copy of the relay somewhere else.

What I still depend on

Breaking free does not mean depending on nobody. It means choosing dependencies I can leave.

• GitHub is only a mirror of my git repositories, to back up my code. Moving it elsewhere takes minutes.
• Cloudflare hosts this site. Any site has to be hosted somewhere. The difference with Hashnode is that I deliver my own files, and I could move them to another host in an afternoon. Even the visit counter runs on my own server.
• The AI vendor is the interesting one. Since early 2026, I have written almost no code by hand. This site is simple and static, so I could still change it by hand if I really had to. Honestly, I don't believe I will: the job has changed. And the vendor itself is replaceable: one day Claude, another day OpenAI, maybe one day an open-source model running locally.

What I keep is the ability to read and check. I like to compare it with assembly. Someone who knows assembly well can learn higher-level languages, read the assembly of compiled code, and even write a routine by hand where it matters. Between the languages I use every day (Python, JavaScript, TypeScript, Go) and what the LLMs produce, I can always dig in and check.

The comparison has a limit, though. A compiler is deterministic: it guarantees that what comes out matches what went in. An LLM guarantees nothing. So checking stays my job. And without tokens, what I would lose is not the ability to change my code, but the capacity: I now own more software than I could maintain by hand.

Tests as the environment

So how much can I trust code I did not write? As long as the tests are well written and passing, I think I can trust it a lot. Well-written tests also push the code towards a certain quality.

Mo (@atmoio) recently put it this way on X:

MMo@atmoio

Does a CEO need to understand his employees' code?

Vibecoding is 2025.

Evolutionary coding is 2026.

Let the code's DNA evolve to find solutions that satisfy environmental pressure (tests).

Genomes are an absolute mess but they work.

HHarminder Virk@AmanVirk1

I have a very strong feeling that these voices that says "Do not look at the code or code doesn't matter" will fade away soon.

There is no freaking way you can build, maintain and operate products where you don't understand or can't reason about your own code.

I like the analogy, because code really is a living organism, like a language can be. It depends on libraries and operating systems that change, and on users whose needs change too.

But evolution gives you what you select for, not what you wanted. Code that only has to pass tests fits the tests, and keeps whatever else it grew along the way. A mess that works is fine until the day I need to read it myself. So my job moves: I write less of the organism, and more of its environment. Who writes the tests matters, and what they leave out matters too. On this site, every check was green the day a style rule I added changed the spacing of the home page. I found it by reading.

If I push the analogy further, the LLM brings the mutations: ask twice, and you get two different answers. The selection is my part, through the tests and my review. It is closer to a breeder than to nature, though. An LLM does not mutate at random: it proposes changes it expects to be good. And I do not select only what survives, I select what I want.

I worked on something close to this in 2012, in a research lab at Kyushu University. We built a model of a human player for the classic Star Trek computer game: rules that decide what the player does, with parameters tuned by evolutionary algorithms (differential evolution and genetic algorithms). The task was so hard that the algorithms could not find parameters that made the player win. What worked was to start from the simplest version of the game, and make it harder as the player won more often. The environment had to evolve with the player. Fourteen years later, I am back to designing environments.

I'm not the only one

Sebastiano Mandalà, my first podcast guest, has posted the same kind of idea for games several times on LinkedIn. In one of them, he writes:

SMSebastiano Mandalà17 Oct 2026 · Public

I wonder if people realize that everything needed to make a complete game engine is already available as open source projects and can be put together in less than one day by AI…

Why use a ready-made engine, when you can build one that fits your game? He is not the only one. Developers are going through a kind of empowerment.

But attackers are getting stronger too. In the Bitcoin world, 2026 has been rough. A flaw in BTCPay Server let attackers take control of merchants' Lightning nodes. After a bug in its Coldcard wallets, Coinkite said it assumes someone used a frontier AI model to review its older, open source firmware. The Boltz team paused its swaps, saying AI-assisted attacks were coming faster than they could patch. None of this is proven, but the reasoning is easy to follow: when the code is public, a good model can scan it for weaknesses faster than ever. And on top of that, people are discussing a "bunker mode" to protect bitcoins from future quantum computers. Security is back at the front of the stage, in open source and everywhere else. We are stronger, and so are the people who attack us, so the risks can be bigger than before. That is where engineering matters most: designing solutions that are simple, private by default and secure by design.

Where the boundary is

I don't know yet where my own boundary between what I build and what I use will settle. For now, what I keep for myself is what I care about most: my private data, and the place where I show my work.