Every Time I Get Stuck, There’s a New Tool
Why does a tool only start to feel truly useful after I lose something?
Why does a tool only start to feel truly useful after I lose something?
I removed a feature from the website, then realized I had no idea how to bring it back.
I just wanted to return things to the way they were before, but it turned out I didn’t know how.
Looking back, that moment wasn’t really just about a missing feature. It made me look again at how this website had been built, and at how I had actually been learning throughout the process.
At the time, I had been spending quite a lot of time learning about AI and experimenting with different models. Somewhere along the way, I started to believe that maybe I could build a portfolio website simply by having conversations with AI.
So I started with a simple prompt.
There was no planning. I didn’t know which framework I should use, what a good project structure looked like, or even fully understand what I was actually building.
I just asked for code.
The result was two files, one HTML file and one CSS file.
Then I stopped.
I didn’t know what I was supposed to do with those two files. I didn’t know how to change the content on the website either.
That was when I started reading.
I didn’t understand much at the time. But at least I discovered VSCode. For the first time, I had a place where I could open, read, and modify code that had previously felt like something AI simply handed to me.
After that, I started looking into frameworks. Based on several recommendations, I found React and Tailwind CSS, which seemed suitable for a simple portfolio website.
So I rebuilt everything from scratch.
This time, I asked for much more detailed explanations. The result was no longer just two files, but an entire folder filled with many of them. That was also when I started becoming familiar with the terminal and localhost.
Visually, the result was already getting close to what I had imagined.
But then another problem appeared.
The content.
Every time I wanted to change a piece of text, I had to go into the code. At the time, I didn’t know that this approach had a name: hardcoding. I also didn’t know that it could become difficult to manage as a project grew.
I only knew one thing: I was tired of opening the code just to change a single word.
That need led me to JSON.
Finally, the content and the code could be separated. I started collecting the data I wanted to display, organizing it into a cleaner structure, and making the website read from that data.
For a while, the problem was solved.
Until I had the next problem.
I wanted to display more data in two languages at the same time. The structure I had created was starting to feel uncomfortable. I still hadn’t found an approach that felt right to me, so I just kept going.
Not long after that, I got stuck again.
This time, I wanted to add a new page.
As far as I understood at the time, the approach I was using didn’t make that particularly easy.
Then I found Next.js.
Suddenly, creating a new page was no longer something I had to think too hard about.
Somewhere in the middle of that process, I also found Vercel.
It was free, connected directly to the project, and the website that had only existed on localhost could finally be seen by other people.
At the time, I didn’t think much about the address Vercel gave me. Until eventually, I realized it was too long and didn’t feel like the kind of portfolio address I wanted to use.
So I started looking for a domain.
I found the .work extension, and it happened to cost only a few tens of thousands of rupiah for three years.
That was where this website’s address came from.
Eventually, something happened that brought me back to GitHub.
I deleted a feature.
Then I changed my mind.
I wanted to bring it back, but I didn’t know how.
The funny thing was, the tool I needed had actually been in my hands for quite some time.
I created my GitHub account on January 22, 2026. The first repository I uploaded wasn’t this website, but the Padjajaran Ginger Candy Website, a client project.
Not long after that, I also created a repository for this website.
Twice.
Both of them are archived now.
The problem wasn’t that those repositories were broken. The real problem was that I didn’t understand GitHub yet.
I treated it like storage.
I put a folder there, and that was it.
I knew GitHub was a place to store code. I knew a little about how to use it. But I didn’t understand the much more important part: that every change I made could be recorded, compared with previous versions, traced back, and restored.
I only understood all of that after I lost something.
That incident eventually made me go back and learn Git and GitHub from the beginning.
Once I started to understand, I didn’t continue with the old repository. I archived it and started a new one on May 7, 2026.
Not because the previous code had a problem.
I just felt that the way I worked had changed, and I wanted the new record to begin from the point where I started to truly understand what I was doing.
Since then, the workflow has become simple.
I write code in VSCode.
I push the changes to GitHub.
Vercel automatically updates the website.
I never planned that workflow from the beginning. Everything appeared little by little because there was always another problem that needed to be solved.
But after experiencing it, it became difficult to imagine working without that flow.
When I look back at everything, the pattern is actually quite consistent.
I never chose a tool first and then looked for a problem it could solve.
It was always the other way around.
VSCode came because I was confused about where I was supposed to open and edit the files.
JSON came because I was tired of changing code just to update content.
Next.js came because I didn’t know how to add new pages.
Vercel came because I wanted other people to be able to see my website.
And GitHub had actually been there from the beginning, but I only truly understood it after losing something I wanted to bring back.
For a while, I thought this way of learning was inefficient.
I’ve rebuilt this website from scratch several times. A lot of work eventually went unused. Some projects were abandoned and restarted using completely different approaches.
From the outside, it might look like wasted time.
But I’m starting to doubt that there is a much more efficient way to learn on your own.
If someone had given me a complete list of every tool I would eventually use from the beginning, VSCode, Git, GitHub, React, Next.js, JSON, Vercel, and everything else—I might have been able to memorize their names and functions.
But that doesn’t mean I would have known when to use them.
The two GitHub repositories that are now archived are probably the simplest proof of that.
I already had access to GitHub.
But I didn’t truly understand what it was useful for.
It turns out that discovering a tool and understanding a tool are two different things.
And the distance between them is sometimes not just a few hours or a few days.
It can take months.
This website itself still isn’t finished.
There were times when I left it untouched for quite a while. Then I came back to it again. Even now, I’m still improving it, often just one small part at a time.
And maybe that’s how this website will continue to grow.
Not because I knew everything I needed from the beginning.
But because every time I get stuck, I find something that helps me move forward again.
What I Learned
- Discovering a tool and truly understanding a tool are two different things. The distance between them can be surprisingly long.
- A tool starts to feel truly useful when I experience the problem it can solve for myself.
- Starting over from scratch doesn’t always mean failure. Sometimes, it simply means the way I work has changed.