DEV Community: Eugene Kozlovsky

Building NICHLYST: How to Code a Survival Engine When You Are Failing to Survive

Eugene Kozlovsky — Sat, 29 Aug 2026 15:58:32 +0000

Building NICHLYST: How to Code a Survival Engine When You Are Failing to Survive

I track everything. It is an occupational habit of a systems architect. You cannot fix what you do not measure — not a failing build, not a leaking color, and not developer burnout. And if you are reading this while grinding through the RevenueCat Shipaton 2026 yourself, you already know that the hardest metric to log honestly is your own state.

So, let me share some metrics.

Clinical Baseline: A PHQ-9 Depression Score of 21

On May 11, 2026, my clinical assessment scores were:

PHQ-9 (Depression): 21. Severe. Immediate professional intervention required.
GAD-7 (Anxiety): 11. Moderate.

On August 22, 2026, in the middle of the RevenueCat Shipaton, I took the assessment again.

PHQ-9: 21. No improvement.
GAD-7: 16. High anxiety. Daily functioning severely impaired.

If you have never read a GAD-7 anxiety assessment, 16 sits deep in the high-anxiety band — the zone where "daily functioning severely impaired" stops being a clinical phrase and becomes your actual schedule.

While I was typing the very first lines of this post, a massive explosion went off, loud enough to make my ears pop. About an hour later, the local news feeds brought the context: an attack drone had been shot down over a park roughly two and a half kilometers from my house. According to the updates, the falling debris killed a two-year-old child and injured two adults.

I am developing a narrative game about survival, the fragility of life, and human behavior under immense pressure. But here, in Kyiv, these are not abstract game mechanics or dramatic tropes to be monetized. They are the immediate, absurd, and brutal reality outside my window.

I am exhausted. The clinical scores haven't moved in months. I sleep in the middle of the day because my nervous system simply shuts down. I am looking at this hackathon as a final, desperate push to build something sustainable.

But here is the thing about the antifragile development plan I wrote about in my first devlog: it does not require me to be okay.

The code does not care about my PHQ-9 score. The system is designed to absorb the collapse of its creator and keep moving forward.

Here is exactly how NICHLYST advanced technically and narratively over the last grueling week, while its developer was barely holding on.

The Git Gatekeeper: A Git Pre-commit Hook Enforcing a 5-color Dictatorship

NICHLYST has a strict, uncompromising visual identity. It is built exclusively on a limited color palette of five: #232626 (Pitch Dark), #3E403F (Slate), #736758 (Sepia), #A69B8D (Ash), and #BFB3A4 (Bone).

I spent hours auditing the entire codebase via terminal (grep -rnE "#([0-9a-fA-F]{3,8})\b") to eradicate every stray #FFFFFF or #000000 from CSS, inline SVGs, and Android capacitor.config.ts. I even wrote a Python script to batch-process all graphic assets through a mathematical gradient map, ensuring absolute compliance.

But human beings make mistakes. Exhausted human beings make a lot of mistakes.

So, I took the human out of the loop. I wrote a pre-commit Git hook (check_colors.sh) that acts as an Anti-Color-Leak Gatekeeper, physically verifying every staged file against our strict 5-color whitelist before allowing a commit:

#!/bin/bash
# ==============================================================================
# NICHLYST — Anti-Color-Leak Gatekeeper (Pre-commit Hook)
# Strictly allowed 5-color palette (case-insensitive, 6 or 8-digit hex):
# #232626, #3E403F, #736758, #A69B8D, #BFB3A4
# ==============================================================================

ALLOWED_PATTERN="^#((232626|3e403f|736758|a69b8d|bfb3a4)([0-9a-fA-F]{2})?)$"

# Determine files to check: staged in Git, or all www/ files on manual execution
FILES_TO_CHECK=$(git diff --cached --name-only --diff-filter=ACM 2>/dev/null)

if [ -z "$FILES_TO_CHECK" ]; then
  FILES_TO_CHECK=$(find www -type f \( -name "*.css" -o -name "*.js" -o -name "*.html" \))
fi

EXIT_CODE=0
FOUND_ERRORS=0

for file in $FILES_TO_CHECK; do
  # Skip binary assets, fonts, audio files, and the check script itself
  if [[ "$file" =~ \.(png|webp|jpg|jpeg|svg|ico|ttf|woff|woff2|mp3|ogg|wav)$ ]] || [[ "$file" == "scripts/check_colors.sh" ]] || [[ ! -f "$file" ]]; then
    continue
  fi

  # Find all 3, 6, and 8-character HEX colors
  HEX_MATCHES=$(grep -onE "#[0-9a-fA-F]{3,8}\b" "$file" 2>/dev/null)

  if [ -n "$HEX_MATCHES" ]; then
    while IFS= read -r match; do
      LINE=$(echo "$match" | cut -d: -f1)
      HEX=$(echo "$match" | cut -d: -f2)
      HEX_LOWER=$(echo "$HEX" | tr '[:upper:]' '[:lower:]')

      # Validate against the allowed palette whitelist
      if ! echo "$HEX_LOWER" | grep -qE "$ALLOWED_PATTERN"; then
        echo "🚨 [STOP-LOSS] Unauthorized color '$HEX' in $file:$LINE"
        EXIT_CODE=1
        ((FOUND_ERRORS++))
      fi
    done <<< "$HEX_MATCHES"
  fi
