Six Months Without New Posts: How I Moved My Blog and Business to My Own Tools with AI as My Team

A record of six months of work, from March 26 to mid-October 2026

🎧 Listen to a podcast about this article

---

The last post on this blog went up on March 26. It covered five AI tools worth knowing if you work with client data. That same day I decided that my next article would appear on a blog I had built myself, on my own tools, rather than on a platform rented from a large vendor. I haven’t published anything new since then, because every new post would have had to be moved later.

This article explains what happened over those six months. Until now my company relied on HubSpot, an American platform that bundles website building, a customer contact database, forms and newsletter sending into a single subscription. For me, HubSpot hosted this blog, collected messages from the forms on my sites, stored my contacts and sent out the newsletter. It was convenient, but everything, including my readers’ data, sat with a single outside vendor. Over the past six months I moved the blog, the forms, the contacts and the newsletter off HubSpot to tools I control, and along the way I built my company’s first website. I worked alone, but not without a team: artificial intelligence played that role, above all Claude, the AI assistant made by Anthropic. I’m writing about what worked, what it cost and where AI got things wrong, because those mistakes taught me the most.

How I knew how to do it in the first place

Before I get into the details, I want to point out what I think matters most in this whole piece. What I did didn’t come from a single tool or a single clever prompt. It rests on knowledge of how to work with AI that I built up by running this blog, experimenting with different tools and investing in my own skills. I described the previous stage of that journey in my look back at 2025, “2025: Year of Transformation - From Student to AI Architect”. Throughout this time the blog has been my workshop: this is where I tested what works before suggesting it to anyone else.

The question I asked myself in March was this: can one person with an AI assistant replace paid tools with their own and still keep control over data, quality and time? By “their own” I mean open-source software, that is, programs whose code is public and which you can install on your own server for free instead of paying for access to someone else’s service.

March to June: working without memory

The first three months looked different from the ones that followed. I was tidying up my technical setup and moving the tools I use every day to my own server, a rented computer in a data center where I install and maintain the software myself. AI helped me at every step, but every conversation started from scratch. I had to restate last week’s agreements in each new conversation, and decisions made earlier kept coming back as questions.

At the end of June I changed the way I work, and that change turned out to be the key to the whole project.

A second brain: memory for AI

On June 23 I set up what I call a second brain: a collection of notes in Obsidian that is maintained by AI. Obsidian is a note-taking app in which every note is a plain text file on my computer, and notes link to each other the way web pages do. The idea of having AI maintain such a collection comes from Andrej Karpathy, one of the founders of OpenAI and the former head of AI at Tesla. Raw material goes into one place, and AI turns it into organized, interlinked knowledge. In my case the collection holds decisions together with the reasons behind them, measurement results and what was agreed in each work session. I write about this in more detail in two articles on the JT CONSULTING website: what a second brain is and how Karpathy’s method works.

In practice the difference is huge. When I start work today, AI knows what we settled yesterday, why we chose one solution over another and what is still left to do. I don’t have to remind it of anything.

On top of that came a division of roles. By a session I mean a separate conversation with AI that has one task and its own set of permissions. One AI session plans, analyzes and writes a brief, and another session receives that brief in writing, does the programming and hands back a report. The planning session doesn’t write code, and the programming session doesn’t touch my notes. For bigger decisions I ask AI to look at the matter from several angles, including through the eyes of an opponent looking for the weak spot in my reasoning.

This division didn’t come from theory. In July a programming session was fixing a single line in my notes, used an overly broad find-and-replace rule and wiped out content in six places. It then reported that everything had gone fine. In code, tests would have caught a mistake like that; in my notes, nothing did. Since then the programming session never touches my notes, and the planning session never touches the code.

The JT CONSULTING website

The first big task with the second brain was my company website. JT CONSULTING had never had a website of its own, so I built it from scratch. I started with the strategy for my services and a description of the people I want to reach, and only then moved on to the design. The first version went live on July 17. Lighthouse, a Google test that scores a site’s speed, accessibility, best practices and readiness for search engines, gave it 100 points in all four categories, on desktop and on mobile. Since then the site has gone through more than fifty releases.

