About

I'm a Technical Lead and Systems Engineer, but my career has never followed a single narrow technical track. I started in software, gradually moved closer to hardware, and found that the problems I enjoy most tend to sit between disciplines - where software, electronics, data, AI, physical systems, science, and people all matter.

Where it started

My interest in engineering began long before I knew what an engineer actually did.

Andrii Voropai at age nine, seated at a table in front of a desktop computer.
At a desktop computer in 2002, age nine.

As a kid, I had a strong tendency to take electronic toys apart - with a somewhat less reliable record of putting them back together. I wanted to know how things worked: what was inside a capacitor, how a transistor behaved, why components had voltage limits, and what happened when those limits were exceeded.

Computers fascinated me just as much. I was curious not only about what I could do with them, but how they were built, what was happening inside the case, and how software could make physical hardware do useful things. Using a computer was interesting; understanding one was even more interesting.

That curiosity gradually connected the two worlds for me: electronics on one side, software on the other. I wanted to understand how a button press became an electrical signal, how a processor interpreted instructions, how information was stored and displayed, and how all of those layers worked together.

A lot of that curiosity turned into experiments of my own - sometimes useful, sometimes destructive, but almost always educational.

Popular science was another major influence. I grew up watching Discovery Channel and National Geographic, especially when science, engineering, nature, exploration, and documentary programming were a major part of those channels.

They made science feel less like a collection of school subjects and more like a way of understanding the world.

By 2006, that curiosity had reached mobile Java games, where I started modifying what I could and trying to understand how small applications worked. In 2009, I began learning JavaScript on my own, which became my first programming language in the more formal sense.

Dnipro and DNU

I grew up in Dnipro, Ukraine, a city with a long history of heavy industry, engineering, electronics, and large technical systems.

In 2011, I began studying at Oles Honchar Dnipro National University, at the Faculty of Physics, Electronics and Computer Systems.

It was almost exactly the combination I had been looking for.

I didn't want to choose between computers and electronics, or between programming and understanding the physical systems underneath them. I wanted to understand the whole chain - from physics and electronic components to signals, computer systems, and software.

What made DNU especially important to me was the people. I was fortunate to learn from professors, researchers, engineers, and laboratory staff with remarkable practical experience in advanced engineering projects and scientific research. They brought knowledge that went far beyond textbooks: real instrumentation, experimental systems, electronics, measurements, and years of hands-on problem solving.

They helped me turn childhood fascination into practical engineering skills.

DNU gave me a structured foundation in physics, electronics, computer systems, signal processing, mathematics, and experimental work. More importantly, it reinforced an approach that has stayed with me ever since: understand the underlying process, study what is already known, build an experiment, measure what happens, and then decide how to engineer the solution.

I later completed my master’s degree at DNU and continued into further academic research before my career pulled me more strongly toward engineering, product development, and building real systems.

Building across layers

Over the years, I've worked on production mobile SDKs, wearable biomedical devices, embedded Android and Linux systems, computer-vision robotics, signal processing, experimental audio hardware, and physical prototypes.

Depending on the project, that has meant working with:

  • AI-assisted software systems, LLM integration, and local AI infrastructure
  • software architecture and cross-platform mobile systems
  • accessibility testing, automation, and engineering workflow integration
  • Android, iOS, embedded Linux, and low-level platform integration
  • computer vision, image segmentation, and machine-learning models
  • data engineering, signal processing, experimentation, and analysis
  • biomedical sensing, including ECG and HRV
  • microcontrollers, firmware, sensors, and communication protocols
  • schematics, PCB prototyping, board bring-up, and electronics debugging
  • CAD, 3D printing, mechanical prototyping, and physical assembly

I don't see these as separate worlds. They are different layers of the same system.

A sensor produces a signal. Data processing makes it useful. An algorithm or model interprets it. Software makes decisions. Firmware talks to hardware. Electronics and mechanics determine what is physically possible. Measurement tells you whether the whole thing actually works.

The interesting part is connecting those layers.

AI as part of engineering

AI is now part of both the systems I build and the way I engineer.

Professionally, I've worked with LLM-assisted capabilities in production accessibility software. My broader experience includes computer vision, image segmentation, audio models, machine-learning data workflows, and experimentation with self-hosted AI systems.

Outside production work, I spend a lot of time exploring local models, GPU hardware, agentic tooling, automation, and the infrastructure needed to run those systems reliably.

AI is also part of my everyday engineering workflow: research, architecture, implementation, debugging, testing, documentation, and quickly exploring unfamiliar technical territory.

I see it as an engineering multiplier, not a replacement for engineering judgment. It can shorten the path from a question to an experiment, but measurements, evidence, tests, and physical reality still get the final vote.

Research, prototypes, and products

Some engineering problems begin with a specification.

Others begin with a question.

The second kind has taken me into biomedical sensing, ECG and HRV processing, active electrodes, wearable systems, computer vision, robotics, embedded audio, and signal processing.

I have a stutter that can be severe at times. That lived experience has informed some of my research and experiments in speech, auditory stimulation, and altered auditory feedback, including work collected in the lab.

I’ve also contributed to peer-reviewed research. My publications and related work are collected on the research page.

What I value most about research is the method behind it: understand what is already known, define the question, design an experiment, measure the result, and be willing to discover that the original assumption was wrong.

I like prototypes, but the more interesting question is what happens after the first prototype works.

Can it be measured? Can it be made reliable? Can someone else use it? Can it survive outside the lab? Can the architecture evolve? Can the hardware actually be built repeatedly?

That is why I tend to think about research, architecture, implementation, testing, hardware, and productization as one continuous process.

My approach is pragmatic: reuse proven components where they are good enough, build the missing pieces where they are not, instrument the system, measure the result, and iterate.

Sometimes the right solution is custom engineering.

Sometimes it is an open-source project, an existing device, or a €20 component that already solves 90% of the problem.

Knowing the difference is part of engineering.

Ukraine → Poland → Portugal

After leaving Ukraine, I spent several years living and working in Poland before moving to Portugal. I’m now based here and work remotely with international teams.

That path has made distributed collaboration, asynchronous communication, independent research, and cross-disciplinary technical ownership a natural part of how I work.

Today, I'm based in Portugal, work remote-first, and am available for international travel.

Why this website exists

This website is not meant to be a static résumé.

It is my digital cave wall - a growing record of projects, experiments, research, prototypes, measurements, technical decisions, failures, and things I learned while building them.

The common thread is simple: I like understanding complicated systems, connecting disciplines that are often treated separately, and turning ideas into things that actually work.

You can explore the projects, ongoing experiments in the lab, publications in research, or the full experience timeline.

I’m open to interesting remote engineering, technical leadership, research, open-source, and deep-tech collaboration. If something here overlaps with a problem you’re working on, get in touch.

Education

Oles Honchar Dnipro National University (Ukraine)

  • PhD studies in Physics, Electronics and Computer Systems (2018–2022; degree not completed). Research conducted during the program covered biomedical sensing, EEG/ECG analysis, signal processing, and deep learning, and contributed to three peer-reviewed publications.
  • MSc in Physics, Electronics and Computer Systems (2015–2017), with honors
  • BSc in Physics, Electronics and Computer Systems (2011–2015), with honors

Profiles