done

if [ $EXIT_CODE -ne 0 ]; then
  echo ""
  echo "❌ COMMIT REJECTED! Found $FOUND_ERRORS unauthorized color values."
  echo "   NICHLYST strictly allows only 5 colors: #232626, #3E403F, #736758, #A69B8D, #BFB3A4."
  exit 1
fi

echo "✅ [COLOR-GUARD] All colors comply with the official NICHLYST palette."
exit 0

If I am tired and accidentally style a button with #FFF, the system physically rejects the commit. The system enforces the aesthetic when my brain cannot.

The Narrative Rewrite: Narrative Game Design — Why I Threw Away the Script a Month Before Release

A few days ago, I booted up the local server, clicked through the first three days, and felt nothing.

The engine worked perfectly. The resources depleted. The RevenueCat SDK integration was flawless (the paywall triggers exactly after Day 3). But the text was dry.

“Khoma arrives. He has evidence. Do you take it?”

If you are going to charge $4.99 for a narrative game — my entire indie game monetization strategy is that one honest purchase, no dark patterns — the text must react to the player's conscience. It cannot be a telegram. The player must feel like they are reading an elite, heavy book where they are the protagonist.

So, I rewrote the JSON schema and refactored the UI (DayScreen.js).

Instead of a single string, the engine now accepts a chapter_narrative array, breaking every day into four distinct phases:

Awakening: The somatic feeling of the basement. Cold concrete, heavy lungs.
Approach: The footsteps outside the blast door. The anxiety before the knock.
Encounter: The dialogue and the evidence.
Dilemma: The moral trap where there are no good options.

I updated the CSS to handle this like true typography. I added an isolated scrolling container, a cascading fade-in animation, and a drop-cap (::first-letter) to the opening paragraph so the text feels tactile and deliberate:

/* ─── Narrative Scroll Area (multi-paragraph chapter_narrative) ── */
.nl-narrative-scroll-area {
  flex: 1 1 auto;
  overflow-y: auto;
  max-height: calc(100vh - 290px);
  padding-right: 8px;
  margin-bottom: 1.25rem;
  scrollbar-width: thin;
  scrollbar-color: var(--c-3) var(--c-1);
  -webkit-overflow-scrolling: touch;
}

.nl-narrative-scroll-area::-webkit-scrollbar {
  width: 4px;
}
.nl-narrative-scroll-area::-webkit-scrollbar-track {
  background: var(--c-1);
}
.nl-narrative-scroll-area::-webkit-scrollbar-thumb {
  background: var(--c-3);
  border-radius: 2px;
}

/* ─── Narrative Paragraph (book typography) ──────────────────── */
.nl-narrative-paragraph {
  font-family: var(--font-serif, "Georgia", serif);
  font-size: 1.05rem;
  line-height: 1.7;
  color: var(--c-5);
  margin-bottom: 1.25rem;
  text-align: justify;
  opacity: 0;
  animation: nlParagraphFadeIn 0.35s ease forwards;
}

.nl-narrative-paragraph:nth-child(1) { animation-delay: 0.05s; }
.nl-narrative-paragraph:nth-child(2) { animation-delay: 0.15s; }
.nl-narrative-paragraph:nth-child(3) { animation-delay: 0.25s; }
.nl-narrative-paragraph:nth-child(4) { animation-delay: 0.35s; }
.nl-narrative-paragraph:nth-child(n+5) { animation-delay: 0.45s; }

/* Drop cap on the opening paragraph */
.nl-narrative-paragraph:first-of-type::first-letter {
  font-size: 2.6rem;
  line-height: 0.85;
  float: left;
  margin-right: 0.45rem;
  margin-top: 0.15rem;
  font-family: var(--font-serif, "Georgia", serif);
  color: var(--c-5);
  font-weight: bold;
}

@keyframes nlParagraphFadeIn {
  from { opacity: 0; transform: translateY(4px); }
  to { opacity: 1; transform: translateY(0); }
}

The engine now supports deep, multi-paragraph storytelling while gracefully falling back to old single-string descriptions for days I haven't rewritten yet.

Expanding the Dictionary of Despair

