DEV Community: Eugene Kozlovsky

Building NICHLYST: The Weight of 40 Days, 29 Endings, and a Style Anchor

Eugene Kozlovsky — Thu, 13 Aug 2026 21:01:28 +0000

Three days ago, I published the first devlog. I had a 128-step plan, a blank APK, and 3 Google Play testers. Today, I have 40 days of structured narrative content, 29 endings, a full art pipeline, and a very familiar tightness in my chest.

Let me explain.

The Content Freeze

Between August 10th and August 13th, I completed a massive chunk of the antifragile plan. The most critical milestone was the content freeze.

What does "frozen" mean? It means NICHLYST now has a definitive shape. Unless a miracle happens and I find myself far ahead of schedule with time to consider expanding the lore, the scope is now locked. The JSON file that drives the entire game has been committed, tagged, and backed up to Google Drive.

Here is what that structure looks like:

40 days of narrative content.
29 endings (main and hidden).
Multiple resource counters (some visible to the player to manage survival, others running silently under the hood, tracking psychological and moral degradation).
Over 100 global flags tracking every choice the player makes.

I wrote the initial script as a markdown document, then structured it into JSON. The English translations were finalized alongside the Ukrainian originals, as the hackathon requires all submission materials in English.

The Moral Audit

Before freezing the content, I ran a moral complexity audit on the entire game. My design formula is simple: every choice must pit the value of testimony against the cost of survival. No binary good/evil. No easy outs.

The audit checked every single day for six criteria: no binary good/evil, testimony vs. survival tension, consequence weight, emotional cost, no easy outs, and narrative coherence.

The audit found 39 out of 40 days passing all six checks. One day failed.

It was a breathing space between two heavy acts. The problem? Both choices had zero mechanical consequences. No resource deltas. No flags set. The player could experience the day as cost-free.

That is a violation of the core design philosophy. In NICHLYST, nothing is free. So I fixed it: accepting help now costs a psychological resource (the moral weight of compromise), and refusing help costs a social resource (the cost of pride). The fix was committed, and the content was frozen.

The audit also identified some of the game's strongest moral scenes — moments where the player must decide whose memory gets preserved, whose identity gets erased, and whether to warm the paper archive or the living people in the freezing basement. These are not fun choices. They are not supposed to be.

The Art Pipeline: Style Anchor and Privacy

With content frozen, I moved to art generation. The design document specifies a "muted gouache and ink-wash illustration" style — desaturated, painterly, Eastern-European post-industrial. This is the style anchor.

I am using a single AI model for this: MAI-Image-2.5-Pro.

I rejected other tools because their creations are public by default. I am not publishing art before the game ships. Privacy is a stop-loss.

I generated a series of test images to validate the style anchor. Then I generated:

Character sheets and portraits for the Archivist and all visitors.
Base background locations for the underground node and the besieged city.
Postscript locations reflecting the slow decay after the finale.
Flat papercut UI icons for the visible resources.
The 1024×1024 app icon.

Every single image was manually audited against a negative checklist: no real flags, no military insignia, no celebrity likenesses, no readable text, no brand logos. One image initially had a pattern too close to real military gear. I regenerated it with explicit instructions for nondescript, worn winter gear without any insignia, and passed the audit.

The 23:00 Rule Met Reality

In my first devlog, I wrote about the 23:00 hard stop. I said an antifragile plan must absorb bad days.

I had bad days.

War breaks a person. Even a civilian one. It shatters the psyche. But paradoxically, it also builds a strange kind of callus. You start perceiving things not as acutely as you might have years ago. Explosions become background noise. But the internal pressure remains.

On August 10th, I felt the pre-panic state creeping in. A tightness in the chest, shallow breathing. I knew exactly what it was — I've been treating GAD for over a year. It didn't escalate into a full attack, but the physical toll was there. Sitting at my desk, trying to write JSON while my nervous system was bracing for an impact that wasn't coming.

On August 11th, Russian ballistic missiles hit Kyiv again. The explosions were loud. But I didn't panic. I just kept working. There is a strange detachment that develops — you hear the booms, you acknowledge the danger, and you return to the code. The anxiety that day wasn't about the missiles; it was the quiet, creeping dread of an exhausted mind.

None of these days were perfectly productive hackathon days. The plan bent.

