DEV Community: Andrew Perepechay

Dashboards That Save You From Burnout and Despair, or How I Keep Building My Online Game

Andrew Perepechay — Tue, 21 Jul 2026 19:14:10 +0000

If it weren't for dashboards, I think I would have abandoned my product by now. It seems that's exactly how vibe-coded projects die.

(But mine isn't dead yet, so come and play.)

A product without users is like a plane without a pilot: cool, but useless

When building any product, even with AI, it's important to remember a simple thing: the most functionally impressive product without users is a waste of time, effort, and money. And the worst product that has paying users is already a successful product.

I set up dashboards so I wouldn't have to guess

To track the life of the product like a real product manager, I set up dashboards for metrics: retention, DAU, MAU, and a few more indicators. Technically, it's all built on events. The client sends a signal at every step of the player's journey: opened the site, entered a nickname, created or joined a lobby, started a game, finished it. The server aggregates this by day, and a separate admin panel turns the numbers into charts and a funnel. At one point the funnel showed more started games than players who entered the lobby. It turned out I was counting events, not unique players — and the same person could play several times a day. Now I try to make data-driven decisions, but without users and data it's still hard.

Dashboards save you from burnout

If it weren't for these charts, I think I would have abandoned the project already. But when you see that someone actually came in and played a game, you feel a surge of motivation.

I want to say a huge thank you to everyone who has already come in and played!

This will probably resonate with many people who are just starting their product. Even one real user feels completely different from a big abstract number in someone else's case study.

One request to those who played

If you played "Growing City," please write in the comments where you played from: at home, at work, on the subway. I have a hypothesis, but I can't test it without feedback. If I get enough answers, I'll definitely share what came of it in one of the next articles.

And if you haven't played yet, come to https://rastushiy-gorod.ru and give it a try — it's free and requires no registration.

The Story of How Claude Called a Task Impossible and Then Built It Himself

Andrew Perepechay — Sat, 18 Jul 2026 09:04:37 +0000

Recently I decided to rebuild the mobile version of my game "Growing City" (https://rastushiy-gorod.ru). I wanted more than a responsive version of the desktop interface — a full mobile game screen with convenient controls and a proper layout of the main elements. I asked Claude to help with the implementation, but got a fairly confident answer: a task like this can't really be done in Cursor, you need a developer.

"This can't be done in Cursor"

The problem was quite real. The game was originally designed for a large screen: the card market, player actions, and information about cities and participants all fit fine on a computer monitor, but on a phone this whole structure started falling apart.

The simplest path is to shrink everything down to the mobile screen. But that usually ends badly: tiny elements, awkward buttons, and the constant need to scroll.

A different approach was needed: a separate mobile layout with its own logic for arranging elements. A header with the key information, the card market, a player panel, an action block, working with swipes and fixed interface areas. Claude assessed this as full-blown mobile client development and concluded that it couldn't be done without an experienced developer.

Someone else's opinion turned out to be more useful than mine

Instead of wasting time arguing with the model, I opened ChatGPT and asked it to break the task down from an architectural angle: how best to organize the screen, which blocks to make independent, where to use fixed panels, how to handle mobile interaction. The result was a detailed implementation plan.

I simply copied it and sent it to Claude. Without extra explanations or attempts to convince it that the task was actually doable. Claude analyzed the proposed structure, suggested its own corrections, and started implementing. In the end I got exactly that architecture: separate interface blocks, a bottom action panel, gesture controls, and a screen designed specifically for a smartphone rather than just a shrunken computer version. In other words, a task that had literally just looked "too big for Cursor" turned into an ordinary development iteration.

Don't argue with AI — verify its answers

The most interesting takeaway here isn't that Claude was wrong. That's normal: the model doesn't see the whole project the way a developer does, and it evaluates a task based only on the available context. The problem starts when you treat such an answer as a final verdict. AI can misjudge complexity, miss another approach, or assume a task requires far more resources than it actually does.

In situations like these, it's better not to prove the model wrong but simply to get a second opinion and test the hypothesis in practice.

The mobile version of "Growing City" is already live at https://rastushiy-gorod.ru. I'd be glad to get feedback on the interface, the game mechanics, and ideas for attracting the first users.

And I'm curious: have you run into situations where AI first confidently said "this is impossible," and then, after you changed the approach, calmly solved the task? How often does that happen to you?

How I Rebuilt the Mobile Version of My Free Online Game in a Single Day

Andrew Perepechay — Sat, 18 Jul 2026 08:59:45 +0000

When I built my free online game "Growing City" (https://rastushiy-gorod.ru), it only existed as a desktop version. The MVP was put together in three days, and at that point it was more important to test the core game mechanics than to worry about adapting it for smartphones. But once it came time to promote the game, one thing became obvious: the lack of a proper mobile version was the project's weakest spot. Most users come from their phones, and playing on mobile was simply uncomfortable. So I decided not to limit myself to cosmetic fixes and to completely rebuild the interface.

Why you can't just shrink the desktop version

The first option seemed obvious: take the existing interface and adapt it with media queries. It quickly became clear that this wouldn't produce a game for phones, but a shrunken copy of the desktop site. Everything technically fits on the screen, but it's inconvenient to use: elements are too small, there's too much information, and important actions constantly require zooming or extra taps.

Instead, I rebuilt the very structure of the screen. Now the interface consists of independent blocks: the header, game progress, the card market, the player list, the action panel, and a bottom sheet. Each block adjusts itself to the available space rather than depending on the size of the whole screen.

I also dropped the endless set of breakpoints for different phone models. Instead of dozens of conditions like "if the width is 390 pixels, do this," there are now a few logical interface states and adaptive typography that scales smoothly between them.

It sounds fairly simple. In practice, it took several iterations before the system really started working reliably.

Why I had to remove the pretty icons

At the same time, I wanted to make card advantages more visual. I added small icons that were supposed to explain card effects: where bonuses apply, who they affect, how they impact money, and what happens after a card is played. I thought it would become a small visual language that would let players read information faster. But after the first tests it turned out that almost no one understood these icons.

The only exception was the money bag — it had long been used in the interface, so players recognized its meaning without fail. All the other icons only slowed the game down. During a match no one wants to figure out symbols — a player needs to make a decision quickly. In the end I removed most of the icons.

Instead, I rewrote the effect descriptions. I didn't just shorten the text — I reworded each description so it could be read completely in a second, with no cut-off phrases or hidden continuations.

One bug I had to fix four times

The most stubborn one was a bug with the market cards. First, empty space appeared under the grid; after fixing that, the cards unexpectedly collapsed to nearly zero height. Then the problem came back again.

At some point I stopped trusting messages like "done" and started looking only at concrete values: the container height, the content height, and the difference between them. Once real numbers replaced descriptions, the cause showed up almost immediately. Sometimes the best way to find a bug is to stop discussing it in words and look at the data.

What came out of it

Now "Growing City" is comfortable to play from a phone. There's a separate mobile layout, the bottom sheet works with familiar gestures, and the city-building progress is always in front of you rather than hidden behind extra taps.

Of course, the interface work can't be considered finished. Any browser game keeps changing after the first users show up. But now it really is a mobile version of the game, not just a squeezed desktop page.

On the same day, I also managed to deal with the site being blocked for some users at the provider level. That story turned out to be unexpectedly interesting — I'll tell it in the next article.

If you have a couple of minutes, I'd be glad if you tried the free online game "Growing City" (https://rastushiy-gorod.ru) on your phone and wrote what works well and what still needs improvement. I really do read every piece of feedback — it's thanks to comments like these that the game gets better.

I Looked at My Game's Stats and Realized People Almost Can't Beat the Bots

Andrew Perepechay — Sun, 05 Jul 2026 20:15:15 +0000

Quick disclaimer: nothing is rigged. Bots don't get lucky dice rolls and have no hidden advantages. Everything available to a human is available to a bot, and vice versa.

Players Only Win 25% of Matches

I recently looked at the stats for every game played and stumbled on a number that surprised me: real players win only 25% of matches.

When I wrote the bot logic, I never expected this outcome. They were meant to fill empty lobby slots and give people a chance to practice before playing against humans, not to become the final boss.

Either the bots play noticeably better than I thought during development, or people are making far less optimal decisions than I assumed.

If you want to test yourself, the game lives here: rastushiy-gorod.ru. It'll be interesting to see whether you can improve humanity's overall stats.

Why I'm Not Adding Difficulty Levels Yet

My first thought, of course, was to add a difficulty selector. But the more I think about it, the less I like the idea.

This isn't a shooter where you can just lower the enemy's aim accuracy. In an economic card game, almost all the difficulty comes from decision-making. I want the bot to play honestly, and for players to beat it by understanding the game and building a strategy, not because the developer deliberately made it dumber.

How I Even Found This Out

I recently rebuilt the analytics dashboard from scratch. Before, it mostly answered questions about the game itself: which cards get picked more often, which modes are more popular, and so on.

It turned out to be far more interesting to look at the players: who wins, who loses, how many matches people play, where people drop off. Sometimes a single number tells you more about a product than a hundred of the developer's own impressions.

I'm planning to write a separate article about the dashboard itself. If you have questions, leave them in the comments, I'll address them in one of the next articles.

Now There's a Different Problem

Most matches right now are one human plus several bots. When I first designed the game, I pictured it very differently. I wanted people to play against each other, with bots simply filling out the roster.

In practice, a lot of people just start a game with bots.

No matter how good the bots are, they're still bots. After a while their style becomes predictable, and the game gets less exciting. The real fun starts when you play with friends or random players, that's the experience I ultimately want to deliver.

The game is still live at rastushiy-gorod.ru. If you play and beat a bot, consider it your personal contribution to a stat that currently isn't looking great for humanity.

As always, I'm collecting feedback and would love to read your comments.

How I Started Attracting International Players to My Game With AI Automation

Andrew Perepechay — Sat, 04 Jul 2026 23:07:42 +0000

In previous articles, I wrote about how I built a browser-based city-building game called "Growing City" in three days using AI, and then how I spent a couple of weeks polishing the lobby, bots, and interface. This time, I want to talk about something that could genuinely help a lot of people on the market.

A Game That Doesn't Care Who's Playing

An economic city-building board game isn't tied to any particular region. The rules are exactly the same whether you're in Moscow, Madrid, or New York: roll the dice, build something, outplay your opponents. There's nothing in the mechanics themselves that only works for one audience.

And yet the site was only available in one language. Not because I decided that on purpose — simply because when you're putting together an MVP in three days, you're not thinking about a three-language interface, you're thinking about making the thing work at all. But it started to feel wasteful to artificially cut off part of my audience with a language barrier that the game itself doesn't actually have.

Translating Isn't the Hard Part. It's Genuinely the Easiest Part

Here's what I did on the technical side, briefly: every piece of interface text got moved into separate dictionary files — one for Russian, one for English, one for Spanish — all sharing the same set of keys. A "Buy" button isn't text hardcoded into the code; it's a key that gets swapped depending on the selected language. I also had to separate the card names the player sees (translatable) from the internal names the game engine uses for logic (which must never change). Otherwise, translating the interface would have quietly broken the game itself.

The neat part was how I handled the default language. There's no need to ask the user anything on their first visit — the browser already knows what language the person's system is set to. Someone arrives with a Spanish OS, and the interface is instantly in Spanish, no extra click required. And if they manually switch the language afterward, that choice is remembered and never gets silently overwritten again.

The Real Surprise: Not the Translation, But Everything Around It

Writing an article isn't hard. Translating it into English and Spanish isn't hard either — that's literally one prompt. But after that comes exactly what I described in my first article: the difficulty shifts away from code and onto everything surrounding the product.

Publishing an article across a dozen different platforms for different audiences used to mean manually opening every single site, pasting in the text, and adjusting the headline to fit each community's format. Honestly, that routine was eating me alive — the kind of repetitive work you'd love to avoid entirely.

That's where Claude for Chrome came in. It's a browser extension that can see the page in front of it and click, fill out forms, and publish content on its own. I just handed it a link to a finished article and asked it to post it to public platforms. Done — it was already live. Literally one prompt and about ten minutes, and the article was sitting on international platforms, kind of like this one (happy to write up the exact steps if anyone's curious — it's genuinely simple).

What's Next

The game is still live at rastushiy-gorod.ru, now available in Russian, English, and Spanish depending on who's visiting. No registration required — you can play with friends, against bots, or get matched with a total stranger from the other side of the world in the same open lobby.

International players have already started showing up. It's too early to draw conclusions, but I'll share numbers and early observations in the next article.

As always, I'm collecting feedback and would love to hear your thoughts in the comments.

I Launched an AI-Built Board Game — Here's What Happened Next

Andrew Perepechay — Thu, 02 Jul 2026 18:36:40 +0000

Not long ago I wrote about how I built a browser-based board game called "Growing City" in three days using AI — and how the hardest part wasn't the code at all. Some time has passed, and I wanted to share what happened next.

Layout Bugs

While vibe-coding solo, I only tested on my own screen, resolution, and browser. The problem surfaced as soon as real users joined with different setups: some people saw everything misaligned, some things got clipped, some cards overlapped each other.

This is how it looked on some screens

I had to rewrite the layout to use adaptive sizing so the game looks correct regardless of screen resolution. It should work now — but if something still looks off on your end, let me know and I'll fix it.

Bots Started Talking

Another change, unrelated to bugs. The service started feeling more alive. Previously, bots just played: rolled dice, bought cards, said nothing. Now they react in the chat to what's happening in the game — if someone's building gets taken, if someone buys an expensive card or runs out of money.

It's a small thing, but the game feels noticeably more lively. An empty game with silent bots versus a session where someone's commenting on what's happening in chat — it's a meaningfully different experience, even though the game itself is the same.

Thank You to Early Players

A special thanks to everyone who tried the game after my first article.

And extra thanks to a user with the nickname SHAM, who pointed out that the game rules never said you can't buy multiple purple cards in a row — even though the game itself has that restriction. Fixed!

What's Next

The project is still going. I'm thinking about ads and other ways to bring in players. Without new users, it's hard to get feedback — and without feedback, it's hard to know what to fix or improve first.

The unit economics don't quite work out yet: paid acquisition costs more than I'm willing to invest at this stage. I'll keep figuring it out. If you have ideas on how to find players for a project like this, I'd genuinely love to hear them.

Want to Play?

The game is still live at rastushiy-gorod.ru. No registration needed.

Same as before — all feedback gets read and used. That's how the project keeps moving forward.

I Built a Board Game in 3 Days with AI — and Realized Code Was the Easiest Part

Andrew Perepechay — Thu, 02 Jul 2026 18:34:06 +0000

I love board games — especially the kind you can play without leaving home. You just call your friends, drop a link, and you're playing in minutes. At some point, I caught myself wondering: how realistic is it to build a complete game almost entirely with AI? Not a prototype, but something actually playable. I decided to find out.

Three days later, I had a working browser-based board game: rooms, multiplayer, bots, chat, full game sessions.

But the most interesting thing turned out to have nothing to do with AI writing code.

What's the Game?

The game is called "Growing City" (Растущий город). It's an economic board game about developing your own city. Each turn, players roll a die, buildings activate, income flows in, and you earn money to buy new structures. Gradually you build up enterprises, construct your economic engine, and race to complete all the key buildings before your opponents.

You can play directly in the browser with no registration. I wanted the simplest possible entry: open the site, enter a nickname, create or join a room.

If the mechanics seem familiar — you're not imagining it. I was inspired by a well-known city-building board game.

Day 1: AI Really Can Write Games

I'm not a developer. I work in tech, but I don't code professionally. Over the past few months I've been experimenting heavily with vibe coding, so I decided to build this project the same way.

I didn't start with code at all. First, I wrote out the mechanics in detail: what cards exist, how a turn plays out, what should happen in each situation. Once the logic settled, I started gradually converting the description into code using AI.

Day 2: Writing the Game Was Just the Beginning

When the first playable version appeared, it quickly became clear that the code was far from the hardest part. The biggest problem was balance.

If you leave everything as-is, players find the single most profitable strategy within a few games and repeat it endlessly. I had to manually tweak card costs, adjust activation probabilities, revisit effects, and examine how different buildings interact. And here, AI doesn't really help.

It can suggest ideas, it can rewrite code — but whether the game actually becomes more fun after changing one number is something only a human can judge. I ended up spending more time on balance than on the initial working version of the game.

Day 3: Infrastructure Hurt More Than the Code

Once the game worked locally, all that was left was the "easy part" — deploying it to a server. How wrong I was.

SSH, Node.js, PM2, Nginx, SSL, domains... and a bunch of other unfamiliar words.

I started with the cheapest VPS. Then I ran an AI agent directly on the server, editing code and deploying changes in real time. Predictable result: the server kept crashing.

The lesson that followed was obvious in hindsight: developing directly on production, especially on a minimal VPS, is a bad idea. Sometimes the most useful lessons are the most basic ones.

The Unexpected Conclusion

When I started the project, I was sure the hard part would be writing the game. In practice, it was the opposite. Within a few days, I had a working product.

Friends played it, found bugs, we fixed things and tweaked others. Then came the question AI handles much worse: where do you find players? Code is easy to verify — either it works or it doesn't. Building an audience is a completely different challenge.

Code has become much more accessible. You can ship an MVP very fast, especially if you're good at working with AI. But after that, a completely different kind of work begins.

You need to find your first users, collect feedback, retain players, understand why they return or don't. And AI can't do that for you.

This seems to be the key bottleneck for most vibe-coded projects right now.

Want to Try It?

The game is live at rastushiy-gorod.ru. No registration needed — just open it, create a room, and start playing. Solo against bots or with friends.

If you give it a try, I'd really appreciate any feedback. Two things I'm most curious about:

Was it clear what to do without digging into the rules?
Did you find a strategy that breaks the balance?

I read every comment and keep iterating on the game. That's how the project is developing right now.