Subscribe

How to spend 15 years perfecting a product

alex@refactoring.guru

Hi!

It's Alex, creator of Refactoring.Guru. A few weeks ago, I emailed you about my new project GitByBit. This is its origin story: how an indie dev with no team, no ad budget, and one aging traffic source tried to build something useful while the dev world was being torn and rearranged all around the globe.

GitByBit

If you've ever wanted to launch something of your own, you may find some useful insights into how to pick an idea and what to consider when you begin, along with a few real numbers. Skip this if you don't like postmortems or cringy humor.

Quick takeaways from this episode: If you want to launch something, start by finding users for your product first. If there's no product yet, pretend that it's already built, then think about what you'd do next. Do THAT immediately instead of writing code. Also, use your unfair advantage. You may have it, but dismiss it as unfair 🥹. Use it before others do!

Quick recap of the last one: Over the last three years, I built a free Git course with a twist: it runs inside your code editor (assuming you use VS Code, Cursor, or one of their clones), so you learn or refresh your Git skills by using it in a real dev environment on your local computer. It's well-designed, illustrated, and perfect as a refresher. Link: GitByBit.com.

GitByBit.com

The hook

In the winter of 2023, I had a blind strong determination to create yet another educational product for developers.

Up until that point, I'd been living the bumpy life of an independent developer and educator, trying to stay afloat while making cool educational materials for developers and surviving never-ending, life-altering events such as a revolution, the birth of a child, a pandemic, and a full-scale war in my country.

Luckily, my recent project Refactoring.Guru was all the rage at that time, and despite many challenges, it felt like, after two decades of trying, I'd finally managed to produce a hit.

But like everything good in life, that sense of stability didn't last long. Make something useful, publish it, wait for people to find it, hope enough of them come back to support your work. Until very recently, this was the go-to strategy for small creators, publishers, and educators. Let's see if it still works.

Choosing the direction for a new product

At the start of 2023, there was only a hint of what was yet to happen. ChatGPT 3.5, a very silly model from today's perspective, but a GENIUS-level AI at the time, made me wonder whether any purely information-based product was pretty much doomed. I'm looking at you, my silly books and websites!

What I didn't expect was that the profession itself was about to be shaken really hard, too: all the layoffs, agentic development, and overall doom and gloom were yet to happen.

If plain explanations were becoming cheap, maybe guided practice with REAL tools still had value. Yes, ChatGPT could explain most stuff, but it was still just a chat: there was no way to run anything in it, and there weren't any illustrations or videos either.

Besides, I'd always wanted to move the learning environment closer to where the actual work is done. Instead of learning on a website or in simulated web editors, I thought it would be cool to have some sort of tutor right in your IDE.

It's funny that we almost have that now with AI chats and agents integrated into IDEs. But further integration somehow stalled halfway. None of the AIs, including native apps like Codex, have access to the IDE's UI, so they can't tutor people within that UI. All you have is a chat interface with access to a limited set of tools such as a terminal, a browser, formatters, etc.

So, I had a rough idea of the desired format: a practice-based course inside a code editor. But which editor? There were two major editor families around: VS Code and JetBrains IDEs (IntelliJ IDEA, PyCharm, and the like).

I decided to start with VS Code, since it was open-source, free, and popular among beginners. It's also based on the JavaScript stack, which I knew well and which would let me get something up and running relatively fast (it was early 2023, remember, so there was no Claude to write code for you in any esoteric language). Luckily, later on, new IVEs (integrated vibe environments) such as Cursor, Windsurf, and then Antigravity were all VS Code forks, so my little thing became compatible with all these editors without much extra effort.

I'd recommend that any developer who has ever wanted to build a tiny REAL product make an IDE extension. It's a safe bet: improve some piece of the workflow for yourself and share it with fellow devs. The chances of making a buck from it are pretty slim, but you can still gain a lot of valuable product experience, see how it all feels, and talk with real users.

The tech was chosen, but what about the topic? My main option was to develop a new version of the Refactoring course, requested by so many people over the years. The current version is web-only, and practicing refactoring right in your IDE would likely be a killer product.

However, by that time, I'd already attempted several unsuccessful redesigns of that course and was burned out on the topic. Besides, it was likely to be huge in scope, and I wanted something smaller to try out this new practice-based educational concept (btw, I'll return to that topic in later parts of this series, so stay tuned if you're interested).

So, of all things in the world, I chose Git. Why, though?

Business considerations

Being a solo indie dev means constantly sweating over such nonsense as:

following market trends: business lingo for making cool stuff;

being aware of the product lifecycle: recognizing when cool stuff becomes uncool;

traffic growth: letting more people know about your work (also known as distracting yourself from developing the product);

and of course monetization: making enough money to avoid starvation.

Coming up with something that would tick all the boxes is tricky, because you often have zero clue about the grand scheme of things. You're just a single person, often without a huge budget or powerful friends. There are tons of ways to test product ideas, yes. But sometimes, by the time you've tested and verified your product idea and shipped 1.0, the market changes again (business lingo for oops, nobody writes code by hand anymore). In the end, you just try to place one decent bet before the table moves again.

