I've been building things since before it was a career.

I started coding as a kid. C++ first — I don't even remember where I found the books, but I remember the feeling of making something work. Then Visual Basic. Then whatever came next. It was never about a career plan; I just liked building things and kept going.

By the time I got to university — Industrial Engineering at Gazi, then Geological Engineering at METU — I was already running a small agency alongside my studies. Real clients, real projects: websites, systems, whatever they needed. That wasn't a side hustle; it was the actual work. The degree was the background track.

That agency became eight years of building across every domain that would have me. E-commerce, newspaper systems, school management software, games. Whatever anyone needed, I figured it out. Those years gave me something no single company could: the ability to walk into any problem domain and get useful fast. I didn't know it at the time, but range was the thing I was actually building.

The turn toward leadership

Around 2016, I started leading teams for the first time — first at Decision Mapper, working on Cortex, an audit automation platform built with Deloitte. It's still in production. Then Applied Blockchain, where I ran four client projects in six months. Then Solve.Care, a blockchain-based healthcare platform, where I built the engineering team and led the first production release.

These weren't leadership roles I planned for. I ended up in them because I was the person who could see both what needed to be built and how to get a team to build it. That combination turned out to be rarer than I expected.

What I learned in those years: the code is never the hard part. The hard part is the team design, the communication overhead, the decisions nobody writes down, and the debt that accumulates when you optimize for speed over clarity. Fixing those things is slower and less visible than shipping features. It's also the work that determines whether the team is still functioning in two years.

Three years as CTO

One% was a volunteering management platform for enterprise clients. I came in as a consultant to build the MVP, and after we found traction, joined full-time to scale the product and the organization. Three years, a small team, and a lot of decisions that turned out to matter more than I realized at the time.

Running concurrently through those years was advisory work — fractional co-founder and technical advisor to early-stage startups across fintech, healthtech, and SaaS. Sometimes the first technical hire. Sometimes the design partner who helped founders figure out what to build before hiring anyone. Sometimes the person who put together the first engineering foundation — hiring criteria, architecture decisions, conventions — and handed it off. It was a different kind of leverage: a few months of the right input at the right moment, instead of years inside one company.

Being CTO of an early-stage company teaches you something no senior engineering role can: how to be the only technical voice in a room full of opinions. How to make architectural decisions when you don't have enough information yet. How to build a team when the company isn't big enough to be attractive to top candidates. And how to know when the process you built six months ago is now the thing slowing everyone down.

I came out of that chapter believing that engineering leadership is mostly an organizational design problem. Engineers don't fail because they can't write code. They fail because the structure around them doesn't let them do their best work.

What I'm doing now

I've been Director of R&D at Rainforest Automation since late 2022. The mandate was to rebuild a legacy energy management platform — without stopping shipping. We built a cloud-native system on Kubernetes that handles high-frequency IoT telemetry from thousands of smart meters. We got to SOC2 Type II without adding headcount. We shipped demand response, EV charging management, and energy disaggregation products with a small team.

The disaggregation work led to a U.S. patent application — a distributed pipeline built on Ray, capable of processing millions of smart meters at scale. I'm the primary inventor. That one surprised me; I've been building things for twenty years and it's the first time the work crossed into something protectable.

The other thing that's shifted in the last few years is how I think about building teams. We've moved to AI-native development practices — agentic workflows embedded into how we do architecture, code review, testing, and documentation. A small team shipping multiple concurrent products without scaling headcount. I write about this on the blog because I think most teams are still treating AI as a productivity tool and missing what it can do to the structure of how engineering actually works.

What I actually believe

The best systems are the ones that stay maintainable under load — not just technical load, but organizational load. What happens when half the team turns over? When a new product requirement breaks your core abstraction? When you need to onboard three engineers in a month? Architecture that only works when everything is fine isn't architecture.

I think most engineering problems are actually organization problems in disguise. The slow team is usually a team with unclear ownership, not a team of slow people. The bad codebase is usually the output of a process that rewarded shipping over clarity for too long. Fix the structure and the output follows.

I also still build things. I think that matters. The patent, this site, a couple of side projects — I want to stay close enough to the work that I know what I'm asking people to do when I ask them to do it.