To ensure the new writing hits the exact psychological notes required, I expanded the game's internal game_data.json dictionaries. I added new tone keywords for the AI-assisted generation prompts:

Wave 4: chemical apathy, cognitive dissonance, claustrophobic giant.
Wave 6: telegraphic despair, spatial erasure, terminal apathy.
Wave 8: somatic overflow, phantom flora, sensory dissonance.

I also added a new piece of deep lore to the Codex: Directive 44. In the world of NICHLYST, the totalitarian Directorate has officially banned "vocal warmth" and empathy in speech as signs of psychological instability, punishable by ration forfeiture. This justifies the dry, brutal tone of the game's UI.

Securing the Perimeter (Via Negativa)

Marketing is not just about posting; it is about squatting. I spent one evening locking down the digital perimeter.

I registered the GitHub Organization, secured the domain koztechie.pp.ua (and deployed a blazing-fast Eleventy static hub onto Netlify), claimed @nichlyst on X, Instagram, TikTok, Bluesky, Threads, and Itch.io.

I also had "Create a subreddit" on my to-do list. But I looked at Reddit's current corporate ecosystem, the CAPTCHAs, the shadowbans, and the decay of the open web.

Aaron Swartz didn't fight for a closed corporate silo. I crossed the task off. NICHLYST is anti-Reddit. We rely on the open web, RSS, Dev.to, HackerNoon, and direct code. This is Taleb’s Via Negativa in action: removing the fragile elements to make the whole system stronger.

The 20-Tester Wall Remains

The game is structurally complete. The monetization is wired. The narrative is being rewritten into something profoundly heavy.

But Google Play’s bureaucratic wall still stands. I need 20 active testers to keep the app installed for 14 days, or I cannot launch on time for the Shipaton.

I currently have 15. I need 5 more.

If you are an Android user and want to help a developer who is pouring the last drops of his nervous system into this engine, please fill out this form. No heavy QA needed. Just accept the invite, install, and hold it on your phone.

👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

I am starting my day with a selective serotonin reuptake inhibitor (SSRI) and eight other pills or capsules differing in shape, color, size, and purpose, just to keep my body and nervous system functioning. But the engine breathes. The infrastructure holds.

The antifragile plan works. I'll see you at the finish line.

Follow this devlog for the #BuildInPublic journey toward the RevenueCat Shipaton 2026.

Building NICHLYST: Two Mugs, a Black Screen, and the Weekend the Engine Woke Up

Eugene Kozlovsky — Sun, 16 Aug 2026 13:46:07 +0000

A friend came by last Thursday and handed me a mug she had brought from Bulgaria. On the mug was a Kama Sutra position so acrobatic that gravity itself seemed ready to file a complaint. "So that there would be love," she said. It felt strangely appropriate: the thing on my desk that week was a half-asleep HTML5 game engine, and it was going to need exactly that kind of stubborn love to wake up.

I already own a hackathon mug. It says: "I participated in the world's largest hackathon and all I got was this mug." And what is written there is the honest truth.

That mug is my main one now. Every day I brew Assam in it, plus a soluble chicory-and-barley drink, and I sit with it through work and through my own projects. The project I received it for last summer no longer exists. I chose not to develop it, for reasons that deserve their own separate silence. But the mug stayed — as a reminder of what I was able to build once, and as a quiet, stubborn motivation to do it again.

The new mug won for pure practicality. Six hundred milliliters. When you spend your days holding other people's infrastructure together and your evenings turning a vision into prompts, you are always drinking something, and 600 ml is the right amount of continuity.

Projects die. Mugs survive. Objects outlive the work that made them. I keep thinking about that while I build a game about keeping records after everything else has burned.

By the morning of August 16th, the plan had quietly eaten steps 49 through 86. Let me explain.

The Audio Phase: ElevenLabs Sound Effects

The second devlog ended on a promise: the audio phase, then the engine. The audio came together first. I wrote the key voiceover lines and generated the voice — and then, without planning to, made a discovery: ElevenLabs also generates sound effects astonishingly well. The ambient layers and the small diegetic motifs of the game were born there too. I did not expect a voice tool to hand me wind, hum, and a door that creaks without moving. I normalized everything on my Xiaomi, committed, and backed the folder up before I allowed myself to feel satisfaction.

Vibe Coding Tools 2026: OpenCode vs Antigravity CLI

The engine needed a different kind of help. Until recently I vibe coded with Antigravity CLI, and it was extremely convenient — exactly as long as my paid Google subscription lasted. The moment the subscription ended, the limits became laughable. Less than thirty minutes of vibe coding, and the tank was empty. So I switched to OpenCode. Even unpaid, its limits are enough to actually work, and OpenCode vibe coding quickly became my default rhythm: open the terminal, describe the intent, review the diff, commit. On Saturday I opened it, and something clicked.

