DEV Community: Roman Voinitchi

Don’t Delegate the Joy of Building to AI

Roman Voinitchi — Thu, 28 May 2026 03:16:40 +0000

We live in a time when more and more tasks can be delegated to AI. Code is written faster, solutions appear instantly, and the final result often looks perfectly acceptable to the end user.

It is convenient and fast. But together with that, it is possible to lose an important part of the whole process — the enjoyment of building things. Things like:

finding an elegant solution for a non-trivial problem
designing and applying a clean architecture
releasing a product and receiving the first feedback from users

If you delegate not only routine tasks to AI, but the entire process itself, you may also lose the very reason many of us got into development in the first place — the joy of creating and the process of building.

This article describes only some of the moments that made building my own application genuinely enjoyable.

Elegant solutions in code

Let me give one example from development. The application has a filter by levels. It contains seven different values, and the user can select either one value or several at the same time. All of this needs not only to be processed in code, but also stored in memory. The most obvious solution is to create seven boolean variables, store each one separately, and manually build the final state every time. It works. But it does not look very elegant.

In the end, I implemented it in a much cleaner way: all filter states were combined into a single Int8 variable using a bitmask. This made the state compact and convenient to manage. I also moved the processing itself to a background thread.

On one hand, there is nothing fundamentally new here. Bitmasks have long been described in algorithm and data structure materials, and thread management is well explained in documentation. But combining solutions like this and seeing the final result brings a very specific kind of satisfaction. And there are many such moments during the development of an application.

This is one of the reasons why it is difficult for me to imagine development where the entire process is fully delegated to AI. Even if it can suggest a similar solution, the enjoyment of searching, understanding, and implementing simply disappears.

Well-designed application architecture

The application architecture started with a fairly difficult goal: the iOS application needed the ability to open any screen from any other screen while still keeping a clean navigation stack, avoiding memory leaks, and maintaining performance. At the same time, the application itself is much simpler than the architectural goals I set. But that is exactly why pet projects are valuable — they allow you to improve your skills and experiment with solutions that you may never encounter in regular work.

As a result, the application architecture includes several fairly advanced approaches for iOS development: Coordinator, Assembler, Dependency Injection, MVVM, and Observation. Designing and implementing this entire structure took a lot of time. But the enjoyment of good architecture turns out to be reusable.

Now that it is time for updates, adding a new screen happens quickly and calmly. And every such update once again brings satisfaction from the fact that the architecture was designed properly from the beginning.

With AI, a significant part of the application could be regenerated for a single new screen. But the process of this kind of generation is difficult to call engineering work. It cannot be compared to extending a well-designed architecture that a developer built and evolved personally.

User feedback

All of the things above gradually turn into something personal — a project that the developer starts treating almost like their own creation. That is why user feedback feels especially meaningful after release.

Every positive review is a small moment of euphoria.

“Convenient tool”, “Well-designed educational materials” — comments like these bring an incomparable feeling that all the work truly had meaning.

But negative reviews are important in their own way as well.

“It would be nice to add…”, “This part feels slightly inconvenient…” — after comments like these, you immediately open the project and start thinking about how to improve the product.

It is exactly this deep involvement in your own project that allows you to experience all these emotions. When an application feels not like a set of generated code, but the result of long and thoughtful work, the connection with the product becomes completely different.

AI is not our enemy

After everything written above, it is important to say this clearly: AI is absolutely not an enemy of developers. On the contrary, it can genuinely speed up work and help with a huge number of tasks. In my case, AI helped with many things:

Routine tasks. For example, educational materials had to be assembled into XML following specific rules. AI handled this very well.
Help during app publication. Texts, App Store questions, and various publishing details become much faster with AI.
Small code-related things. While working on architecture, it is easy to forget even the simplest things. AI helps quickly recall a solution or syntax.
UI and design discussions. Even with a finished design mockup, small UI questions constantly appear during development. In situations like this, AI becomes a good assistant for discussing solutions.

AI handles tasks like these really well. And at the same time, these are rarely the tasks that bring real enjoyment from development itself.

AI is an ideal assistant, but keep the enjoyment for yourself