But the plan did not break.

On the morning of August 13th, I sat down, opened VS Code, and committed the final content freeze. The JSON was valid. The art was generated. The moral audit was complete. The structure was intact.

The antifragile plan absorbed days of anxiety and war, and the project still shipped its milestones on schedule.

The Tester Update

In my first post, I asked for help with the Google Play 20-tester bureaucracy.

I now have 6 emails.

It is progress, but the math is still unforgiving. I need 20 testers to bypass the 14-day closed testing wall before I can publish to production.

So, I am putting this directly into this devlog again. If you are reading this, have an Android device, and 2 minutes to spare, please help a fellow builder bypass this bureaucratic wall.
👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

You will just need to accept an invite from Google Play later, download the app, and keep it installed for 14 days. No deep QA required. Just your presence to satisfy the algorithm.

What Comes Next

The content is frozen. The art is generated (resizing and compression are deferred to pre-APK build — another stop-loss decision to avoid perfectionism).

Next up: Phase 4 (Audio) and Phase 5 (Engineering — the game engine in HTML5/JS, reading from the JSON). The hardest part is still ahead. Writing a JavaScript state manager that tracks all these counters, flags, and ending conditions — all running inside a Capacitor Android wrapper on a phone.

But the foundation is no longer fragile. It is concrete that was poured during a heatwave, under missile alerts, through the fog of GAD.

NICHLYST is coming. And the content is frozen.

Follow this devlog for the #BuildInPublic journey.

Building NICHLYST: An Antifragile Approach to Surviving a Hackathon (and Reality)

Eugene Kozlovsky — Sun, 09 Aug 2026 21:30:57 +0000

I’m 36. From Kyiv.

Right now, my city is suffocating under a heatwave. At night, the air raid sirens wail, and the psychological weight of a war with no end in sight presses down on every decision. I am typing this on an AMD A4-4020 with 8GB of RAM — a machine so weak it chokes on modern web browsers.

I am not a traditional developer. I am a vibe coder. To me, vibe coding isn't just a buzzword; it's a philosophy. It’s the ability to translate a feeling, an idea, or a complex vision into a precise prompt for a machine. It’s about orchestrating AI to bring a concept to life, rather than getting bogged down in the syntax of writing code from scratch. By day, I work as a webmaster and system architect, navigating a full-time job and a complex medical regimen.

Yet, I am entering the RevenueCat Shipaton 2026 hackathon. Alone. Against teams with M2 Macs and budgets.

Why? Because I don't just want to build an app. I want to prove that constraints don't kill projects. Fragility does.

This is the story of NICHLYST — a slow narrative survival-archive sim for Android — and the 128-step antifragile plan I wrote to ensure it actually ships by September 28th.

The Concept: Survival as a Gameplay Loop

In NICHLYST, you are an archivist in a besieged city. You don't fight. You record. Every day, someone knocks on your door with a story. You must choose: record the full truth and risk your safety, or edit it to survive. The consequences don't arrive immediately — they arrive days later, via a real-time push notification, forcing you to live with the anxiety of your choices.

It’s a game about documentation, truth, and the civilian experience of conflict.

Phase 0: The Pre-Mortem

Most hackathon projects die because developers start coding on day one. I started by writing a 128-step plan, but before writing a single line of code, I forced myself to do a pre-mortem.

I listed the 10 most likely ways NICHLYST would fail. Here they are, raw and unfiltered:

My weak local PC freezing during an Android build.
Solo development bottlenecks.
Missed evenings due to fatigue or schedule conflicts.
Google Play App Review delays.
AI art style mismatch or inconsistency.
RevenueCat sandbox failure or SDK integration issues.
Missing the hard deadline entirely due to scope creep.
Psychological burnout.
Catastrophic loss of content or code.
Conflict with an existing 32-day evening schedule I must maintain.

Then, I applied Nassim Taleb's Antifragility framework. I didn't just want to mitigate these risks; I wanted the project to benefit from the stress.

The Barbell Strategy: I allocated 90% of my time to the core, guaranteed MVP. The other 10% is strictly time-boxed for bonus categories. The "middle ground" — medium-risk, medium-reward tasks — is entirely eliminated.