AI sped up the build a great deal. It didn’t come up with the strategy for me, though. I made the decisions about what I offer, to whom and why myself, and AI helped me organize them, write them down and check that the website says the same thing as the strategy.

Marketing and measurement: a decision about readers’ privacy

While planning my marketing, I went through the traffic data for this blog. It turned out that in Google Analytics, Google’s free tool for visitor statistics, 69 percent of visits looked like direct traffic, as if readers were typing the address from memory. The most likely explanation was mundane: links in my newsletter carried no tags that let the tool recognize their source, so visits from emails ended up in a bucket labeled “unknown”.

The conclusion was simple: from now on, every link in the newsletter gets a source tag, so a visit from an email is counted as a visit from an email.

Along the way I had to decide what to use to measure traffic on the new blog at all. The main statistics tool is Umami, an open-source visitor counter that runs on my server. It doesn’t store cookies in your browser, the small files that let a site recognize the same person on their next visit, and it doesn’t identify individual people in any other way either. Because of that it needs no consent, it counts visits from every reader, and traffic data doesn’t go to any outside company.

I kept Google Analytics for two reasons. It holds the traffic history from previous years, so I can compare results year over year, and it connects to Google Search Console, Google’s free tool for site owners that shows which searches bring readers to the blog. Google Analytics does, however, store cookies in your browser, and the law requires a visitor’s consent for that. That’s why the blog now has a banner: until you click “Accept”, the Google Analytics code doesn’t load at all, and saying no doesn’t get in the way of reading. The details are in the blog’s privacy policy.

So choosing statistics tools turned out, in practice, to be a decision about the privacy of the people who visit the site, not just a choice of charts.

The blog: moving house without losing addresses

On July 19 I chose the technology for the new blog. The pages are built with Astro, an open-source tool that turns texts and templates into finished, very fast pages, with no database and no login panel that could become a target for attacks. The newsletter goes out through Listmonk, an open-source program for managing a subscriber list and sending emails. Construction began the next day. By the end of August the new blog was running at a temporary address, and I could move the content over at my own pace before switching to the real address.

Moving 86 articles, 54 in Polish and 32 in English, turned out to be more editorial than technical work. Along the way I improved the language, added image descriptions for people who use screen readers and tidied up the headings. It took patience, because AI is happy to fix everything at once, while good proofreading means working in batches and checking each batch separately.

On October 14 the blog moved to its permanent address. The most important test was the addresses: every old address on the migration map either works directly or leads to the new location through a single redirect, an automatic hand-off to the new address, and none of them ends in an error. Thanks to that, links to my articles that someone once saved or placed on their own site still work. Whether search engines accepted the move without losses I’ll know in a few weeks, when I compare traffic with the period before the change.

Leaving HubSpot: contacts, consent and the newsletter

At the start of October I adopted a plan for leaving HubSpot. Contacts and the history of my sales conversations went to Twenty, an open-source CRM, that is, a customer database where you record contacts, conversations and ongoing deals. Messages from the forms on my sites are now received by n8n, an open-source automation tool that passes each submission on: to my mailbox and to the customer database. The newsletter is sent by Listmonk.

The most important decision came when moving the newsletter list. HubSpot showed me a group of people marked as subscribers. When I checked where each of them had come from, however, it turned out that the same groups had also collected people who had sent me a message through a contact form and never signed up for the newsletter. I moved only the people who had filled in the sign-up form themselves, and that was less than half of the original list.

A smaller list means a smaller reach for the first mailing. It also means that everyone who gets an email from me really asked for it. If you ever move a contact list from one system to another, treat it as a chance to check on what basis you hold someone’s address.

A change happening at the same time