AI can genuinely provide strong and fairly qualified help during development. It can answer many questions, remind you about different mechanisms, help with routine tasks, and even create a work plan for a pet project. In this sense, AI is truly an excellent assistant.

But the process itself means nothing to it. By delegating not only routine tasks, but the entire development process to AI, a developer loses the experience, the enjoyment of building an application, and the satisfaction of the final result.

So perhaps the best way to use AI is to keep it in the role of assistant while preserving the development process for yourself. Stay involved in the work, search for solutions, build architecture, release products, and enjoy the entire process of creation.

Design decisions behind my “Irregular German Verbs” iOS app

Roman Voinitchi — Thu, 21 May 2026 12:47:43 +0000

A pet project is, first of all, a way to learn something new in your own field. I have a 9–5 job, but I almost always work on some side projects as well. The difference is that until now I had never actually brought one to the App Store like my current app — Irregular German Verbs. Why did I finish this one? And why exactly this topic?

Thanks to my wife — a university German language teacher with 25 years of experience. She clearly understood which topic should become a standalone app and how exactly it should be presented. The app is based on my wife’s educational ideas, and the app itself clearly states whose educational methodology it is based on.

You can find the full list of product decisions on the product page. In this article, I want to explain why these particular decisions were made.

One problem, One tool

Irregular German Verbs is a very narrow topic. The app contains only 191 verbs that simply have to be memorised. At first glance, it may seem more logical to build something larger and more universal. We discussed that option as well. But when I suggested making something bigger, I received a categorical “no”. And the reasons were purely educational:

this topic should not be mixed with any other;
Irregular German Verbs is difficult because these verbs simply need to be memorised — there are no rules here;
a proper memorisation system is required, a simple table is not enough.

That is exactly the approach I started development with.

No ads, No tracking, No subscriptions

Learning requires concentration. Ads and tracking create unnecessary distraction and stress. As a developer, I tried to argue for ads a little. But my wife, as a teacher, responded with a very clear “no”. When she teaches students, distractions are not acceptable.

And when it comes to subscriptions, I personally dislike them as well and try to avoid them whenever possible. If translated into the educational process, this app should feel more like buying a book: you pay once and continue using it peacefully afterwards. Which feels honest and familiar for students.

Free A1-A2

The app includes a decision that is not very obvious and definitely not very profitable for a developer — A1-A2 levels are completely free. And that is basically one third of all verbs in the app. But this decision also comes from educational principles. Everyone learns differently:

some people prefer video;
some prefer audio;
some prefer books.

A student should be able to calmly try the material and understand whether this format works for them.

A1-A2 levels are designed specifically for beginners learning German. If a student decides to continue further, unlocking all verbs requires a one-time $2.99 purchase, which is a very reasonable price for educational material of this level.

After the purchase, all learning levels and extended testing options become available.

No aggressive gamification

I am a native iOS developer, but my background is strongly connected to games. Naturally, I know Game Center very well, and almost immediately I suggested adding gamification features:

achievements;
visit streaks;
different progress rewards.

At one point I even suggested implementing streaks without Game Center.

But none of these ideas passed the teacher’s approval. All of this distracts from a difficult topic and serious educational material. That is why the app only includes progress tracking — simply as statistics for the student. Nothing more.

Code and architectural decisions

For me, a pet project is also a great opportunity to learn something new, build a clean architecture, and experiment with code. At the same time, I have a regular 9–5 job, so I can dedicate maybe a couple of hours per day to the project, and not even every day. Sometimes the main job simply wins.

Taking all of this into account, the project took 2 years to develop. For an app like this, that is still quite a long time. But as a developer, I am happy with:

the architecture;
the code;
and the knowledge I gained during development.

What’s next

During development, we barely looked at competitors. This is a specific educational system created by a specific teacher — Ecaterina Niculchea. So for us, it was not that important what other apps were doing. After releasing the app, we finally decided to take a closer look at competitors — and honestly, we were very happy with our own solution.

In any case, what I released was an MVP. Even before release, I already had a long list of ideas: interface improvements, new settings, testing improvements, and overall UX polishing. All of these are new and interesting product decisions for the future development of the app.

I also noticed some interesting ideas in competitor apps — and that is completely normal. So the next step is gradual improvement and polishing the product as much as possible. After that, I will probably try submitting it for an App Store feature. I hope the product will be strong enough for that by then.