Stop-Loss Dates: I hardcoded triggers into my plan. If the AI art pipeline isn't done by August 26th, I don't argue with myself. I automatically cut the art scope to a stark, 1-bit CSS visual filter and move on. Emotion has no place in the schedule.

The 23:00 Rule and the Reality of Mental Health

My plan includes a strict rule: work ceases at 23:00. A tired solo dev creates more bugs than they fix. Sleep is a strategic investment.

But that’s the theory. The reality is messier.

Sometimes external factors — late shifts at my day job, or the air defense activity in Kyiv — make the 23:00 deadline impossible. And then there are the internal factors. I live with GAD and depression. There are days when there are no missiles, no extra work, but my brain simply refuses to cooperate. The energy tank is empty. On those days, the only achievable victory is making it to the shower and getting into bed.

An antifragile plan can’t be a rigid, brittle clockwork. It must absorb these bad days. If I miss an evening due to a depressive episode, the Stop-Loss dates protect the project. The schedule bends, but it doesn't break. It accommodates the reality of being human.

Phase 1: Infrastructure and the Art of Being Broke

I operate on a strict, near-zero budget. My monthly income is about $700 USD, and rent consumes half of it. The only financial investment I made was paying the $25 Google Play Console registration fee — a serious amount of money for me right now.

The Shipaton sponsors heavily promoted Replit for cloud builds. Replit even offers a 40% discount for hackathon participants. But even with the discount, a Replit Pro subscription is financially impossible for me.

So, I engineered a workaround. I set up a local development environment on my Xubuntu 26.04 LTS machine using VS Code. For the heavy lifting — compiling the Capacitor Android APK — I connected my GitHub repo to Codemagic's free tier.

The setup wasn't painless. Capacitor v7 requires Java 21, but Codemagic defaulted to an older version. My first cloud build failed with error: invalid source release: 21. A quick edit to the codemagic.yaml file fixed the environment variables, and the build went green.

When I sideloaded that blank, debug APK onto my Xiaomi Redmi Note 9 Pro and saw it launch... it wasn't just a blank screen. It was proof that a pipeline running from a $0 local machine to a $0 cloud builder to a physical device actually worked. The cycle was closed before I wrote a single line of game logic.

The Google Play 20-Tester Bureaucracy

Then came the infrastructure hurdle. Google Play now mandates a 14-day closed testing track with 20 active testers before a new personal account can publish to production.

This is a bureaucratic nightmare for a solo dev with a ticking clock. If I wait until the game is done to start this timer, I will miss the deadline. So, I built a Google Form and posted it in the Shipaton Discord, my social channels, and sent it to colleagues.

The result? Humbling.
I got 3 emails from colleagues — my most loyal audience. From the Discord community? Zero. After 24 hours, the form remains agonizingly empty.

I try not to succumb to panic. I try to filter out the noise, both from the outside world and my own anxiety. But the math is unforgiving: I need 20 testers, and I have 3.

So, I am putting this directly into this devlog. If you are reading this, have an Android device, and 2 minutes to spare, please help a fellow builder bypass this bureaucratic wall.
👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

You will just need to accept an invite from Google Play later, download the app, and keep it installed for 14 days. No deep QA required. Just your presence to satisfy the algorithm.

The Unseen Labor

Right now, NICHLYST is just a 128-step plan, a handful of .md files tracking risks and deadlines, a GitHub repository, and a codemagic.yaml configuration. No art, no story code, no RevenueCat paywalls yet.

But the foundation is poured. It is not fragile.

The day before yesterday, after a 10-hour shift at my day job and helping my wife with her transcription work, I had zero energy left. I didn't code. I didn't force it. I followed the rule: I updated my PLAN_STATE.md log with one sentence, did a git commit, and went to sleep.

In a hackathon, survival isn't about sprinting. It's about building a system that allows you to keep walking, even when the ground is shaking.

NICHLYST is coming. And it will ship on time.

Follow this devlog for the #BuildInPublic journey.

One person, one project, one month: Building Svitlogics from Kyiv

Eugene Kozlovsky — Sat, 12 Jul 2025 00:13:56 +0000

This is a submission for the World's Largest Hackathon Writing Challenge: Building with Bolt.

I'm 34. From Kyiv. A city that has learned to live by the sound of sirens.
Because of my health, office life is impossible for me. So my home became my studio.
I’m not a professional programmer. I know some Python, that's it. My real strength is something else. A process known as "vibe coding"—the ability to translate a feeling, an idea, a vision into a clear prompt for a machine.

