I Just Wanted to Code. Now I'm a CTO.

I never planned to be a CTO. I just wanted to build cool things and solve real world problems.

Today, I lead a small team, manage our infrastructure, make technical decisions, and still write a lot of code every day.

My younger self would have never imagined this path.

How It Started

My first programming job came during my second year of college. I joined as a junior programmer building a school management system using ASP.NET Web Forms. The codebase followed a clean structure with multi-layer architecture, MVC, and solid naming conventions. It was my first exposure to how real software was built, and I loved it.

But I was curious about more. Web Forms felt outdated, and I kept wondering how modern web apps were built. That curiosity led me to discover AngularJS and React. It completely changed how I saw frontend development. I could finally manage UI behavior with JavaScript, and it felt powerful.

After I graduated, I became a full-time frontend developer working with React and TypeScript. Thanks to my C# background, TypeScript felt natural. At that time, React was on fire in the job market, and I was excited to dive in. I dove head first.

Becoming a Leader

In my first few years as a frontend developer, I stayed in my lane. I worked on UI components, dashboards, animations, anything visual.

Then I was given a chance to lead the web development team.

I still wrote code, but now I was reviewing others work, helping set priorities, and thought more about the big picture.

That shift taught me that leadership isn't a promotion. It's a new kind of responsibility. I started paying attention to communication, decision making, and how work flowed through the team. Soon I cared more about systems than single features.

That mindset prepared me for everything that came next.

From Side Projects to Full Ownership

The real turning point came outside my 9‑to‑5 job.

A client wanted to build an online escape room, called RiddleStory. I joined to help ship the first version. Then more feature requests coming, and I ended up shaping the architecture, discussing infrastructure, and even started interviews for new hires.

They eventually asked me to join full time and lead the technical vision. That is when I officially became the CTO. It felt less like a promotion and more like a natural extension of all those late nights spent solving problems end to end.

What Being a CTO Means to Me

People often picture a CTO announcing funding rounds, speaking at conferences, or managing several engineering teams. All those cool stuffs.

At large startups, a CTO focuses on aligning tech with business goals, managing directors, and talking to investors.

At big corporations, a CTO deals with governance, procurement, security audits, and compliance roadmaps.

For me, being a CTO is closer to the code. I set up CI and CD pipelines, review complex pull requests, spin up new services, and answer "What should we build next?" all in the same day.

It is wearing many hats and knowing when to put one down. It is not about being the smartest person in the room, it is about creating space for the right problems to be solved quickly and clearly. It is a lot of context switching, listening, and choosing what matters over what merely looks impressive.

It is a fun, frustrating, mind-boggling, and never-ending journey of thought. And I genuinely enjoy it.

Final Thoughts

I did not become a CTO by climbing a ladder. I became one by chasing curiosity, filling gaps, and saying yes to tasks that scared me a little.

It was not a straight path, and it was never planned. Looking back, patterns stand out:

Solve real problems.
Communicate with clarity.
Care about the outcome, not just the code.
Chase that "How to get to the next level" thing.

If you are a developer wondering what is next, do not wait for permission. Own problems outside your scope, help your team move faster, and think like a builder rather than just a contributor.