Diploma and thoughts on dapps

As you may know, I've been intensively writing my diploma for the last couple of weeks. Of course, right before the deadline. Actually, the last week was a huge mess.

The point was to develop software that enables paid subscriptions for Telegram channels. Moreover, the solution had to be as decentralized as possible. To put it simply, there shouldn't be one point of failure, and users should be able to transfer tokens back and forth without the involvement of a third party. Another requirement was a usage of some stablecoin instead of highly volatile token.

With this in mind I've digged into blockchain technology. The final solution consists of four components:

1. Smart-contract (solidity/brownie/python/pytest) that acts as a database and stores all the logic. Source code is right here.

2. Telegram bot (python/python-telegram-bot/web3.py) that acts as an admin in provided channels adding/removing subscribers. It also helps to verify a user and added channels. Moreover, bot can retrieve an information from smart-contract.

3. Frontend (dart/flutter/flutter_web3) that integrates with Metamask and aims to interact with smart-contract. It has to be here, so users can sign transactions with their private keys and pay a small commission for every transaction that changes state.

4. Script (python, web3.py, cron) that triggers the payment process for debtors (runs daily).

Here are some of the insights and conclusions I came to during the research and development process:

- Transactions that aim to change the state of smart-contract are not free. These transactions require gas. Gas is like a fuel that allows Ethereum network to operate. Gas price measures in ETH. At the time I was testing the interaction with the smart-contract, each transaction cost me about 0.3$. Happily, I was testing it on Rinkeby testnet, where you can get some ETH for free.

- Many apps that claim that they are dapps are at best only half dapps. Fully decentralized solutions shouldn't depend on centralized servers or databases. My solution can't be fully decentralized as Telegram is a centralized software. On top of that, I can't give a bot token to everyone, so they can do whatever they want.

- If some dapp asks you to approve spending of a large number of tokens, claiming it'll improve user experience, don't go along with it. Even if contract is open sourced. If there is a hole in smart-contract, all approved tokens could disappear forever.

- It follows from the previous point that the contract must be covered by tests up and down.

- Solidity isn't really cool. I had to store an array of user addresses for a mapping that maps user address to user structure only to be able to iterate through users. I've also couldn't find any utility methods for arrays/strings/mappings. How to live without generics?!

- One authoritive HR said that large companies, during the recruitment process, look through developer's CV and make a note when they see cryptoprojects in the experience section. It may show that money is more important for a developer than solving complex problems.

#crypto #blockchain #dev #thoughts

Be willing to learn

One day we've all written suboptimal code. Maybe it lacked decomposition, maybe there was some misleading naming, or the code was ready to blow up on the first edge case. It usually happens due to a lack of experience. And it is totally fine. What's not fine is when a developer continuously writes this code, applying bad practices to every project he/she touches without thinking something's wrong.

In such a case, every party suffers. The company spends more hours fixing bugs and adding new features. Moreover, other devs may not understand the code if the guy suddenly disappears. The product owner gets a buggy product with vague development prospects. The developer has fewer opportunities to find another good job if the recruitment process is done right during the tech interview.

There might be several reasons for this:
- Developer has never seen good code, and nobody has ever reviewed his/her projects, so a developer doesn't know what good code feels and looks like
- Developer doesn't want to learn new stuff and try something unknown

The first scenario is not that bad. You can always ask your more experienced colleague or some senior dev from the community to review your project. I'm always happy to help and share my approaches with anybody from the community if it'd make their life a bit easier and code - more maintainable.

The second scenario is much worse, but I can understand these people. If you're a freelancer or your company is satisfied with your work, and you're comfortable with your code, then there is no reason to change anything until something blows up (which will be an unpleasant surprise for all parties mentioned above).

So what's the point?
The point is that it doesn't work this way in our industry. If you want to evolve as a developer to have more career opportunities to work on something that matters to you and millions of people => you should always look for ways to improve your practices and make the development process more predictable.

At some point, being “just a mobile developer” stopped feeling like enough.

I’ve been a Flutter mobile developer for the last 5 years, and eventually I hit that familiar feeling: plateau. I’ve always believed that constant professional growth is mandatory, but I started questioning where that growth should go next.

Native mobile? iOS / Android? Honestly, it feels like more of the same. For Flutter, knowing how to write your own plugins already covers most real needs. I don’t want to switch to native. It feels too narrow.
Also, I still don’t fully understand why two separate teams often build the same app for different platforms, when a huge amount of code can be reused. I get that sometimes there’s a massive legacy codebase that’s hard to rewrite once and for all, or companies simply can’t find a strong cross-platform team — but still, it feels inefficient.