When I saw the announcement for the World’s Largest Hackathon presented by Bolt, my first thought was crushing.
Who am I to compete?
A 34-year-old guy from Ukraine. Not a developer. Alone. Against 70,000 participants. Against entire teams. It felt absurd.

I almost gave up on the idea.
But a day before registration closed, I asked myself: what did I really have to lose? Time? I waste it doomscrolling anyway. A prize? The odds were tiny.
But the potential gain was incredible. Experience. And most importantly, a chance to build something that matters.

That idea was already living in my head. Svitlogics.
The name combines the Ukrainian word "світло" (transliterated as svitlo, meaning "light") and "logics" for reason.
This isn’t just a tool. It's my personal mission. Because I believe we must bring light into the information chaos. And while this is a global issue, here in Ukraine, the ability to see clearly has become an acute survival skill.

On May 28th, I registered. On the 31st, I began.
My first prompt was simple. Very simple. "Create the full structure for a web application. The design should have a brutalist vibe. The app's purpose is to analyze text." Then I hit "Enhance prompt" and let the AI work.

The result was… magic.
It wasn't what I envisioned, but it wasn't entirely wrong. Bolt.new had created a functional text analyzer, but one that focused on word counts and character metrics, not the nuanced analysis of manipulation I had in mind. But I didn't feel disappointment. I felt euphoria.
That feeling when you see a first, wobbly, but incredibly important step.
The foundation was laid. It was imperfect. It was raw. But it existed.
The first light of Svitlogics had been switched on.

Onwards.

Let me start with the questions…

… The ones people ask.

"Why does it look so... raw?"
"Where are the shadows? The rounded corners?"
"Isn't it a bit... primitive?"

My answer is simple. And it’s always the same.
This is not a mistake. It is a choice. It is a philosophy.

I call it "Pure Minimalist-Brutalist."
Because I believe form must serve substance. Not hide it.
Svitlogics exists to cut through the noise. Its design must do the same. No exceptions.

Modern UI uses soft shadows to create depth. It uses gentle gradients to feel "friendly."
This is persuasion.
It’s the same toolkit manipulators use, just with visuals instead of words.
I refused to fall into that trap. For a tool that dissects lies, a "friendly" interface would be the biggest lie of all.

So. No shadows. No gradients. No visual tricks.
Because they are noise. Because they distract. Because they are not honest.

The font is IBM Plex Mono. For one reason: absolute clarity. It sets a serious, analytical tone. It signals that this is a tool for thinking.
The palette is even stricter. Black and white. For pure contrast.
And one single color. Blue.
It’s not for branding. It’s for function. It has only one job: to say, “You can act on this” or “This is a key result.”
One color. One purpose.

This design is not about being "beautiful."
It is about being honest.
And for a tool designed to fight for clarity, honesty is the only thing that matters.

Unapologetically.

If the design is its soul…

…the system prompt is its brain.
It’s what turns a general AI into a specialized tool. And building it was the hardest part of this journey.

My first approach was naive.
I thought I could write one "universal" prompt for both English and Ukrainian.
I fed it an English text. The result was… promising.
Then I fed it a Ukrainian text.
A total mess.
The AI missed the cultural context. The scores were erratic. The justifications felt soull-ess.

This wasn't a turning point; it was a confirmation of what I already knew, especially after Russia's full-scale invasion: language is a weapon. The way manipulative narratives are constructed in English-speaking media can be vastly different from the techniques used in texts aimed at a Ukrainian audience. A universal tool would be a blunt instrument where a scalpel was needed.
So I threw out the universal idea. And started over.
Two separate prompts. One for each language. Double the work. But it was the only way.

The process became a relentless loop.
Prompt. Test. Analyze. Refine. Repeat.

First, the data. I realized my initial test texts were too simple.
So I spent hours building a richer dataset. Corporate press releases. Political speeches. Opinion pieces. Even 20th-century propaganda.
Then I did something more. I used another AI to create synthetic data. To generate perfect examples of disinformation, with every manipulation I wanted to teach Svitlogics to see. It was like a targeted training course for my AI.