If you are compiling your own shortlist of the best vibe coding tools 2026, here is my field data from one weekend: Antigravity CLI is brilliant while the quota lasts, and OpenCode is the tool that keeps a solo dev walking when the quota dies. The winner of any comparison is not the smartest model — it is the one whose limits let you finish an evening session.

The Engine Wakes Up

What followed is hard to describe as a sequence, because it stopped being one. The plan's steps blurred into a single long evening and then another. A state manager that reads the frozen JSON and loads its initial truths from it. A persistence layer — autosave after every meaningful event, because a mobile game that loses your guilt when the OS kills the process is not a game, it's a scam. A renderer for the day screen. A pipeline that resolves choices and their delayed consequences. A parser that reads condition strings and picks an ending from the data. Transitions between narrative layers. A UI that slowly decays after the finale, the way the design document always promised it should.

Then the wiring: backgrounds, portraits, audio — everything the art pipeline had produced, connected to the machine. Every subsystem arrived with a checklist and at least one test scenario, because on a weak PC with a weak margin for error, "it seems to work" is not a status. Commits landed before 23:00. The 23:00 rule from the first devlog is still alive; some rules survive precisely because they are boring.

Thirty-eight game development milestones closed in one weekend. Three of them had to be closed twice. That ratio is the honest metric of solo development.

The Black Screen

Because here is what happened the first time I wired the art: the game launched and showed me a header, two buttons, and a black void where the narrative was supposed to be.

Diagnosis first, guess-fix never. The render pipeline was interrupting itself the moment an asset manifest request failed. And the manifest was a lie I had written: it expected file names I had invented, while the disk held file names the generator had invented. Two fictions that had never met.

The fix became a contract. The narrative renders even if every optional subsystem dies. Every fetch gets a catch. And the manifest is no longer written by hand — it is regenerated from the disk, because the disk is the only source of truth; anything the script can't recognize goes to a quarantine list, never into the game by guesswork. When I reloaded and heard the knock — cautious, irregular, exactly as designed — I sat still for a while. The JSON was no longer a document. It was a place.

Monday Is Coming

On Monday, rehabilitation begins. Three to four hours a day, including the road. I don't yet know the exact slot, which means the schedule has to absorb an unknown shape — again. My sessions with the psychologist are also coming to an end; one is left, and I caught myself grieving in advance for a structure that taught me to stand without structures.

This is what the war years do to a plan. Not always with sirens. Sometimes just with the slow accumulation of appointments, procedures, endings, and beginnings, while the city stays hot and the air stays loud enough to be a baseline. You don't get heroic days. You get days. The antifragile plan from the first devlog was written for exactly this: the schedule bends, it does not break. Rehabilitation goes into the calendar. The 23:00 rule stays. The mug travels to every desk I sit at.

The Tester Wall: Google Play 20 Testers, Almost Down

Since the second devlog, the tester form has grown to 14 emails. I need 6 more. That's it. That is the whole distance between me and the Google Play production track.

If you are reading this, have an Android device, and two minutes to spare:

👉 https://forms.gle/4hJkWsmuyKp3Tgtr8

Accept the invite later, install the app, keep it for 14 days. No deep QA. Just your presence to satisfy the algorithm.

What Comes Next

The engine breathes. Next is money and time: the RevenueCat SDK and the paywall, the push-notification architecture — the diegetic knocks that arrive hours after a choice — the demo video under two minutes, and a Codemagic build my testers can hold.

NICHLYST is coming. And now it remembers.

Follow this devlog for the #BuildInPublic journey.

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 for the RevenueCat Shipaton 2026. Diving deep into the heavy, emotional trenches of narrative game design, 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.

Instead of relying on a rigid game design document template, I wrote the initial script as a markdown document, then structured it directly 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: Surviving the Google Play 20 Testers Requirement

In my first post, I asked for help with this exact 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. If you are reading this while also grinding through the RevenueCat Shipaton 2026, you already know the unique pressure of shipping under extreme constraints.

I am not a traditional developer. I am a practitioner of vibe coding with AI. To me, this isn't just a buzzword; it's a philosophy of orchestrating AI. It’s the ability to translate a feeling, an idea, or a complex vision into a precise prompt for a machine. It’s about bringing 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 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. If you are constantly researching how to avoid scope creep, the secret is that the "middle ground" — medium-risk, medium-reward tasks — must be 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.

Developer Burnout Prevention

To survive a solo hackathon, I rely on a strict checklist to protect my mental bandwidth:

Hard stop at 23:00.
Sleep treated as a strategic investment.
Zero guilt on low-energy days.

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 a fellow builder figuring out how to get 20 testers for Google Play, I see your struggle. But right now, I need your help to bypass this bureaucratic wall. If you have an Android device and 2 minutes to spare, please take action:
👉 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.