One Man Army

HOW IT ALL BEGAN

The ephemerality of results and the glass ceiling

[2025.08.15]

With over twenty years of experience in graphic design under my belt: from raster and vector to 3D and motion. In my case, it was almost never just drawing "for the soul"—only harsh commercial reality with strict deadlines and manager oversight. Over time, the magic of creating visual imagery inevitably turns into a conveyor-belt routine. You clearly realize you've hit a solid glass ceiling, and every new workday becomes merely a technical repetition of what you've already done hundreds of times before.

The most depressing factor in this profession was the absolute ephemerality of the results of my labor. A meticulously balanced composition of a promotional flyer lives only until it reaches the nearest trash can, and a beautiful social media post rapidly sinks into an endless information feed. Posters, packaging, short video ads—all of these are commercial one-offs. I developed a persistent feeling that I was engaged in creating an attractive but fleeting shell with a shelf life measured in hours.

Thus, the need to move forward and create something greater, flexible, and functional matured. I didn't plan to radically break my life and leave for alien fields—I wanted to stay in my element, at the same desk, but radically expand my coordinate system. The realization came that all my accumulated visual baggage should no longer be the final destination. It can and must become a powerful auxiliary tool for engineering and constructing my own long-lasting software mechanisms.

PARADIGM SHIFT

From visible pixels to hidden logic

[2025.10.11]

An interest in programming had lived in me for a long time, dating back to the late 80s and computer science clubs where we studied Basic. Years later, there were spontaneous attempts to dive deeper into code—for example, experimenting with the popular Python in 2023. But due to a lack of a clear plan and understanding of the final goal, everything was limited to trivial console string outputs and simple arithmetic operations. Further development required the traditional path: specialized courses or working in a studio, which seemed like an entirely unrealistic scenario. The barrier to entry looked like a monolithic wall.

Everything changed when large language models massively burst into our lives. I immediately saw them not as the notorious "Do everything for me" button, but as an absolute, tireless mentor. Previously, you had to gather information crumb by crumb on forums, endure the arrogance of local "gurus," or take courses in the spirit of "how to draw an owl." Now, the learning process has been compressed into the ideal real-time cycle: Question — Answer — Clarification — Practice. AI became the very bridge that allowed me to step over the barrier to entry and start studying architecture, rather than just copying someone else's solutions.

But the most difficult stage turned out to be the paradigm shift itself. In a graphics editor, you create an object and immediately see it on the screen with all its properties. In programming, everything shifts into the realm of invisible abstractions, states, and logical connections that cannot be "touched." The cinematic myth of developers furiously typing on a keyboard was quickly shattered. In practice, engineering means maximum concentration in front of a monitor with a paper notebook at hand. You might spend a whole hour building a system in your head just to write a single line of code, only to rewrite it later upon realizing it breaks the logic in a completely different place.

THE .NET REVELATION AND PRAGMATISM

An ecosystem of possibilities and abandoning the "Dream Game"

[2025.12.23]

The real catalyst for my dive into development was Jeremy Gibson Bond's book on game development with Unity and C#. Moving from the substantial theoretical part to practice brought me into the game engine's interface, which, for someone who had spent years working in 3D editors, turned out to be a surprisingly familiar and comfortable space. But the main discovery was not the engine itself, but the language that powered it. I started asking the neural network questions, googling tons of information, and the big picture began to emerge.

Delving into the study of C#, I began to realize the true scale of what I had encountered. It turned out that the language is the core of Microsoft's colossal .NET platform. It was akin to an engineering revelation: an incredibly vast, fundamentally well-thought-out world opened up before me. The understanding came that I held the ultimate set of tools, allowing me to build absolutely anything—from mobile games to complex web services and desktop applications. The question of choosing a technology stack simply vanished.

To avoid drowning in this ocean of information, I built my own "learning academy" in tandem with my AI mentor, outlined a strict roadmap, and began mastering topic after topic. The main lesson I learned right at the start: to learn how to make good projects, you need to make many projects. The illusory "Dream Game" was consciously and immediately cast aside. I focused on creating a project that might be simple and somewhat clunky, but complete. That is exactly how the development of DRiot began—my first full-fledged combat training ground.

THE FINAL BOSS OF DISTRIBUTION

The 80/20 rule and the quest called release

[2026.04.30]