Then, the real grind began.
I’d run a test. Svitlogics would miss a manipulation.
Why?
My prompt was too vague. "Look for logical fallacies" isn't enough.
So I’d refine it.
“Search for a 'Straw Man' argument. A 'Straw Man' is when you misrepresent someone's position to make it easier to attack. For example…”
Then I’d run the test again. A small victory. It found the Straw Man. But it missed the Appeal to Emotion.
Back to the prompt.
Another iteration. Another test.
For hours. Days. Living in this cycle.

Every success was a jolt of pure ecstasy. Every failure, a command to think clearer. To instruct better.
This is the unseen labor behind Svitlogics.
It's not just an API call. It's a carefully calibrated instrument.
And the prompts are its secret sauce. The result of dozens of hours of obsession.

The cascade eureka

At first, Svitlogics was fragile. It relied on a single AI model.
A choice born from pragmatism. I had a zero-dollar budget. It was free and generous.
For a while, it worked.

Then, during an intense testing session, it broke.
429 Too Many Requests.
I had hit the limit. My workflow, my focus — shattered.
It was more than an annoyance. It was a fundamental flaw. A single point of failure.
A tool for clarity cannot be this unreliable.

The dilemma was classic. A smarter model with stricter limits? Or a dumber one that was always available?
Neither was good enough. It needed to be smart and resilient.

The answer came to me while staring at the Google AI documentation.
I didn't have to choose one model. I could use them all.
The idea was a cascade. A sequential fallback system.
It would try the best model first. If that failed, it wouldn't show an error. It would seamlessly try the next one. And the next.
From a fragile pillar to a resilient, multi-layered structure.

I built a priority list of seven models.
The smartest and fastest at the top. The high-volume "workhorses" in the middle. The most limited one at the very end, defining the baseline for the whole app.
This became the central nervous system.

I chose to build this logic entirely on the client-side. In the browser.
Simpler for a solo dev. Faster to deploy.
I rewrote my API service into a recursive function.

Here’s how it works.
The system starts with the highest-priority model. It makes the API call.
Success? Great. The job is done. The user gets their analysis.
But if the API returns an error 429—meaning the model's quota is hit—there's no panic.
The function simply calls itself again, this time targeting the next model down the cascade.
This loop continues until it either gets a successful response or has tried all available models.
To the user, it just works.

Under the hood, it’s an elegant dance between seven different AI brains.
Orchestrated by a few lines of JavaScript code running in the browser.
Ensuring the light of Svitlogics never goes out. Even when some of its bulbs flicker.

My workflow: A symphony of two AIs

I am not a programmer. Not a traditional one.
This is the most important context.
Svitlogics exists because of a new way to create. A process known as "vibe coding."
It’s not about writing code from scratch. It's about having a clear vision and orchestrating AI to bring it to life.
The project was built by a trio. Me, as the director. And two AI partners.

Gemini was my strategic consultant. Bolt.new was my tireless engineer.
A constant, fluid dance between them.

I used Gemini as my architect and ultimate debugger. Before any big feature, I'd have a conversation with it. "I need to build a model cascade. What are the pitfalls?" It gave me blueprints. When Bolt's code broke, I didn't just ask Gemini to "fix it." I gave it the full context. The component. The prompt. The exact error. And it would find the root cause in seconds.

Bolt.new was my implementation team. It built the project structure in minutes. My daily flow was simple: discuss logic with Gemini, refine details in Bolt's Discussion Mode, then execute with Build Mode. My job was to be the lead engineer. To review. To refine.
This synergy is best illustrated by the story of when Svitlogics got "sick."

It happened on June 8th. Until then, my confidence was soaring. The plan was simple: add a language switcher to the UI. I asked my strategist, Gemini. It recommended a solid, battle-tested library.
But then, out of simple curiosity, I asked my engineer, Bolt, for its opinion. It suggested a different, lighter library. And I made a critical error. I deviated from my tested workflow and chose Bolt's suggestion.

I gave it the prompt. "Install the library."
And the machine I had come to trust turned against me.
The application collapsed. A complete, catastrophic failure.

My confidence evaporated. Frustration set in.
I spent hours in a frantic loop. Feed error messages to Gemini. Translate its advice into prompts for Bolt. Each attempt was a gamble, burning my precious token allotment. The afternoon bled into evening. I was getting nowhere.

