How building side projects helped me as an engineer

I have almost always had a project on the side.

The reasons have changed over time. Sometimes I wanted to learn a new technology. Sometimes I wanted to automate a task that annoyed me. Sometimes I was simply curious whether I could turn an idea into something real.

Buying the domain is still the easiest and most fun part of the craft. Watching it sit unused afterward is less fun :P

At first, I thought of these projects as a place to practice coding. Looking back, the code may be the least interesting part of what they taught me.

Building outside work gave me a small space where I could follow a problem from beginning to end. I had to decide what to build, make it understandable, put it in front of people, and keep it working if they came back. That changed how I thought about engineering. It made the product, the user, and the limits around the code much harder to ignore.

Curiosity was the starting point

My early side projects took many forms. I tried to create a web framework. I built command-line tools to automate small tasks. I experimented with new libraries, browsers, infrastructure, and design because I wanted to understand how digital products came together.

Most of those projects were small, and many of them went nowhere. That was fine. A project did not need users or revenue to be useful. Finishing even a rough version forced me past the comfortable part of learning.

It is easy to follow a tutorial and feel that you understand a tool. It is different to use it for an idea of your own. Suddenly there are decisions the tutorial did not make for you. You have to choose what belongs in the first version, what can wait, how the pieces connect, and what to do when the simple path stops working.

That kind of practice made technology less abstract for me. I could learn a concept, make a bad choice with it, feel the cost, and try again. The lesson stayed with me because it was connected to a problem I had actually faced.

I stopped looking for places to use technology

For a while, learning often started with a tool. I would discover a message queue, a framework, or a database and ask where I could use it. Side projects slowly reversed that order.

When you are responsible for the whole product, every extra piece of technology gives you more work. You have to set it up, understand it, pay for it, watch it, and fix it. A choice that looks interesting in isolation may add very little for the person using the product.

I began to start with a different question: what is painful here?

Only after feeling the problem did I look for the smallest useful solution. Sometimes that solution needed a tool I had wanted to learn. Often it did not. This was an important change in how I saw engineering. Technology became a response to a need rather than the reason for the project.

The change also made my learning more demanding. A solution could be technically clever and still fail because it was slow, confusing, hard to find, or aimed at a problem nobody cared enough about. The whole product became the test.

Colorkuler made scale feel real

In 2017, İmren and I built Colorkuler, a tool that found the main color palette of an Instagram profile. It began as a weekend project and the first version was built in a day.

The idea was simple enough to explain in one sentence. That clarity helped it travel. After launching, people started sharing their palettes and traffic grew much faster than I expected. Within the first fifteen days, Colorkuler had reached 280,000 unique visitors from 180 countries. At its busiest, more than 10,000 people could be using it at the same time.

For a side project built so quickly, that was hard for me to take in. It was also the first time many engineering concerns stopped being theoretical.

Colorkuler depended on collecting and processing information before it could produce a palette. A small delay in that flow was easy to miss when I tested it alone. With thousands of people waiting at once, latency became the product experience. A slow request was no longer a number in a dashboard. It was a person looking at a loading state and deciding whether the tool was worth another few seconds.

I had to understand where the time was going, which work could happen ahead of the request, what could be cached, and how the system should behave when the source or one of our own parts became slow. I was still an inexperienced engineer, so I learned much of this while the problem was happening.

That pressure was uncomfortable, but it made the lessons concrete. I did not need to imagine why a system might need a different design. I could feel the limit of the current one. Scale was no longer about choosing impressive infrastructure. It was about keeping a simple promise to the user while demand changed underneath us.

Colorkuler is still active today. Its underlying technology has changed many times since 2017, but the user need has remained quite stable. That contrast taught me something else: implementations age much faster than good problem definitions. Code can be replaced. The reason a product is useful should be clearer and more durable.

Kome taught me that building is only part of the work

I built Kome in 2023 as a browser extension. It used AI to help people summarize pages, save useful material, and work with what they found online.

By then, I had much more engineering experience. I could build the product, make technical choices, and get it into people’s hands. What I could not do was assume that any of this would create demand.

The first version gained little traction.

That was useful feedback, even if it did not feel good at the time. My first instinct as an engineer was to improve the product by adding or refining features. But more code would not help if people could not quickly understand what Kome did, how it fit into their day, or why they should choose it.