There is a well-known rule in development: the first 80% of work on a project takes 20% of the time, and the remaining 20% (polishing, bug hunting, building) drains 80% of your energy. It is exactly at this stage that many break down, leaving their hard drives as graveyards of unfinished prototypes. Thanks to my theoretical foundation, I was ready for this. It didn't bother me at all that an experienced professional might give my code a low rating. The main goal was to see it through to the end: a clunky but finished project is always better than a perfect but abandoned one. The process was captivating, even when I got stuck on complex logic for a long time and had to painfully roll back to stable versions.

But it turned out that writing the logic and compiling a working build was only half the journey. When DRiot was technically ready, the full picture of what distribution actually means opened up before me. Initially, releasing on Google Play seemed like a walk in the park. In reality, it turned into a grueling quest: convoluted and illogical verification systems, data safety declarations, age ratings, and a mandatory 14-day closed testing quarantine. Fortunately, the developer community proved to be lively and responsive, and finding people for testing on Reddit using a "test-for-test" principle wasn't difficult. But the sheer volume of bureaucracy was mind-boggling.

In parallel, I also had a finished iOS build on my hands, but its release required owning a MacBook and a deep dive into Apple's infrastructure. Running around borrowing hardware from acquaintances just for publication was entirely unappealing. I made an absolutely pragmatic decision: for a first project, Google Play was a perfect fit, and the narrow, closed "aquarium" of the Apple ecosystem simply lost my interest. This entire bureaucratic stage was exhausting, but it felt like battling the final boss. And when the game was finally published, I experienced a hard-to-describe sense of victory—the first full cycle of solo development was successfully closed.

THE INFRASTRUCTURE WALL

The lesson of inNote and the pivot to the open web

[2026.07.17]

After the first completed project came a desire to expand my horizons and see what else the .NET platform was capable of. The next step was desktop development—creating the inNote application. Technically, it was an incredibly interesting challenge: designing a custom interface, working with local data, writing my own service, and packaging it all into a neat installer. At this stage, it seemed that if you had a great, stable working product in your hands, releasing it wouldn't be a problem at all. I didn't just want to drop the app on the web; I wanted to go through the entire commercial release path to understand how this system works from the inside.

This is exactly where I crashed full speed into a solid infrastructure wall. It turned out that writing good code is far from everything. The real world of commercial distribution proved to be a harsh labyrinth of bureaucracy, regional restrictions, inaccessible payment gateways, and withdrawal issues. Colliding with this clumsy system caused strong disappointment, apathy, and anger. It hurt to realize that a technically fully finished project had to be put on pause not because of bugs or poor architecture, but due to insurmountable external barriers.

But this painful period didn't last long. A bitter taste remained, yet the obstacle acted as a perfect catalyst. Web development had long been on my list of areas to "probe," and I took this pause as a sign that the time had come. By that point, a massive amount of materials had accumulated on my local hard drive: dev logs, thoughts, drafts, and the projects themselves. I decided not to just make a simple business card page using a ready-made builder, but to fully dive into a new stack. That's how the creation of inHub began—an attempt to organize all the chaos into a unified system and build my own digital home, accessible to the entire world.

ABSOLUTE FREEDOM AND ANCIENT SCROLLS

The paradoxes of the web and the solo developer's pipeline

[2026.08.01]

Solo development requires strict discipline; otherwise, the project will inevitably devolve into chaos. Gradually, a clear working pipeline formed for me: Project Vision -> Tech Stack -> Roadmap -> Dev Log. I don't consider myself part of the growing trend of "vibe-coders" who simply ask an AI to generate everything for them. In my process, AI is an advanced sparring partner. We discuss concepts, I show it architectural drafts, it helps find bottlenecks, but the final decisions and logic always remain mine. A separate revelation was maintaining a Dev Log: it not only structures the step-by-step development process but also saves the language model itself when its context gets "blurred" and it needs a quick reminder of the project's global essence.

Venturing into the open web with the development of inHub provided a long-awaited sense of space where you can breathe much easier. There are no corporate restrictions, moderators, or closed "aquariums" here. The line "public object InHub { get; private set; }" works quite literally here: this is my territory, and these are my rules. But along with this freedom came an encounter with a surprising paradox. Web development itself feels technologically stuck in the past. Writing HTML by hand, with its endless tags, feels like deciphering ancient scrolls. For an engineer accustomed to node-based logic, where architecture and visuals are assembled by nodes in real time, this manual syntax looks like an archaism that should have been buried deep "under the hood" long ago.

Despite this dissonance, the strategic task has been accomplished. inHub was built from scratch on ASP.NET Core and became an independent digital home uniting scattered projects, logs, and experiments. The current architecture is not the final point, nor is it the end of the story. It is merely a reliable, fully controllable foundation for exploring new domains. The journey continues.

What, how and why does this happen...