About

My path into software wasn’t conventional.

Before working in technology, I spent fifteen years in prison operations in Croatia. It was a high-pressure environment where communication, responsibility and dealing directly with conflict were part of everyday work.

During that time, I retrained in IT. I also initiated a multi-department information-system prototype that was later incorporated into the prison system’s final platform. Eventually, I decided to change careers completely.

I started a small software business, building custom applications and a lightweight accounting and POS product for local businesses. Then, in 2014, I joined Repsly as a software developer.

When I joined Repsly, the technical problems were very different from the ones we face today.

Over time, my work moved from writing product code into platform reliability, architecture, development throughput, team dependencies, infrastructure, security and enterprise readiness.

One of the longest-running parts of that work was the evolution of the original monolithic platform. As both usage and the engineering organization grew, the monolith became a constraint on reliability and parallel development.

We didn’t replace it with a separate rewrite. We gradually evolved it toward an event-driven domain architecture while continuing to build the product.

Production incidents fell from roughly weekly to every two or three months during the first two years of that work. Over time, we reduced them further to roughly one per year, while peak load grew from around 5,000 to 25,000 requests per minute.

At different points, other problems meant changing how we deployed software, introducing infrastructure as code and automated environments, changing team boundaries, bringing non-functional requirements into roadmap planning, or dealing with security and infrastructure economics as the business matured.

The technology changed many times. The question behind most of it didn’t: what’s likely to become a constraint next, and do we need to do something about it yet?

I spend a lot of time thinking about problems we don’t need to solve yet.

The difficult part is knowing the difference between seeing a problem early and solving it too early. If I think something will eventually become a constraint, I want us to understand the risk and have some idea of the direction we’ll need to take. That doesn’t mean we should start building it.

The same applies to architecture. I don’t see it as something separate from product, engineering or organization. You can make a perfectly good technical decision at completely the wrong time.

Today I spend most of my time on long-term technology direction, architecture and engineering systems across teams. I still build things myself when that’s the quickest way to figure something out, prove that an approach works, or leave behind something other people can use.

AI has become a large part of what I’m working on.

I started experimenting with AI-assisted coding in late 2023, mostly because I wanted to understand what the technology could actually do rather than what the demos suggested it could do. By early 2025, I was increasingly interested in whether coding agents could change the development process itself, particularly on a large, mature codebase.

That eventually led to our AI Territory Planner. It became both a commercial AI product and an experiment in building production software through coding agents.

I stayed hands-on during the early stages, moving between architecture, development and product as we figured things out. What we learned there eventually became the basis for an agentic development process that is now being used more broadly across engineering.

I’m now spending a lot of time on what this changes beyond coding itself: how we plan work, how we give agents enough context about existing systems, how we verify what they build, and eventually what all of this means for the way engineering teams work.

I don’t think we know the full answer yet. That’s what makes it interesting.