Then, the air raid sirens began to wail in Kyiv.
The dissonance was surreal. Wrestling with a broken app—a problem entirely of my own making—while the very real threat of missiles loomed outside. It was a stark reminder of priorities.

In that moment, I had to make a decision. Not as a developer chasing perfection, but as a project manager with a hard deadline.
I could keep fighting this losing battle. Keep burning time and tokens on a feature that wasn't core to the mission.
Or I could retreat.

I chose to retreat.
The next day, my first command to Bolt was not to fix. It was to remove.
"Delete the library. Remove every file. Every line of code. Revert everything."
It felt like a small defeat. But it was the most mature decision I could make. I realized my desire for "one more feature" had endangered the entire project.

A buggy app with a language switcher is infinitely worse than a stable, single-language app that does its job perfectly.
This taught me the most valuable lesson of this hackathon.
Ruthless prioritization.
A great project is defined not just by what you add, but by what you wisely choose to remove.
Sometimes, the most powerful move is not to write more code.
It's to decisively delete it.

Building under fire: Finding focus amidst chaos

This isn't just about code. It's about the human context.
To build a hackathon project solo, with a full-time job, is a stretch.
To do it from Kyiv, during a war, is to find focus in the heart of a storm.

There were many nights like that. Nights that started not with code, but with the wail of air raid sirens. Nights that ended not with a successful commit, but with the grimly familiar routine: running to the hallway, waiting for the thud of our air defense systems at work, and hoping for the silence that follows.
The next morning, you wake up a wreck. Utterly sleep-deprived.
For me, sleep isn't a luxury; it's a pillar of stability. Its absence is a trigger for my depressive disorder. On those days, the energy tank is empty. Zero code gets written. Zero progress is made on Svitlogics.

This is the part of the story often left out of triumphant tech narratives. The grind. The exhaustion. The many days where you produce nothing at all.
And it was on one of those days, running on fumes, that I realized my perfectionism had become a trap.
I was obsessed with making the system prompt "perfect." But the list of other essential tasks was a mountain.
I was getting bogged down. Watering a single tree, while a whole ecosystem needed attention.

So I made a strategic decision.
I split my time into two tracks.
Track 1: The Engineer. Deep, focused work on the AI brain. Reserved for the days when I had strength.
Track 2: The Product Manager. Everything else. UI fixes, writing content, project planning. Less cognitively demanding tasks for the days of exhaustion.
It was a way to keep moving forward. Always.

This was a turning point. It felt empowering.
It taught me that discipline isn't about forcing yourself to work when you have no energy left.
It’s about being smart with the energy you have.
On some days, progress is a complex new feature. On others, it’s fixing a single bug.
Both are valid. Both are steps forward.

This journey has been a lesson in resilience.
The drive to create something meaningful is a powerful anchor in a sea of chaos.
And the quiet act of writing a line of code, of building a tool for clarity while the world outside explodes, feels like a small act of defiance.
An act of hope.
And that is the most powerful motivator of all.

34 days. What started as a last-minute decision has become one of the most rewarding experiences of my life.
Svitlogics is now a real, working application. But for me, it is so much more.

I came into this not as a programmer, but as a "vibe coder."
I had a vision, a deep "why." But I believed my lack of traditional skills was a barrier.
I was wrong.
This journey proved to me that tools like Bolt.new are powerful equalizers. They shatter the walls between an idea and its execution. The future of building is here. And it’s incredibly empowering.

Svitlogics itself is a project with a clear philosophy.
It's not a judge that gives you answers. It's a scalpel to help you ask better questions.
Its mission is to empower your own critical thinking. This belief is in every part of it—from its honest, brutalist design to its core analysis. Because the most effective way to fight disinformation is not by creating a new source of truth, but by fostering more critical minds.

Building this from Kyiv gave it a meaning I never expected.
The sounds of war are not a footnote to this story. They are the ink it was written with.
It transformed a technical exercise into a personal act of resistance.

I don't know if I will win. But I know I have already won the most important prize.
The experience of building something I believe in, from zero.
The lesson of managing a project, facing failure, and finding focus in chaos.
The proof that my personal challenges do not define me.

Whether it wins an award or not, Svitlogics exists. It works. It was built with purpose.
For a solo developer from Kyiv, that is everything.