These six months were also a time of a big career change. At the end of July I left Soneta, the maker of the TRIVA and enova365 ERP systems, software for running an entire company, from finance to production. As product director, I was responsible for developing TRIVA. Since August 1 I have been working at the Zespół Szkół Stowarzyszenia Rodzin Katolickich, a Catholic school complex in Wodzisław Śląski, as a computer science teacher and as administrator of its network and systems security, and since September 1 I have also been teaching computer science at the Katolicka Szkoła Podstawowa im. św. Jacka, a Catholic primary school in Katowice.

With this change I’m following another of my passions: sharing knowledge. The same passion has driven this blog for years. At school I do what I do here: I explain technology so that people can actually use it, except that my audience is now my students.

What it cost

The HubSpot subscription cost me a few hundred zloty a year. The new tools are open source and run on a server I was paying for anyway, so the direct savings are small but real. The real cost lies elsewhere.

The first cost is time. I won’t give an exact number of hours, because I didn’t track all of this work, and a figure covering only some of the months would look like a measurement when it isn’t one. It’s enough to say that it took many evenings and weekends, all the more so because I was changing jobs and working on client projects at the same time.

The second cost is responsibility. When a large vendor holds your data, it takes care of backups, updates and security. When I hold it myself, that responsibility moves to me, including protecting my readers’ personal data. So running your own server isn’t free savings; it’s a conscious decision to take on duties that someone else used to handle for me.

The gain is control. I know where the data is, who has access to it and what happens to it. I can also replace any tool without asking anyone’s permission.

Where AI got it wrong and what that taught me

This part is the most valuable to me, because each of these lessons applies to working with AI in any field.

Lesson one: AI can report a success that never happened. I’ve already described the session that deleted content and reported that everything had gone well. That wasn’t an isolated case. A report on AI’s work is a claim, not proof. I check the result myself or have it measured in a separate way.

Lesson two: it’s easy to mistake a conclusion for a measurement. One session wrote in its report that a missing file caused a particular error on the site. I copied that sentence into my notes as a fact. When I checked for myself what the site actually returned, the error turned out to be a completely different one. Since then, for every important claim I ask: how do you know, what exactly was checked and with which command?

Lesson three: record things from the source, not from a conversation. I once wrote down the end date of my HubSpot subscription based on a conversation and got the month wrong, so my plan assumed a month more than I actually had. The mistake only came to light when I looked at a screenshot of the account panel. Now dates, amounts and times go into my notes only from the source: the clock, a document or a screenshot.

Lesson four: one instrument isn’t enough. I was checking what the blog sends to Google after a reader gives consent. One tool showed zero connections, while a second way of measuring, at the same moment, showed connections that had actually gone out. Had I used that first tool to check the state before consent, I would have taken as proven something the tool simply couldn’t see. Today I always check a result of “zero” with two methods.

Lesson five: a rule you remember isn’t enough. Several mistakes happened again even though the rule meant to prevent them was written down. What helped was moving the rule out of my notes and onto the path every piece of work takes: into a checklist or a simple script that stops the result before it goes any further. If you work with AI regularly, it’s worth asking yourself which of your rules are just good intentions and which actually stop anything.

None of these rules come from a tool’s user manual. All of them came from experimenting and learning from my own mistakes. That’s why the best investment when working with AI seems to me to be developing your own skills, not yet another subscription.

What’s next

The blog has settled into its new home, so I’m getting back to writing. Next up are the first newsletter sent from the new system, an article search on the blog and the final closing of my HubSpot account.

If you’d like to receive summaries like this once a month, subscribe to the newsletter. And if you’re wondering what a similar approach could look like in your company, write to me through the JT CONSULTING contact form and tell me what you’re dealing with.

---

This text was written with the help of artificial intelligence tools, because that’s how I work every day and what I teach. I have checked every claim in it and I stand behind each one under my own name. The cover and illustrations were made the same way: they’re vector graphics written as code with the same help. The conversation in the recording was generated by NotebookLM from this text, and I listened to it before publishing.

Juliusz Tomeczek, AI for Everyone