Then there’s backend. For a long time I thought: why do I need it as a mobile developer? There was simply nowhere to apply it in my daily work.

There’s also the management side. I’ve been a team lead for the last couple of years, and I’ve already developed some management skills — communication, planning, responsibility for delivery. But if I’m honest, my focus is still much more on the technical side.

About 1.5 years ago a new thought appeared:
What if the next step is becoming a CTO of a product I actually care about?
That role gives you much more influence, responsibility, and yes — better money. But let’s be honest: if you only know mobile, becoming a CTO is extremely hard.

Even though I graduated as a software engineer and almost started my career as a Python backend developer, I realized how many gaps I had:

• deployment & infrastructure
• databases (real-world usage, not just theory)
• message brokers, microservices, system design

And then the last year happened.

Chatbots, vibe-coding, agentic coding — this wave hit me like a real wake-up call. Suddenly, improving my skills wasn’t optional anymore. At the same time, these tools made learning backend much more accessible and faster.

So here’s my current plan:

1. Go deep into modern AI tools and solutions — maximum level. I’ve got serious FOMO here I need to get rid of.
2. Build pet project, read books, watch conferences, talk to other developers to grow solid backend skills.

My backend stack right now: Python + FastAPI.
Let’s see where this road leads 🚀

PS. This post was approved by ChatGPT

How my LLM coding subscriptions escalated

It started very innocently.

1. Free ChatGPT
Back then it was already called vibecoding, but I still didn’t really believe in LLMs for real coding tasks.
I mostly used it instead of Google. A bit more advanced Google.

I clearly remember questions like:

"Our designer has an animation idea (attached file) — what’s the best way to implement this in Flutter?”

Useful, but very exploratory. No real trust yet.

2. ChatGPT Plus ($20, on my girlfriend’s account)
I still didn’t fully trust GPT to write code for me.
But the Pro subscription helped in a different way:

– longer conversations
– architectural discussions
– switching between models and access to latest models
– sanity-checking ideas

It felt more like a whiteboard discussion than coding assistance.

3. Free Cursor (≈ 1 month)
Copy-pasting from ChatGPT into my project got annoying very fast.
Most real tasks need context across multiple files.

I was already coding in VS Code anyway, so Cursor felt like a smart wrapper on top of my usual workflow, not a completely new tool.

I mostly used Cursor via tab completion — it honestly felt like it was reading my mind.
Occasionally I asked the side-panel agent questions, but not that often.

4. Cursor Pro ($20)
The free tier wasn’t enough anymore:

– small request limits
– even tab completion stops working after some time

I stayed on it for a few months and slowly adapted.
More and more routine tasks moved to the agent.

I learned about rules, connected MCPs (Figma MCP is 🔥 for frontend).
Cursor also kept adding bonus credits — roughly +$80–90 on top of a single monthly subscription.

I still mostly used it for routine tasks — cases where:
– everything is clear
– I can quickly validate the result
– and fix things manually if needed

5. Cursor $20 + Claude Code $20
I kept hitting Cursor’s limits and decided to try the already hyped Claude Code in parallel.

I had heard about skills and sub-agents, but never really touched them (now they are also available in latest Cursor version).
I spent ~45 minutes experimenting non-stop, building my first custom skill... and hit the 5-hour limit before it was even ready.
Opus 4.5, thinking mode.

Pain.
Sadness.
Now what?

6. Cursor $20 + Claude Code $100
Relatively recently, I upgraded to the 10× Claude Code plan.

If you want to actually experiment with agents, sub-agents, skills, and hooks — iterate, break things, rebuild — upgrading the subscription starts to make sense.

My current setup:
– simple tasks → Cursor (with composer-1). Works surprisingly well.
– more complex tasks → Claude Code (Sonnet 4.5 or Opus 4.5)

What is your setup?

AI can ship your UI faster — unless your Figma is chaos

Implementing mobile layouts is boring work. You're essentially a human compiler — copying padding values, font sizes, and color codes from Figma to your IDE. No creativity, no challenge, just routine.

I tried using Cursor with design screenshots. It would generate something similar, but never accurate enough:

- Inconsistent spacing values
- Wrong font sizes and weights
- Slightly off colors (`#2A2A2A` instead of `#1F1F1F`)
- Design icons replaced with similar ones from MaterialIcons