I had to learn about marketing, positioning, and search. I paid attention to the words people used for their problems and to the questions they were already asking. I worked on making the product easier to explain and easier to find. I also looked at which parts people returned to and which parts seemed valuable only from my side of the screen.

This changed the product. It made me more selective about what we built and clearer about who it was for. Over time, Kome reached a point where it was serving more than 200,000 users in a month.

The growth was exciting, but the more useful lesson came from the quiet period before it. A product can work exactly as designed and still not connect with people. Distribution is not a layer you add after the engineering is done. The way a product is described, discovered, and understood shapes what is worth building in the first place.

Kome helped me see marketing as another form of listening. Search behavior showed what people were trying to solve. Their response to a page or message showed whether I understood the problem well enough to explain it. This feedback was less precise than a test result, but it was still information that could improve the product.

The projects changed how I work as an engineer

The effect of these projects on my engineering work was gradual. I did not return to my job with one new skill and become a different engineer overnight. Instead, the questions I asked began to change.

I still cared about whether the code was clear and the system was reliable. I also started asking what failure would mean for the user, whether the solution matched the value of the problem, how much it would cost to maintain, and what evidence would tell us that it was working.

Side projects gave me practice with trade-offs that can be distant from a single engineering task:

• A feature has a development cost, but it also has a support and explanation cost.
• A fast release can be the right choice when it helps you learn, as long as you know which risks you are accepting.
• A system should be able to handle success, but imagined scale should not make the first version impossible to ship.
• Technical quality matters most when it protects the people using the product and the people who will keep changing it.
• Work is not complete when it reaches production. It is complete when it creates the effect you built it for.

At Pera Wallet, I had the chance to apply this way of thinking by leading and building open source SDKs, including Pera Wallet Connect. It created a feedback loop that felt familiar from side projects. Hundreds of engineers started using what we had built, and we could quickly see where it helped, where it was confusing, and what it needed next. Watching it become part of other teams’ work was delightful. It made developer experience feel concrete: the API, documentation, examples, and release process were all part of the product.

These ideas were not new to software engineering. Side projects gave me a direct way to experience them. There was no separate product team to define the value, design team to make the flow clear, marketing team to find an audience, or operations team to notice a growing bill. Even when I asked other people for help, the gaps still came back to me.

That made me a more confident engineer, but not because I learned to do every discipline well. It made me more aware of how much good product work depends on those disciplines working together. I became better at noticing the questions outside my own area and involving people who could answer them.

Side projects are not a requirement

I am careful about presenting side projects as something every engineer should do.

People have different responsibilities, interests, and amounts of free time. Good engineers can grow through their work, open source, study, teaching, community work, or many other paths. Nobody should need a second shift of unpaid work to prove that they care about their career.

Side projects also have limits as a learning environment. They give you freedom and broad ownership, but they do not recreate the work of a mature team. You can make a decision alone much faster than a group can build shared context around it. You can rewrite your own product without coordinating several teams. You do not face every security, access, legal, or organizational concern that appears in a larger company.

My professional work taught me how to build with other people, work within shared systems, and make decisions where the cost reaches far beyond me. My side projects taught me what happens when no part of the product is outside my view. I needed both kinds of experience.

What made side projects valuable for me was not the extra number of hours I spent coding. It was the freedom to follow my curiosity across the boundaries of a role.

I still build to keep asking better questions

Today I work as an engineering manager, but side projects remain one of the ways I stay close to the craft.

They let me try a new tool without making a team’s delivery depend on the experiment. They remind me how much uncertainty exists between an idea and a useful product. They also keep me humble. Even with more experience, I can still build the wrong thing, misunderstand a user, or make a simple system more complex than it needs to be.

I do not expect every project to grow like Colorkuler or Kome. Most will not, and that is not how I decide whether they were worth building. A small tool that removes one repeated frustration can teach me something. So can an unfinished idea that shows me my first assumption was wrong.

When I look across all the things I have built, the main benefit is not a list of technologies. It is a way of thinking that starts closer to the problem and keeps the whole product in view.

Side projects helped me become more comfortable with incomplete information, more thoughtful about trade-offs, and more interested in the effect of engineering after the code is written. They gave my curiosity somewhere practical to go.

I am still building because I am still curious about what happens next.