One of the strategic product design decisions was the desire to gradually polish the app and bring the project to the best possible state. This is exactly what I am working on now, and almost every new update brings new product decisions.

What about you? What difficult product or architectural decisions did you make in your own pet projects?

My anti-burnout system as an indie developer

Roman Voinitchi — Thu, 14 May 2026 13:50:32 +0000

Work is not everything

I am an iOS developer. I work full-time on a game project, eight hours a day. My experience and qualifications allow me to feel calm. But programming is more than just work for me.

It is important for me to constantly update my knowledge and follow how software development evolves. As a result, about three more hours of learning are added to my main job every day. This can be reading documentation, building pet projects, or exploring new directions. The form may change, but the essence is the same — all of this requires time, energy, and focus.

All these complex tasks and advanced topics take up 11 hours every day. That is a lot. And without a clear schedule, this kind of routine can easily lead to burnout.

Anti-burnout is not a one-time action

When I was younger, things were simpler. While studying for my master’s degree, working at the same time, and learning new things at night, occasional days off really helped. Youth allows you to ignore fatigue more easily.

Over time, both my approach to work and the work itself have changed. The depth of learning became different. If earlier I was learning how to write variables, now I study algorithms, data structures, and architecture. Work tasks also became more complex — more fundamental problems that require up-to-date knowledge and constant attention.

And all of this still happens within the same 11 hours every day. In this situation, a random day off no longer solves the problem. A system is needed.

My anti-burnout plan

Over time, I developed a clear structure that helps me stay productive without constant pressure and exhaustion:

Daily level — no more than 11 hours of programming per day. After that, only family and activities I enjoy.
Weekly level — 5 working days and 2 days off. No programming on weekends.
Half-year level — two weeks of vacation every six months. No work and no staying connected.

It is important to note that I work remotely. This schedule is designed for remote work and may differ from an office routine.

Daily level: what a normal day looks like

For a remote worker, it is important to start the day with work. Breaks and other activities come later. This kind of start already gives several hours of productive work.

During the day, pauses appear naturally. Between main work and learning, a proper reset is required — without it, new information is simply not absorbed. Learning itself, whether it is pet projects or something else, usually goes without breaks. It is my hobby and something I genuinely enjoy.

As for activities during the day, the key point is that they should be personal — something that truly helps you rest. I have two such activities.

Activity #1. baCist — bass guitar from a programmer

I cannot imagine my life without music. I have been playing bass guitar for a long time. This activity truly calms me down, helps me recover, and gives me energy.

During the workday, these are short 5–10 minute breaks just to groove. After all the work and learning, I usually spend about an hour playing calmly and learning something new.

Activity #2. Daily physical activity

For me, this is a simple walk close to a workout: 5–6 kilometers at a fast pace, with a heart rate above 100. This is a daily practice, including weekends. On weekends, I just walk longer and more calmly.

The most important thing is not to stop and to take care of yourself every day. The type of activity can be different for everyone, but the fact that a programmer needs regular physical activity is obvious to me.

Two days off in a row is mandatory

Even with a good daily schedule, the last working day of the week still feels heavy. That is why two days off in a row are essential for me. During this time, I completely exclude programming. Usually, this includes:

calm walks
bass guitar
cooking
football
sleep

This is enough to start a new week with a sense of freshness, not resistance.

Two weeks of vacation without work or connection

Just like the end of the workweek, the last month before a vacation feels especially heavy. This is where the need for a two-week break appears — a break with no mentions of programming at all.

Even though my work is something I love, it is important for me to fully disconnect from development at least twice a year. Changing the environment and traveling helps the most.

This is also where the travel direction of this website comes from. I have accumulated many places and travel stories that I genuinely want to share.

Anti-burnout is not procrastination

An anti-burnout plan is not laziness and not an attempt to avoid work. It is a way to preserve energy for long-term, stable work on something you truly enjoy.

Everyone can have their own approach, their own intervals, and their own forms of rest. But one thing is clear: such a strategy is necessary. And it is essential if you want to stay productive seriously and for a long time.

I am also curious — do you have any habits, activities, or systems that help you avoid burnout?