Then I discovered Figma MCP and everything changed.

Yes, it costs €12/month, but it's worth every cent.

Figma MCP is a bridge between Figma and your coding agent. It provides tools that allow the agent to extract actual design data — variables, styles, and metadata from selected frames. It also provides screenshots so the agent can understand the visual semantics. Combined, the agent gets both the precise design tokens and the visual context.

The results are significantly better.

But here's the critical part — and this is where most setups fail:

The designer must follow atomic design principles

Your designer needs to:

1. Create design tokens (atoms) — colors, fonts, spacings as variables
2. Build components (molecules) from these tokens
3. Compose screens from these components

Think of it as a proper design system hierarchy.

My workflow

As a Flutter developer, I use the AI agent with Figma MCP for the entire process:

1. Tokens → AppTheme
The agent generates color tokens (like primary500, error300`), typography (`heading1, body2`), and spacing (`spacing8, `spacing16`) with matching names from Figma.

2. Components → Reusable widgets
The agent creates Flutter widgets using these tokens.

3. Screens → Complete layouts
I feed the agent context: “tokens are in AppTheme class, components are in `lib/src/core/uikit`” or use a custom skill, and it generates screens using the existing code structure.

The key is naming consistency. When Figma tokens and Flutter code use identical names, the agent can reference them correctly.

Is it pixel-perfect?

No. I still need to review the generated code and make adjustments.

There's a way to make it more reliable using Flutter golden tests — the agent generates a component, compares it to the Figma screenshot, and if pixels don't match, it fixes the code and compares again. But this feels like overengineering for now. The feedback cycle can take too long for simple components.

Manual review is faster.

Garbage in, garbage out

I'm fortunate that my girlfriend creates proper design systems with clean component structure and consistent tokens. This saves me hours of manual implementation.

But I've worked with many designers who focus only on visual appeal without considering implementation. Their Figma files have random spacing values, inconsistent colors, and “components” that aren't actually reusable.

These designs look good but don't generate good code.

TL;DR

This approach eliminates the tedious part of mobile development. But it requires structured design files, not just pretty mockups.

Good design systems are the difference between AI generating production-ready code and AI generating something you'll need to fix manually anyway.

The question I ask at every interview

Once, at one of my first interviews for a mobile dev position, I was asked: what does "good code" mean to you? Since then, I often ask candidates the same question at the end of interviews. Not to evaluate — more out of curiosity.

The answer is almost always the same: readable, extensible, testable. SOLID, DRY, clean architecture. Juniors, mids, seniors — almost everyone says the same thing.

I used to think the same way. I'd agonize over layer structure, debate patterns, refactor before the feature even worked. It felt like the "right" way to code.
Now, with more experience, architecture just happens. You set up a foundation, work within it, adjust as you go. You don't overthink — you just know what fits. And once that's no longer something you struggle with, the real question surfaces: how fast can I deliver this feature? Not "is this abstraction elegant enough" but "is this in prod and solving the user's problem."

AI is reinforcing this mindset. An LLM can understand your codebase and write new code within its patterns. The architecture doesn't suffer — but the delivery speed multiplies.

That said — in real production work, AI doesn't magically make everything 10x faster. The bottleneck was never really the code itself. It's communication: unclear requirements, waiting for designs, going back and forth with the client. AI eliminates the slowest part of coding, but it exposes what was always the real problem — everything around the code. Which only reinforces my point: obsessing over code perfection was always misplaced energy. But that's a topic for another post.

So if someone asked me that same interview question today, I'd answer: good code is code that solved the problem, reached the user, and did it on time. Cleanliness is a means, not an end.

A while back I started diving into system design.

I got curious about how large-scale modern systems work, how and why their architecture is shaped the way it is. Decided to step outside the mobile dev bubble (wrote about that in my previous post).

I love learning and consume a ton of educational content now: books, conference talks, articles, all mixed together. But what really clicks for me is smart people who explain complex things simply.

So here are 3 lectures I want to recommend: Oleg Bunin's talks from HighLoad++ 2017 (1, 2, 3) as a solid foundation for system design. He walks through different approaches to scaling high-load systems one by one, then gradually moves into practice. Sure, some things are dated by now, but the fundamentals hold up.

I know that at least some of my friends who are really cool engineers are reading this. If you know similar resources that explain system design in a clear way, please share, I'd really appreciate it 🙏

Fun fact: back then (in 2017) VK had only about 20 developers 🫡