About
I build software by combining product thinking with engineering ownership.
I'm a product-minded software engineer with 7+ years of hands-on development experience. My background includes backend systems, APIs, web applications, payment flows, authentication, integrations, internal tools and production troubleshooting.
Over time I became less interested in simply implementing isolated tasks and more interested in understanding the entire product: what problem it solves, how the system should be structured, and what is required to make it reliable in production.
Today I build my own SaaS products, publish open-source tools and help companies create or stabilize software systems.
I use AI agents to increase delivery speed, but I personally own product decisions, architecture, code review and production quality.
(to be added)
neutral background
natural light
no stock imagery
Professional evolution
How I got to product engineering
Not a career timeline with logos on it. These are the shifts in how I work. Each one changed what I considered my responsibility.
-
Freelance web development
I started as a freelancer building simple websites for clients. That work taught me the skills no framework does: talking to people, hearing the need behind what they ask for, and turning a vague request into something they could use. It is also where I learned frontend for real.
-
APIs, backends and production
From websites I moved into systems: backend services, APIs, payment and authentication flows, integrations and internal tools. This is where I learned what production actually does to a design, and how much of software engineering is diagnosis rather than construction.
-
Owning whole products
I stopped treating a ticket as the definition of the problem. I started asking what the feature was supposed to change for the business, which usually meant the requested solution was not the right one. That shift, from implementing tasks to shaping products, is the one that mattered most.
-
Architecture and production ownership
I took responsibility for what happens after the deploy: system boundaries, failure paths, observability, the on-call reality of a system nobody wanted to maintain. A feature is not finished when the code is written. It is finished when it holds up under real conditions.
-
Building my own
The next step was products of my own, born from problems I hit in my own work. I shipped open-source libraries and self-hosted tools and I'm building SaaS. Publishing them meant owning product definition, positioning, documentation and release management, not only the code. The products page has the full list.
-
Independent builder, AI-assisted
I run an AI-assisted workflow that lets one engineer cover the ground a small team used to. I build my own SaaS products, publish open source, and take on selected work: building products, automating operations and rescuing software that stalled. I work globally.
How I work with AI
AI agents are a development team. I am still the engineer.
The working model as it actually runs, including where it does not help.
I own
Product and architecture
What the system is for, where its boundaries sit, what it will not do, how the data is modelled and how it fails. These decisions are not delegated, because they are the ones that are expensive to reverse.
Agents do
Implementation at volume
Inside a defined boundary, AI agents write code, tests and migrations faster than I can alone. That is a real increase in capacity, and it is the reason a single engineer can now ship a system that used to require several.
I own
Review and production quality
Nothing reaches production without my review. Generated code is confident, fluent and indifferent to whether it is correct, so the review is not a formality, it is where the engineering happens.
AI increases my production capacity. It does not replace engineering ownership.
Roman Golovanov
What I'm looking for
Roles and projects with real ownership
I'm open to Senior Product Engineer, Founding Engineer, Technical Lead and other product-oriented software roles, as well as selected projects where I can take meaningful ownership.
What I'm useful for is the situation where a product needs someone who can understand the problem, decide the architecture and move it to production without a large team around them. What I'm not looking for is a role where the thinking has already been done elsewhere and the job is to type it in.
Links
Where to look next
The code is the most direct answer to most questions about how I work.
Hiring, or have something that needs building?
Tell me what the situation is: a role, a product, a process that runs on manual work, or software that stalled. I'll tell you whether I'm the right person for it.