Nevertheless, if I've learned anything over the last two decades as an indie dev, it's this: always start with distribution, meaning how you're going to get users for your precious creation. Btw, let me know if you want me to explore this in the next emails.

In this particular case, I decided to copy what worked for me in the past and bet on SEO as a primary channel. Most people who know about any of my work learned about it through search. I know how it works and know how to make a resource that both 1) ranks AND 2) is not a complete dumpster fire from the user's perspective.

So... looks not too shabby? But I had an unfair advantage (business lingo for things like trading stocks while being a son of Trump or using your search engine to promote your web browser).

Proof of work

Anticipating the GitByBit release I launched my first Git tutorial in 2011, a whopping 15 years ago. It's called GitHowTo.com (miraculously, still online), and it was similar in scope to the current GitByBit main course: free and without ads. In those ancient times, there were only a handful of resources about Git, especially ones translated into multiple languages. So the project steadily grew on its own, and at its peak, it had about 50K monthly visitors.

GitHowTo.com

In 2023, that resource still had a steady stream of 30K monthly visitors (mostly from SEO, thanks to being online for so many years), so I naively thought that:

this was a great jump-start for a new Git-related product;

since it had lasted for 12 years, surely it would last a tiny bit longer!

SPOILER ALERT: three years later, that number has fallen to 5K monthly visitors, thanks to Google answering more queries directly with AI overviews while sending fewer people to the resources those answers were built from.

But at that time, the number was high enough to convince me that the market was still there: people were still learning Git (and they still are).

Monetization-wise, that old resource was free, but based on my prior experience, if you provided a cool, non-hostile premium option, enough people would buy it to support past and future development.

The primary math that had worked for ages: if you managed to get 1,000 visitors interested in your resource, you could expect up to 10 of them to be generous enough to buy something from you (often simply as a token of appreciation). This more or less still works, but the effort of getting those 1,000 visitors is becoming increasingly unsustainable.

In any case, my plan was to use that old project as a staging area (get it?) and a bridgehead for creating THE MOST OVERPRODUCED THE BEST GIT COURSE IN THE WORLD.

get it?

Next stop:Making THE BEST GIT COURSE IN THE WORLD

The biggest problem with being an indie developer is that you have to be mentally ill to be successful (my wife is a therapist, so this is an expert-approved opinion).

Split personality: playing several contradictory roles at once: move fast (business guy), but be careful (security expert); build to last (software architect) with tech that will be obsolete in a few years (business guy again); teach technical stuff (accurate and precise dev), but package it with attractive, cool graphics (whimsical artist).

Split personality: playing several contradictory roles at once: move fast (business guy), but be careful (security expert); build to last (software architect) with tech that will be obsolete in a few years (business guy again); teach technical stuff (accurate and precise dev), but package it with attractive, cool graphics (whimsical artist).

Self-delusion: believing in the eventual success despite depressing initial numbers, setbacks, pivots, and questions like "dude, are you still working on that thing?"

Self-delusion: believing in the eventual success despite depressing initial numbers, setbacks, pivots, and questions like "dude, are you still working on that thing?"

Aggrandizing: aiming to produce the best thing in the world with the hope of actually shipping something not too shabby.

Aggrandizing: aiming to produce the best thing in the world with the hope of actually shipping something not too shabby.

Narcissism: constantly yapping to your friends, fans, and total strangers about seemingly the same thing for YEARS in order to validate random ideas, while totally ignoring concerned looks.

Narcissism: constantly yapping to your friends, fans, and total strangers about seemingly the same thing for YEARS in order to validate random ideas, while totally ignoring concerned looks.

Obsession: rewriting content for the third time because your old voice sucks. Redesigning the whole UI because your high standards the project has evolved drastically in 3 years.

Obsession: rewriting content for the third time because your old voice sucks. Redesigning the whole UI because your high standards the project has evolved drastically in 3 years.

Mania: capitalizing on sudden streaks of productivity to accomplish a lot while those eyes still burn.

Mania: capitalizing on sudden streaks of productivity to accomplish a lot while those eyes still burn.

AI-psychosis? A new tool for the job!

AI-psychosis? A new tool for the job!

I'll touch on many of these pains in the next part. I'll show what it actually took to build this thing, how it evolved over time, when the early launches happened, and some more GitByBit numbers. Stay tuned if you're interested.

Wanna chat?

Have you shipped something of your own lately? Vibe-coded or not, if you're proud of it, let me know. I'd love to see!

Also, if you're in a tough spot with your project, let me know too, maybe I can suggest something useful or at least we can cry together.

Oh, almost forgot: if there's a thing or two about Git that you struggle to remember (for example, what's the difference between git reset and git revert?), do let me know! I'm on the lookout for interesting mnemonic ideas and other Git gotchas people encounter.

P.S. If you replied last time but are still waiting for my answer, please check the SPAM folder (I do my best to always reply back). I think there was a misconfiguration in my domain's DNS last week that could have caused this issue, but it's now fixed.

RefactoringGuru