There’s a specific kind of dissatisfaction that’s hard to name when you’re in the middle of it. It’s not burnout, I’ve had burnout, I know what that feels like. It’s not boredom either. It’s more like… you’ve been very good at a thing for a long time, and one day you realize the thing itself has stopped being enough.
I’ve been sitting with this feeling for most of 2024. And I think I finally understand what it is.
I don’t want to just design anymore. I want to build.
Five years is a long time to stare at the same product
I joined VALK in November 2019. I was 23, fresh out of agency work in Moscow, excited to go deep on a single product after years of jumping between clients every few weeks. The fintech world was new to me, I didn’t know the difference between a cap table and a spreadsheet, and asset tokenization sounded like science fiction.
Five years later, I understand institutional capital markets well enough to have real opinions about them. I’ve designed and redesigned the same core flows so many times I can sketch the investor onboarding funnel from memory. I watched the product grow from basic deal management into white-label infrastructure for 70+ financial institutions. I’ve seen us launch Merlin, watched it grow, watched it pivot, watched everything pivot eventually.
And somewhere in all of that, something shifted in me.
The honest version: I’ve spent years designing features that then went through a long, complicated relay, me to engineers, engineers to staging, staging to QA, QA back to engineers, then eventually to production, and what shipped was rarely exactly what I had built in Figma. Not always worse. Sometimes different in ways that were actually fine. But always different. And the gap between the thing I made and the thing that existed in the world kept accumulating, specification by specification, interaction by interaction.
At some point that gap stopped feeling like a normal part of the process and started feeling like a fundamental limitation of my role.
The Merlin Christmas thing changed something
In late 2022 we did a holiday campaign for Merlin, an NFT project, conceptually simple, but requiring actual frontend work and a smart contract. Dev resources weren’t there to execute it. I ended up doing it myself.
I built the frontend. I wrote the smart contract. It shipped.
I’m not going to pretend I suddenly became a senior engineer from that experience. There was a lot of documentation reading, a lot of trial and error, a lot of moments where I genuinely wasn’t sure what I was doing. But it worked. Real users interacted with something I had built end-to-end, not just designed.
That feeling was categorically different from shipping a design.
When you design something, you’re always an intermediary. Someone else has to interpret your decisions, implement your choices, handle the edge cases you may or may not have anticipated. You’re producing instructions, not the thing itself. When I built the Merlin campaign myself, there was no translation layer. My decision, my implementation, directly in the world.
That directness was addictive.
I started paying more attention to the code that lived alongside my designs. Reading pull requests. Asking our frontend engineers more specific questions, not just “can we do this?” but “how would you do this, and what would make it easier?” I started learning things I had no immediate professional use for, just because I was curious.
The “designer who can build” conversation is getting old
There’s been a long-running discussion in design about whether designers should code. It’s produced a lot of hot takes and not a lot of clarity. I’ve held multiple positions on this over the years.
At the agency, I thought it was mostly theoretical. Work was moving too fast for technical depth to matter, what mattered was producing good concepts quickly. At VALK, working on the same codebase for years and sitting in the same engineering conversations repeatedly, the practical argument became harder to ignore.
The designers I admired most weren’t the ones with the cleanest component libraries or the most beautiful interactions in Figma. They were the ones who could sit down with an engineer and say “I understand why this is technically complicated, so let’s find an approach that gives us 80% of the experience with 20% of the engineering cost.” That’s a conversation you can only have if you understand both sides.
I’ve gotten better at the engineering side through necessity, five years in a small team will do that, but I’ve never fully crossed over. I want to cross over.
Not to stop designing. Design thinking, the way of looking at problems, understanding what a user actually needs versus what they say they need, that doesn’t leave you. It becomes part of how you see everything. I don’t think I could turn that off if I tried.
But I want the output to be something I built, not just something I handed off.
The ceiling that comes with being the only designer
There’s a specific plateau that happens when you’re a solo designer at a company for long enough. You get extremely good at reading the organization, at knowing what’s possible, at speaking the language of every stakeholder. You become efficient in ways that are invisible, you stop designing things that will never get prioritized, you pre-negotiate constraints before they become conflicts, you develop a kind of institutional intelligence about the product.
Genuinely valuable. Also a trap.
Because the same familiarity that makes you efficient starts to limit what you’re able to imagine. You know too much about what won’t work. You’ve heard too many reasons why something is complicated. You start designing within the organization’s constraints before you’ve even explored what’s actually possible.
I noticed this in myself over the past year. I’d open a new design problem and my first instinct was already filtered, not by what would be best for the user, but by what I knew about the current architecture, the current team capacity, the current company priorities. That instinct was usually pragmatically correct. But it meant I had stopped designing at the edges of what was possible.
That’s the ceiling. And I don’t think you can break through it by staying in the same place.
Looking at the whole arc
I started freelancing at 14. Designing logos and WordPress themes for small clients in Russia, learning everything from forums and tutorials, figuring out what worked by watching what people responded to. By 19 I was doing professional UX work. By 22 I was lead designer at an agency in Moscow, running design on 50+ projects, working with companies like Kaspersky and OTPBank.
When I joined VALK at 23 I thought I was stepping into the next chapter, and I was. But looking at the arc now, I can see a pattern: I’ve always moved forward by expanding what I do, not just getting better at a narrower thing.
Freelance to agency wasn’t just a change in scale. It was a different kind of work, different relationships, different skills. Agency to product design wasn’t just a slower pace, it required learning to care about a single product deeply, to think in systems instead of sprints. Each transition felt uncomfortable and slightly too ambitious at the time, and obvious in retrospect.
I think I’m at another one of those moments.
What the next version looks like (I don’t entirely know yet)
I’ll be honest: I don’t have a fully formed plan. I’m still inside the thing, still at VALK, still doing my job, and thinking about what comes next mostly in the early mornings before work or late at night when I should probably be sleeping.
What I know is that I want to spend more time building and less time describing what should be built. I want to be in environments where the gap between design and implementation is smaller, either because I’m doing both, or because the team structure makes that gap less of an obstacle. Work on problems where my understanding of how to make things look and feel useful still matters, but where I’m not the last person before handoff.
I’ve been playing with development tools more seriously over the past year. Not to become an engineer, the learning curve is steep and I respect what proper engineers do too much to claim their title after a few months of experimentation. But to understand enough to participate differently. To be less of an instruction-giver and more of a collaborator who can sit alongside the code.
The role of “designer who only designs” is compressing. The purely pixel-pushing role, the person who exists only to produce Figma files for others to implement, that’s a narrower and narrower space to occupy. The designers who are staying actually relevant, not just employed, are the ones who understand the systems they’re designing for.
I’ve always been more systems-oriented than aesthetics-oriented. I care about how the thing works more than how it looks, even though making it look right matters enormously to me. That instinct might translate well.
What VALK gave me that I didn’t expect
I want to be clear about something: I’m not leaving frustrated. I’m leaving having learned more than I thought was possible in a single job.
I learned an entire industry. I went from not understanding what a data room was to having genuine opinions about how institutional investors think about risk. I designed for users who manage billions of dollars of capital, and I had to think carefully about what trust means at that scale, what makes someone comfortable committing to a transaction in a product you built.
I learned to work without much structure. Small team, enormous scope, constantly changing priorities. You either develop judgment quickly or you produce the wrong things. I developed judgment.
And I learned that the thing I designed and the thing that shipped will never be identical, and that’s not a failure, it’s the nature of collaborative work. But the closer I can get to the implementation, the smaller that gap becomes.
I’m grateful for all of it. Genuinely.
On writing this blog for four years
I started kargaev. me as a personal outlet. Somewhere to think through problems out loud, to process what I was learning, to write for an audience of roughly zero and occasionally be surprised that someone found it useful.
I’ve been inconsistent. Months where I published nothing, months where I wrote three things in a week. The quality varies. Some of the early posts I reread now and notice the awkward phrasing, the grammatical choices that give away that English is my second language, the slightly over-formal tone of someone writing in their non-native tongue.
But I kept writing. Because the act of trying to explain something forces you to understand it better. And because every so often someone would send a message saying a post helped them think through something they were struggling with, and that was enough to keep going.
I don’t know exactly what the next chapter is yet. I know it involves building more and designing differently, and figuring out what I want to do with everything I’ve accumulated over the past decade.
I’ll probably write about it.
Originally published on kargaev.me. Imported to blog.deeflect.com archive.