Dee's Blog · Notes from a designer-engineer in LA

I was a half-builder

Thu, 07 May 2026 00:00:00 GMT

I have thirteen public repositories on GitHub.

Three of them are real products.

The rest are half-shipped: interesting starts, side-quests, idea-shaped objects with a README and a pushed_at date and not much past it. Universal-codemode: clean idea, two demos, no users I can name. Vasted: works on my machine, never advertised, never used by anyone who isn't me. Smart-spawn: model router, never wired into anything I run daily. Mcclaw: Mac LLM checker, fun side build, abandoned at v0.2. Moltedin: a marketplace I sketched and walked away from. Lobster-tools. Tldr-club. Clawbot-blog.

I built fast. I shipped half. I posted screenshots.

That's the dominant mode on AI-builder X right now and I want to write the post about it as someone caught inside it, not above it.

The Builder.ai version

The loud version of this is Builder.ai.

The pitch was an AI named Natasha that built apps from a single sentence. Microsoft believed it. SoftBank's DeepCore believed it. The Qatar Investment Authority believed it. About $450M of capital believed it.

Behind the AI: 700 human engineers in India and Eastern Europe.

By 2024 the investigations had landed. Bloomberg. WSJ. The Information. By May 2025 the company was filing for insolvency, Microsoft and the creditors were inside the building, and "Builder.ai" had become culture-wide shorthand for AI-washing. Strap "AI" to a labor product, raise nine figures, ride the cycle until the cycle catches up.

That's the loud version of the pattern.

The quiet version is on your X feed every day, and it's not committing fraud. It's people shipping the half they can ship and calling it the whole. That's what I've been doing.

What a half-builder actually is

Tighter than "doesn't ship":

A half-builder is an operator who can do exactly one half of design-to-deploy, then skips the other half by simply not showing it. They post the artifact for their good half. The bad half is implied to exist. It usually doesn't.

There are three failure modes and I've personally lived all three.

The designer who can't code. Posts the Figma. Posts the AI-generated mock. Posts the screenshot, the concept, the "what if I built this?" thread. Never posts the running URL. The "build" is a frame around an image. I did this for years before I learned to ship.

The coder who can't design. Posts the diff. Posts the gist. Posts the prompt. The thing technically runs but you wouldn't keep it open for more than a session. The interface is a textarea and a <details> tag in Helvetica. I've published a few of these too. I called them "tools."

The either who can't ship. The most common failure mode by an order of magnitude. They can do their half competently. They can't deploy it, can't keep it up, can't onboard a single user, can't reach week two. Six demos a month. Zero products. The artifact dies in a screenshot.

The third failure mode is the one I've spent the most time in. I'd build a thing in a weekend, push it to a public repo, post a screenshot, get a few likes, and move to the next thing on Monday. I called that "shipping." It wasn't. It was sketching in public.

In all three modes the AI is real. The thing posted is real. Something got built. What didn't happen was building the whole thing. The half that wasn't shown was fake, missing, on someone else's calendar, or a TODO that never got picked up again.

That's a half-builder.

Why half-building is the default

It's not a personal failure. It's the structure of the industry for twenty years.

Design and engineering have been culturally separated since the early-2000s web. You picked a side at 22. The side trained you. Designers learned visual systems, components, motion, brand. Engineers learned data structures, infra, deployment, latency budgets. The handoff was the deliverable. Each side optimized for being good at their half, because their half was the whole job.

AI is collapsing that gap.

Every tool that closes the design-to-code distance (Figma-to-code generators, coding assistants, no-code with escape hatches, full-stack agents) pays out to operators who hold both sides in one head. The premium isn't on either half anymore. It's on the seam.

Twenty years of single-side specialization don't unwind in a hype cycle.

So the dominant cohort on AI-builder X is exactly who you'd expect. People whose career was built around being competent at one half. Learning AI in real time. Posting the half they can already do. Hoping the AI bridges the rest.

Sometimes it does. Most of the time it doesn't. The shipped product never appears. The next thread does.

I've been on this side of the timeline for years. Designers who became "builders" the day GPT-4 dropped. Engineers who became "AI engineers" the day Cursor got good. I'm one of them. The honest answer is that AI made it embarrassingly easy to look like a whole-builder while staying a half-builder underneath.

Builder.ai was that, with a $450M check on top.

What I've actually shipped (and what I've half-shipped)

Here's the honest receipts list. Not the highlight reel.

Real products people use:

Dory. Shared memory layer for AI agents. Local-first, markdown source of truth, CLI / HTTP / MCP native. Open-source on GitHub, has actual users, gets actual issues filed. This is the only one I'd call run-grade.
deeflect.com. Personal site, in production, anchors my entity online.
blog.deeflect.com. Thirty-one published articles. Some of them are good. Not all of them are from this year, that was overstated in earlier drafts of this essay.
dee.agency. Solo studio site, productized AI work.
Don't Replace Me. Survival book on the AI apocalypse, paperback, hardcover, Kindle, on Amazon. Written end-to-end. People are reading it.
The SEO-to-GEO Gap. First research paper, accepted and posted on SSRN this month with a real DOI. First peer-review-adjacent credential I've ever earned.

Half-shipped:

ViBE. Twitter-based reception benchmark across 22 frontier AI model families, 2,965 judged mentions, $1.92 in judge cost. I love the writeup. I keep pitching the writeup. The benchmark itself is dogshit as a continuous product. It's a one-shot artifact, not a living thing, and treating it like a flagship was me confusing "interesting research" for "shipped product."
Universal-codemode. Two tools that replace hundreds. Clever. Not used.
Vasted. GPU-inference one-liner. Works. Unadopted.
Smart-spawn. Model router. Demo grade.
Castkit. CLI demo recorder in Rust. Cute. Sat down.
Mcclaw. Mac-LLM checker. Fun. Abandoned.
Moltedin / lobster-tools / tldr-club / clawbot-blog. Different shapes, same pattern. Started, posted, walked away.

The actual range underneath all of it:

Fifteen years of design. A cybersecurity bachelor. Firmware on ESP32 and marauder builds when the topic shifts. Designed for VALK across 70-plus financial institutions and 15 countries before walking out of that role earlier this year. Russian-born, lived across five-plus countries. ADHD wired enough to learn shit in a week and bored enough to walk away from it in a month.

The range is real. The shipping discipline isn't there yet.

In October 2025 I burned out and quit X for six months from a 200K-impressions-a-day peak. I'm reactivating from 640 followers as I write this. The list above is what got built around the crash year: three real products, a book, a paper, a personal entity I can point to, and a graveyard of clever half-things.

That's the honest picture. I'm a recovering half-builder.

The opposite cohort

The opposite of a half-builder is a whole-builder.

A whole-builder is one operator who covers design + code + AI + deploy + distribution end-to-end with no handoff. They pick fewer fights. They keep the artifacts alive past launch week. They have repos with users in the issue tracker, not just stars in the corner.

Pieter Levels is the canonical example. Design, code, deploy, distribute, monetize, all solo, all in public, receipts measured in MRR and screenshots. Marc Lou ships products with full visual identity attached. Theo runs an entire product line out of what he can hold in one head.

These aren't unicorns. They're the rarer category: operators who didn't pick a side and built their working pattern around not having a handoff. They're also the operators who said no to the next side-quest and kept the last one running.

I've copied the breadth half of that pattern. I haven't copied the discipline half. Whole-building isn't about doing more. It's about doing fewer things further. That part I'm still learning.

How to spot a half-builder (mirror included)

Most "AI builders" on the internet right now are half-builders, and most of us know which side we're on if we're honest about it.

The test is mechanical. It costs nothing. Run it on every "AI builder" account in your timeline this week, and on yourself.

Ask for the running URL. Not the prompt. Not the screenshot. Not the demo video. The URL someone else can open right now, on their phone, with no auth, no waitlist. If they can't produce one, you're talking to half a builder.

Ask for the repo. Public repo, last commit recent enough to matter, an issue tracker that isn't a ghost town. If "the code is private", fine. Ask for the deployed product. If neither exists, you have your answer.

Ask what they shipped this month. Not last year. Not "in their career." This month. Half-builders ship demos. Whole-builders ship products that someone else is using on a Tuesday morning.

If you ran that on me a month ago, you'd hear about ViBE and a clever Rust thing and a model router and a half-finished benchmark and a launch I almost did. You'd hear about everything except a product someone else opened on a Tuesday. The honest answer would have been Dory, and maybe the blog, and the rest is noise.

Show the repo or sit down, including the one I'm pointing back at when I write that.

Stopping

The exit from being a half-builder is mechanical, not mystical.

Pick the half you can't do and start doing it badly until you can do it. Designers shipping their first deploy. Coders learning visual hierarchy. Either learning distribution. The half you can't do isn't a personality. It's a backlog.

Pick fewer things. Keep them alive past the first week. Treat "shipped" as "someone else used it on a Tuesday," not "pushed to GitHub on a Sunday."

Whole-building is a slow accumulation of the second half by the first, until the seam disappears. None of that happens in a single weekend.

This essay is the first move. The next moves are: Dory gets the maintenance it deserves. ViBE either becomes a continuously-updating thing or gets retired honestly as a one-shot paper, not pretended into a flagship. The agency stops being a placeholder. The next side-quest waits its turn, or doesn't get started.

I'm writing this with the same uncertainty most of you feel scrolling past it. Am I the half-builder? Probably. What does the turn look like? Like this.

Build the whole thing.

Ship the running URL.

Show the repo.

Or sit down, including me.

That's the post.

Sources for the Builder.ai facts: Bloomberg's investigation into the company's engineering operations (2024), the Wall Street Journal's coverage of the May 2025 insolvency, and The Information's reporting on the human-engineer back-end. Public, well-indexed; current URLs available via search.

I've Touched Everything and Mastered Nothing

Mon, 06 Apr 2026 00:00:00 GMT

Seventeen years. That's how long ADHD has been making me touch every skill, hobby, and career path that crossed my path. I'm 30 now. I've lived in eight countries, built products in five programming languages, shipped code on four blockchains, released music on Spotify under an artist name I genuinely cannot remember, and learned enough Vietnamese to haggle at a market in Nha Trang.

A lot of it stayed at the level of useful. A few things became real expertise.

That's the honest version of this story. Not the LinkedIn version where "my diverse background gives me a unique perspective." The real version, where I've spent a decade and a half chasing dopamine across every domain imaginable and I'm only now figuring out what that actually means for a career, an identity, and a life.

What the ADHD cycle actually looks like across every skill, hobby, and career path

The cycle runs on roughly a two-week clock. Something new appears - on Twitter, in a YouTube rabbit hole, in a Discord I shouldn't be in at 2am. The dopamine hits immediately, before I've done anything. I'm already planning the next phase while I'm still in the first hour.

Then comes the manic stretch. Twelve-hour sessions at the computer, deep in documentation and GitHub repos and forum threads from 2015 that nobody else has read. I still eat well, still sleep well, still train. Health is the one thing I never let slide, no matter how deep the rabbit hole goes. But everything else disappears.

Two weeks later, sometimes less, I wake up and it's gone. Not burnout. Burnout has texture - exhaustion, resentment, a desire to rest and come back. This is nothing. Flat affect toward something that consumed me completely three days ago. The interest didn't fade. It evaporated.

This has been my entire adult life. Before that, too - graffiti, parkour, long-distance running, acrobatics, all before I owned a computer. I fixed a relative's MS-DOS machine in English when I was around eight and barely spoke English. I rigged our home phone line to connect to a friend's LAN across the city. I built a radio to intercept our wireless home phone so I could eavesdrop on my mom's calls.

I was never bored. I was always building something I'd abandon.

What I didn't understand at eight, and only started to understand around 27, is that this isn't a moral failing. It's the shape of how my brain processes novelty. The dopamine system in ADHD brains responds to new stimuli harder and drops off faster than neurotypical brains. I wasn't undisciplined. I was running a biological process I had no name for.

Knowing that doesn't stop the cycle. But it changes how you relate to the wreckage.

The graveyard is real

Let me just list some of it.

A DJI drone I used four times. A Sony DSLR that mostly lives in a bag. A 3D printer I operated twice, let collect dust for six months, and sold at a loss. A soldering station I learned to use at university, felt was essential to own again years later, and which currently sits in my wardrobe untouched. A ukulele from Turkey. Guitar - I can play a few songs. Piano - I can play Kanye's Runaway and that's it. Harmonica. Stylophone. Otamatone. An AKAI MPK Mini. Ableton. AI music with Suno. I released lofi tracks on Spotify. I cannot remember the artist name.

Stocks in Russia via an app. Mostly broke even, maybe lost a bit. Cybersecurity hardware - a Flipper Zero, a Kali Linux laptop, ESP32 boards with Marauder firmware, an ESB dongle for intercepting TPMS sensors, and an M5Stack kit with a pile of controllers and sensors. Cardputer. LLM630. Tiny screens, weird modules, more little boards than I had any reason to own. I spent weeks flashing firmware and scanning radio frequencies. Did I build anything useful? No. Make money? No. But I understood how your wireless water meter broadcasts unencrypted data to anyone with the right hardware, and that felt worth it.

None of this is sustainable. The "ADHD is a superpower" content you see everywhere stops before this part. The graveyard. The money spent. The projects half-finished. The domains where I got to "good enough to be dangerous" and never further, because the dopamine was already somewhere else.

This pattern has been running long enough that it stopped feeling surprising a while ago.

The financial reality nobody mentions

I want to be concrete about this because most "ADHD and creativity" content is vague about costs.

The 3D printer was around $400. Sold for $180. The drone was $700. Used it maybe ten hours total. The cybersecurity hardware - Flipper, M5Stack, the various ESP32 boards, cables, accessories, random modules - probably $600 spread across three months. The Ableton license. The AKAI. The ukulele I bought in a market in Istanbul because I was in a hyperfocus phase about lo-fi music production.

I don't have an exact number. But it's real money. And this doesn't count the opportunity cost of the hours - hundreds of hours flashing firmware on microcontrollers that never produced anything, learning guitar in 30-minute sessions spread across five years, studying Vietnamese for six weeks before the next interest hit.

I'm not saying this to make it sound worse than it is. I'm saying it because the "embrace your ADHD divergent thinking" content leaves this part out and I think it's dishonest. The breadth has real costs. The search has a price.

When it does stick

Some things stuck. Design, 17 years. The gym, 15+ years. AI, three years and accelerating.

I started freelancing at 14, selling forum banners and GIFs on ICQ. By university I was building websites for roughly $80-120 each in local-currency terms at the time. When I graduated, companies were offering something like $150 a month. I was already making more than that per site. I said no thanks and kept going. Design is probably the closest thing I have to real expertise after 17 years - I spent five of those years as the solo senior product designer at VALK, a fintech platform that moved $4B+ in deals across 70+ financial institutions in 15 countries. Awards. Real scale. Products that live in actual banks.

The gym stuck because I started before I knew what consistency meant and just never stopped. Different approaches over the years - bodybuilding, strength, cuts, boxing for two years in Krasnodar - but the baseline never dropped. I track bloodwork every few months and stay on top of health like it's another system to tune. When something becomes infrastructure instead of a project, the ADHD can't kill it.

AI stuck because it's the first domain that feeds the obsession cycle faster than the cycle drains it. Every week there's something genuinely new. You can't get bored because the field won't hold still. I built one of the first agentic loops I'd seen anyone build in 2022 - a Telegram bot for a crypto community that could reason and take actions, before "agentic" was even a term. I didn't know what I was building. I just thought it was interesting.

Now I let AI maintain my second brain - knowledge, reminders, loose thoughts, follow-ups, personal assistant type shit. Less "look at my agent stack," more "I built something that remembers what I forget and keeps my life from scattering." I also host local models on a Mac Mini because of course that became another obsession too - if something can run on my own box, I want to try it. It's not a demo. It runs every day. You can read more about how I approach coding and multi-model workflows if you want the technical side.

Why some things survive the cycle

I've thought about this a lot. What makes design and the gym persist when everything else evaporates?

Two patterns show up every time.

First: external feedback loops that don't require internal motivation. The gym gives me bloodwork numbers, strength PRs, photos over time. Design gives me client feedback, shipped products, metrics. When my internal interest flags, there's still external data pulling me back. The drone had none of that. The guitar had none of that. They only worked when I was actively excited, and when the excitement went, nothing remained.

Second: the domain kept changing fast enough to feed new obsession cycles. Design went from print to web to mobile to design systems to AI-generated UI. Every three years there was a new layer to get obsessed about. The gym went from machines to compound lifts to programming to bloodwork optimization. The domain regenerated novelty before I burned through it.

AI has both properties at a ridiculous level. New model every month. New architectural pattern every six weeks. New tool category every quarter. It's basically a purpose-built trap for an ADHD brain and I walked straight into it.

How ADHD shapes every skill, hobby, and career path you choose

Here's what I've realized after 30 years of this: ADHD doesn't just affect how you learn things. It determines what career paths even become available to you.

I have an Information Security bachelor's that I haven't used professionally once. But the two years I spent in that program gave me networking fundamentals, an understanding of cryptography primitives, and enough systems-level thinking that when blockchain showed up in my life it wasn't foreign territory. That "useless" degree became the reason I could evaluate Solidity code for security issues at VALK without being a dedicated security engineer.

The career I've actually had - designer, then product lead, then AI engineer - looks like three different careers. But they're the same brain solving the same problem at different layers of abstraction. Design is about modeling user mental states. Product is about modeling system interactions. AI engineering is about modeling agent behavior. I didn't pivot three times. I drilled down.

That's the ADHD career path nobody maps: not a straight line, not even a zigzag, but a spiral. You come back around to the same core problems from different angles. The angle changes. The problem doesn't.

The generalist discount problem

No job posting says "wanted, someone who can do a little bit of everything."

Generalists get discounted by hiring processes designed for specialists. I have production code in TypeScript, Python, Rust, Solidity, and SQL. Deployed products on four blockchains. Sysadmin experience across every OS since childhood. Enough crypto experience to have launched 20+ tokens. On a resume this looks scattered. In a specific situation - say, a 48-hour sprint where a client needs a smart contract, a minting frontend, and custom illustrations - it's exactly what's needed and nobody else in the room has all three.

When VALK wanted a Christmas NFT campaign I told them I'd handle it. Smart contract, minting site, illustrations, the whole frontend - solo, in one sprint. That's not something a specialist does. That's an ADHD brain that collected 12 different surface-level skills over a decade, all converging on one afternoon's work.

The problem is you can't interview for that. "I know a little about a lot" doesn't clear an ATS. So the career path for someone like me had to go around traditional hiring - freelance, founding roles, solo building. Places where the breadth shows up in delivered work rather than credentials.

The breadth problem and the breadth premium

This year I wrote a 33,000-word book from scratch. I'd never written a book before. Don't Replace Me: A Survival Guide to the AI Apocalypse - 24 chapters, formatted, cover designed, published on KDP, audiobook via ElevenLabs, SEO landing page with schema markup, Amazon ads. Not because I wanted to be an author. Because the process of building the whole machine was interesting to me.

The ADHD didn't stop me from finishing a book. It kept me engaged long enough to finish one because there were 15 different new processes to learn inside the single project. The writing was interesting for the first 10,000 words. Then the Kindle formatting was interesting. Then the audiobook pipeline. Then the schema markup. By the time I finished, I had a complete book, a production process, and had learned four skills I didn't have before.

This is the pattern. I don't go deep on one thing. I go wide enough that when a project needs five different skills, I'm the one person in the room who can cover them all. The breadth is a premium in those moments - genuine leverage that a specialist can't replicate without a team.

The honest version though: those moments don't come every day. Most days, the breadth just means I know enough to be frustrated by problems in domains where I don't know enough to solve them.

Why the AI age changes this calculation for ADHD builders

AI is doing something weird to the generalist problem. On one side, everyone's a generalist now. Vibe coding means your non-technical friend can ship a landing page. The moat of "I know five programming languages" is basically gone.

On the other side - and this is the part I actually believe - breadth becomes more valuable when AI amplifies execution. You don't need to be an expert Rust developer. You need enough Rust to direct an AI agent doing Rust work. You need to know when the output is wrong. You need the taste to recognize what "good" looks like without being able to produce it from scratch at 100 words per minute.

I spent 17 years accumulating surface-level knowledge across maybe 30 domains. That knowledge doesn't help me compete with a specialist in any one of them. But it means I can look at an AI's output in almost any domain and tell you whether it's right. Design intuition applied to code review. Crypto chaos tolerance applied to agentic system failures. Sysadmin muscle memory applied to Docker containers. The ADHD brain that couldn't go deep now has a use case that rewards breadth.

This isn't hypothetical. I use dee.ink - a collection of 31 Rust CLI tools I've built for AI agent workflows - as a practical example. Building those tools required Rust, CLI design, documentation, packaging, and enough understanding of AI agent needs to spec useful primitives. Same with the home lab stuff - a ZimaBoard running home server experiments, local infra, and smart home services because once I touched self-hosting I obviously had to touch that too. A specialist Rust engineer would write better Rust. A specialist AI engineer would understand agent needs more deeply. A specialist infra person would build a cleaner home lab. But I could build the whole thing myself, end to end, without waiting on anyone.

That's the AI-era argument for the ADHD generalist: you're not competing on depth anymore. You're competing on range of judgment. And AI is making range of judgment the bottleneck, not depth of execution.

If you've felt this same tension - the generalist guilt, the half-finished projects, the identity question of what you even "are" professionally - I wrote more about navigating ADHD and AI as actual compensation tools, not the productivity-porn version.

The identity question ADHD every skill, hobby, and career path creates

Here's the thing nobody talks about with the ADHD generalist lifestyle: you don't know what you are.

Ask a specialist what they do and they tell you in one sentence. "I'm a backend engineer." "I'm a product designer." The identity is clean. The work is legible to other people.

Ask me and I have to make a choice about which version of myself I'm presenting. The designer with 17 years? The AI engineer building multi-agent systems? The guy who spent three months obsessively learning about RF signal interception for no professional reason? All of these are equally true. None of them is the whole answer.

For a long time this felt like a problem. I'd look at people with clear professional identities - engineers who'd been doing one thing for ten years, designers with a coherent portfolio narrative - and feel like I was faking it. Like my breadth was evidence of some underlying lack of commitment.

What I've landed on at 30 is different. The identity question isn't a problem to solve. It's a feature of a specific type of brain operating at full capacity. The discomfort of not fitting a category is the cost of not being constrained by one.

I'm not a designer who learned to code. I'm not an engineer with design skills. I'm something that doesn't have a clean job title yet, that probably couldn't exist before AI made it possible to execute across domains without a full team. That's not a failure of self-definition. It's just early.

What actually sticks at 30

The gym. Design. AI.

And maybe that's the real pattern. The things that stuck aren't the things I chose. They're the things that were still there after the dopamine moved on. The gym was still there because I'd been going long enough it became automatic. Design was still there because clients kept paying me. AI is still there because it keeps generating new problems faster than I run out of interest.

What I've stopped doing is chasing the feeling of the early phase - that first-week intensity when everything seems possible and you're learning at maximum speed. That feeling always ends. The question isn't how to keep the feeling. It's what you're building during it.

What I actually think about it at 30

The "ADHD superpower" narrative is mostly incomplete. It's real but it stops too early. Yes, the hyperfocus is incredible. Yes, the breadth compounds in ways specialists can't replicate. Yes, the manic phases produce more in two weeks than most people produce in two months.

But the depressive phases are the tax. The days where you look at a project you were obsessed with last week and feel nothing at all. Not tired. Not frustrated. Nothing. The graveyard of equipment bought and abandoned is real money. The projects with twelve active tabs and zero generating revenue are real.

I've been through every single phase of this across eight countries and more career pivots than I can accurately count. I still think I'll find the thing. Maybe design and AI are already it and I just haven't accepted that yet. Maybe something I haven't encountered will show up and replace everything I've built my identity around. Both feel equally plausible from the inside.

What I know is this: at 30, having touched more domains than most people touch in a lifetime, being functionally average at most of them and arguably expert at two - I'm not embarrassed by any of it. The search wasn't failure. The search was the work. Everything compounds in ways you can't predict when you're in the middle of a two-week obsession with intercepting radio signals from water meters.

If you want to see what the current obsession looks like in practice - the AI engineering side, the multi-agent systems, the actual tools - the about page has the full context. And if you're building something similarly scattered and solo, the tags page will probably surface something relevant.

If you're in the middle of your own version of this - the cycle, the graveyard, the guilt about the 3D printer sitting in your closet - you're probably not broken. You're probably just still searching.

That's an okay place to be.

So I asked AI to list my skills

Based on everything I've touched, built, learned, half-learned, abandoned, revived, bought, sold, shipped, and somehow got paid for, I asked AI to write out my skill set in one paragraph.

It was a mistake.

Graphic design, product design, UI design, UX design, interaction design, interface design, web design, mobile design, dashboard design, platform design, application design, systems design, design systems, visual systems, component systems, branding, digital branding, visual identity, typography, layout, hierarchy, composition, spacing, iconography, illustration, digital illustration, vector illustration, marketing design, motion graphics, banner design, avatar design, forum graphics, landing page design, cover design, presentation design, pitch deck design, onboarding design, checkout flow design, conversion design, user flows, journey mapping, wireframing, prototyping, information architecture, UX strategy, usability thinking, interface critique, product thinking, product strategy, feature prioritization, product packaging, product positioning, product communication, client communication, stakeholder communication, design leadership, solo product ownership, freelance design, agency design, startup design, enterprise product design, fintech product design, dashboard UX, enterprise workflows, white-label platform design, workflow design, complexity reduction, visual clarity, frontend design, frontend implementation, HTML, CSS, responsive design, JavaScript, TypeScript, React, component libraries, design-to-code translation, web app implementation, rapid prototyping, interface implementation, code editing, debugging, code reading, AI-assisted coding, product-minded engineering, scripting, Python, Rust, SQL, Solidity, command-line tooling, CLI product thinking, developer tooling, automation scripting, API integration, webhook logic, backend glue code, database basics, schema instincts, debugging AI output, debugging code, debugging workflow failures, prompt engineering, prompt iteration, prompt structure, context design, tool calling, agent orchestration, multi-agent workflows, AI workflow design, AI product design, AI UX, AI-assisted writing, AI-assisted coding, AI-assisted research, AI tool evaluation, model comparison, reasoning model usage, local model usage, cloud model usage, local LLM setup, memory systems, second-brain systems, reminder systems, retrieval systems, RAG, embeddings, semantic search, vector search, AI assistant design, assistant workflow design, personal AI systems, research pipelines, writing pipelines, content pipelines, synthesis pipelines, information capture, note systems, knowledge systems, crypto product design, Web3 product design, smart contracts, Solidity workflows, token launch mechanics, NFT launch mechanics, minting flows, DeFi UX, blockchain UX, wallet UX, crypto campaign execution, crypto community operations, crypto marketing, launch coordination, presale mechanics, token website building, contract deployment understanding, onchain product instincts, community bot building, Telegram bot building, automation design, workflow automation, n8n-style orchestration thinking, research automation, content automation, digital marketing, internet marketing, social media growth, Instagram page growth, landing page copy, copywriting, headline writing, article writing, blog writing, long-form writing, editing, rewriting, draft development, AI-draft cleanup, humanization, publishing workflows, book writing, book formatting, self-publishing, KDP publishing, metadata writing, SEO, GEO, search intent mapping, keyword targeting, internal linking instincts, schema markup thinking, authority building, distribution strategy, launch strategy, publishing systems, website management, domain setup, CMS-light publishing, self-hosting, home server experimentation, Docker, DNS, reverse proxy basics, infrastructure curiosity, service setup, local infra experimentation, smart home experimentation, device setup, system setup, macOS setup, Windows setup, Linux setup, terminal usage, shell comfort, firmware flashing, hardware experimentation, embedded-device tinkering, cybersecurity basics, information security fundamentals, cryptography fundamentals, systems thinking, network instincts, radio experimentation, wireless experimentation, sensor experimentation, hardware debugging, hardware setup, game server hosting, home PC hosting, monetization instincts, digital hustle instincts, app install arbitrage, e-commerce experimentation, dropshipping experimentation, pricing instincts, sales instincts, client acquisition instincts, offer shaping, agency operations, productized service instincts, open source contribution, release management, tool publishing, music experimentation, music production, AI music workflows, Ableton experimentation, audio arrangement instincts, basic piano, basic guitar, basic ukulele, basic harmonica, stylophone experimentation, otamatone experimentation, creative direction, aesthetic judgment, visual taste, naming instincts, concept development, trend detection, trend synthesis, pattern recognition, fast learning, context switching, parallel execution, obsessive research, rabbit-hole depth, ambiguity tolerance, pressure-driven shipping, solo building, independent execution, figuring things out with incomplete information, reverse engineering workflows, surviving bad documentation, adapting to broken tools, evaluating software fast, comparing tools quickly, stack assembly, stack migration, no-code experimentation, low-code experimentation, API-first thinking, browser tooling, workflow compression, research summarization, synthesis, memory capture, memory retrieval instincts, file organization attempts, chaos-tolerant organization, async collaboration, self-direction, self-teaching, self-reinvention, internet-native communication, pseudonymous building, online identity experimentation, public writing, authority building through shipping, cross-domain thinking, interdisciplinary synthesis, technical taste, product taste, marketing taste, creative taste, execution bias, strategic intuition, quality smell detection, visual QA, copy QA, product QA, issue isolation, error triage, launch QA, software evaluation, tooling adoption, rollout instincts, packaging instincts, distribution instincts, positioning instincts, and generally becoming competent enough to start, ship, fix, relaunch, and repurpose work across an unreasonable number of domains without ever sitting still long enough to make any of it feel normal.

Reading it felt less like a skills list and more like a forensic report.

Don't Replace Me: My AI Survival Guide Book

Sun, 29 Mar 2026 00:00:00 GMT

I wrote a book. It's called Don't Replace Me: A Survival Guide to the AI Apocalypse, and it's available right now on Amazon in Kindle, paperback, and hardcover. The announcement for Don't Replace Me survival guide dropped March 28, 2026 - press release picked up through AP News and everything. 235 pages, 24 rules, 33,000 words.

Took me way longer than I expected and was nothing like I expected. Let me explain what it actually is and how it got made.

Why Don't Replace Me exists as a book and not just tweets

I've been getting a version of the same conversation for two years. Someone finds out what I do - AI engineering, building agents, 15 years in product design - and they get this look. Half curiosity, half dread. Then the question: "So... should I be worried? About my job?"

The honest answer is complicated. Not "no, you're fine" and not "yes, start learning Python immediately." The actual answer depends on what you do, how you do it, and whether you understand what AI is actually replacing versus what it's just augmenting.

The loudest voices on this topic tend to be at the extremes. Either AI builders who are close enough to the technology that the disruption looks like opportunity from where they're standing. Or people far from it who are doom-scrolling tech Twitter and convinced everything is gone. Both are wrong in ways that matter to normal people with real jobs.

I've sat on both sides of that divide. I spent five years designing products at VALK - financial infrastructure for 70+ banks across 15 countries, $4B+ in deals running through platforms I helped design. I was building for institutions. Then I pivoted to building the automation itself. Multi-agent systems, AI workflows, the actual pipelines that companies are now using to cut headcount or redeploy people.

I've talked to people on both ends. Executives excited about efficiency. Employees scared about what "efficiency" means for them personally. And I kept having the same thought: someone should write something honest about this. Not a hype piece, not a manifesto, not a beginner's guide to ChatGPT. Something from the middle.

So I did.

What Don't Replace Me is and what it isn't

Don't Replace Me is not a coding tutorial. It's not a prompt engineering guide. There are plenty of those and they're mostly aimed at people who already know what a terminal is.

This is for my mom. For my friend who does project management at a mid-size company and genuinely doesn't know if her job will exist in three years. For the copywriter, the customer service manager, the paralegal, the graphic designer who keeps seeing LinkedIn posts that make them feel like they missed the boat.

24 rules. Each one practical, specific, and grounded in things I've actually seen. Not "embrace AI" or "upskill your journey" or whatever LinkedIn thought leadership nonsense. Real career advice for people navigating a real transition.

The companion site is at dontreplace.me and it has a free AI threat assessment quiz. You answer questions about your actual job - what you do day to day, how structured the work is, how much it involves judgment vs.execution - and you get a risk score. Not fearmongering, not false reassurance. Just a calibrated read on where you actually stand.

Three formats available now: Kindle, paperback, hardcover. Audiobook is in production. If you've been waiting for audio, it's coming.

ASIN on Amazon is B0GTX4J124. Paperback ISBN is 9798253164594. Hardcover is 9798253165386. I'm mentioning these in case you're the kind of person who looks these things up. You can also check out the book's website at dontreplace.me for more info and the quiz.

How I made this and why I'm being upfront about it

I used AI to write this book. I'm not hiding that, and I'm not embarrassed about it. But it's not what people assume when they hear it.

I didn't type "write me a 235-page career guide" and hit enter. That's not how this worked.

What I did: I spent months collecting actual opinions. Notes from real conversations. Observations from years of watching companies get disrupted from the inside. Things that frustrated me. Things I genuinely believe. Specific examples from fintech, from AI engineering, from watching product design go through its own automation panic. I had a lot to say - just scattered across voice memos, Notion drafts, Twitter threads, and conversations I kept having with people who were scared.

All of that went into the process as fuel. The AI was the engine. The substance is mine.

The result reads like me because it is me. My takes, my experience, my perspective on what's changing and what isn't. I used every tool available to get it out of my head and into something usable. Which is exactly what the book tells readers to do - use AI as leverage, not as a replacement for your own thinking.

The irony is the point. I couldn't have written a better proof of concept.

And honestly, if you're going to argue that this makes the book less valid - that's a conversation worth having, and it's one of the conversations the book is designed to prompt. Because that reflex, the instinct to devalue work because AI was involved, is exactly the kind of thinking that will hurt people's careers over the next decade. The question isn't "did a human do every part of this." The question is: is the thinking real? Is the perspective genuine? Is it useful?

Yes, yes, and I think so.

What 15 years of watching tech cycles taught me about this one

I started freelancing at 14. I've watched design go through "designers will be replaced by templates." I watched developers go through "no-code will replace engineers." I watched writers go through "content mills will replace real writing." Some of that disruption was real. A lot of the fear was misdirected.

This cycle is bigger. I won't pretend otherwise. The things AI is genuinely good at - pattern recognition, synthesis, first-draft generation, handling repetitive decisions - overlap more directly with white-collar knowledge work than previous automation waves did. This isn't just factory floors and truck drivers. It's reaching into offices.

But the shape of the threat is different for different people. And most of the advice out there treats it like a monolith. "Learn to prompt" is not useful advice for a nurse. "AI can't replace human connection" is not useful advice for a data entry specialist.

What actually helps is specificity. Understanding which parts of your work are high-judgment versus low-judgment. Understanding where your industry is in the adoption curve. Understanding the difference between "AI will do this task" and "AI will make someone else more efficient at your job." The second one is actually the bigger risk and people underestimate it.

That's what the 24 rules get into. Specific, not vague. Grounded in real patterns I've watched play out, not hypotheticals.

If you want a preview of where my head is at on some of this, I've written about leaving fintech to build AI systems, about what ADHD and AI actually look like together, and about why most AI products have terrible UX - the gap between what builders understand and what real users need. The book is longer, more structured, and aimed at a wider audience, but those posts give you a sense of how I think.

Who Don't Replace Me is actually for

Specifically, concretely:

If you have a job and you're not sure whether to be worried, this is for you. Not to soothe you with "AI can't replace humans" and not to panic you into a six-month bootcamp. To help you actually assess your situation.

If you manage people and you're trying to figure out how to talk to your team about AI adoption without sounding like either a corporate automaton or someone who's out of touch, there's stuff in here for you.

If you're in a creative field - design, writing, marketing - and you've already felt the job market shift, there's a section of this that I think is genuinely useful. Not "here's how to compete with AI" but here's how to think about what you're actually selling.

If you already know about AI and want something to send to a family member who keeps calling you asking what to do - this is that thing.

The technical people are not the audience here. My coding stack post or the deep dive on debugging AI agents is more your speed. This book is for the people those systems are being built around.

Where to get it

Amazon has all three formats right now — grab it here or search "Don't Replace Me Dmitrii Kargaev."

The companion site is dontreplace.me - free quiz, takes about five minutes, gives you a real threat assessment based on your actual role. Even if you don't buy the book, the quiz is worth doing just to have a concrete picture instead of ambient dread.

Audiobook is in production. I'll announce it here and on my portfolio site when it drops.

If you read it and have thoughts - what landed, what you disagree with, who you think needs to read it - I want to hear that. Building in public means the feedback loop stays open. This isn't the end of the conversation, it's more like a long, structured version of it.

The people I had in mind when I was writing this are real. If you know someone who's been quietly scared about this stuff, send it to them. That's what it's there for.

SEO Is Dead? No. But the Game Changed.

Thu, 26 Mar 2026 00:00:00 GMT

I asked ChatGPT who I am. It had nothing. No idea I existed.

I've been deep in the AI space for a while now. I spent 5 years as lead product designer at a fintech platform serving 70+ financial institutions. I shipped 31 open-source Rust CLI tools. Published 13 blog posts. Built in public for months. And the models I use every day had zero record of me.

That bothered me more than it probably should have. But it also made sense once I started pulling the thread. Because "SEO is dead" isn't quite right - but something real is shifting, and I wasn't ready for it.

This is what I found.

The two games nobody told me I was playing

There's Google-findable. And there's AI-citable. I had one. I completely lacked the other.

Traditional SEO is about ranking. You write content, build links, optimize your pages, and Google surfaces you when someone searches. The pipeline is: search query → ranked results → human clicks through. That's the game most people know how to play.

Generative Engine Optimization - GEO - is about citation. AI generates an answer. Your content, your name, your entity gets referenced in that answer. The pipeline skips the click entirely. There's no blue link. The model just knows you exist, or it doesn't.

I had spent zero time thinking about the second one. Which meant I was completely invisible to the systems I use to do my actual work. The irony was genuinely annoying.

That gap is what sent me down a multi-week research rabbit hole that ended with an open-source platform list, a scoring system, and a website full of free tools. But I'm getting ahead of myself.

What's actually happening to search right now - and why "SEO is dead" keeps trending

The data isn't speculative anymore. BrightEdge tracked AI Overviews appearing in 11% of all queries in 2025. CTR is down 30%. People are asking AI assistants instead of searching, and when they do search, they're increasingly getting an AI-generated summary instead of ten blue links.

This isn't a prediction. It's already the baseline. The shift isn't coming - it happened while everyone was arguing about whether it would.

SparkToro's 2025 data puts this in concrete terms: top established brands appear in 55-77% of relevant AI responses. Unknown entities? 70x more volatile. You either have consistent presence or you have noise. There's not much middle ground.

The question stopped being "how do I rank?" and became "how do I get cited?"

What made this hit differently for me was trying to find myself across the major AI systems. Not just ChatGPT. I asked Claude, asked Perplexity, asked Google's AI Overview. The results were inconsistent in a way that told me something real: these systems aren't pulling from the same data, aren't weighting the same signals, and aren't resolving entities the same way. Being findable on one doesn't mean you're findable on all. That fragmentation is the part nobody's really mapped yet - including most of the GEO content I've seen so far.

SEO isn't dead - let's be honest about that

The title is provocative on purpose. Here's the actual nuance, because I think people deserve a straight answer rather than a hot take.

seoClarity's 2025 research found that 99.5% of AI Overview sources come from Google's top 10 organic results. Read that again. The AI is pulling from Google's rankings. Which means if you don't rank, you don't get cited. SEO is still the prerequisite. GEO builds on top of it.

So no, you shouldn't burn your SEO playbook. You should add a chapter.

What changed is the goal. Ranking #1 used to be the finish line. Now ranking #1 gets you in the candidate pool for AI citation. That's still worth doing. But it's not sufficient anymore. You can rank well and still be invisible to AI systems if you're missing the signals that models use to identify credible, citable entities.

Think about what that means practically. You could have a page ranking on the first page of Google for a competitive keyword - real traffic, real impressions - and still not get cited in an AI-generated answer for the same query. Because the ranking signals and the citation signals overlap but aren't identical. You need both. And most SEO workflows are only optimizing for one.

That's the shift. Not death. Evolution with a second layer that most people haven't started thinking about yet - including me, until very recently.

What GEO actually is and why the research convinced me

Generative Engine Optimization is the practice of optimizing your online presence to appear in AI-generated answers, not just search rankings.

The foundational paper here is Aggarwal et al., published at KDD '24 - you can read it on arXiv. They tested different optimization strategies across a range of queries and found that the right approach could drive up to a 40% increase in AI visibility. The top strategies weren't what I expected: citations and statistics outperformed most other approaches. Authoritative sourcing matters enormously to how models evaluate content.

Structured data, clear entity signals, and demonstrable expertise all feed into whether a model considers you citable. This isn't link juice. It's closer to reputation infrastructure - the stuff that makes a model "trust" that you're a real entity with real credentials.

What clicked for me is that this maps to how the models actually work. They don't crawl the web in real time. They learned from a corpus. And in that corpus, some entities are clearly defined, well-referenced, consistently mentioned. Others are noise. I was noise.

The content structure piece most people miss

The Aggarwal research gets into something most GEO content glosses over: it's not just what you publish, it's how you structure it.

Content that AI systems cite tends to have specific characteristics. It makes direct, falsifiable claims. It cites external sources. It includes statistics with attribution. It answers questions in a way that can be cleanly excerpted. This last point matters more than I initially thought - AI systems aren't summarizing your whole article, they're pulling specific passages. If your content isn't written in citable chunks, it's harder for a model to quote you cleanly even when it wants to.

This is actually a content design problem as much as an SEO problem. It's related to something I've written about before in the AI UX space - most people building for AI systems haven't thought about the machine as a reader with specific needs. The machine reads differently than a human does. It's looking for density, structure, and attributable claims.

Writing for AI citation means writing in a way that makes a model's job easier. Short, precise statements. Named sources. Numbers with context. The exact opposite of the fluffy "this is interesting to explore" writing style that pads word counts but says nothing.

The data point that actually rewired how I think about this

I went deep on the Ahrefs research and one number kept stopping me.

Brand mention correlation to AI citation: 0.664. Backlink correlation: 0.218.

That's not a small gap. Brand mentions are three times more predictive of AI visibility than backlinks. Three times. The entire SEO industry is built around backlinks as the gold standard signal - and for Google rankings, that's still mostly true. But for AI citation, what matters is whether your name, your brand, your entity is being talked about across the web.

The Semrush data added another layer: nofollow links perform nearly as well as dofollow links for AI visibility. In traditional SEO, a nofollow link is worth significantly less. For GEO purposes, the signal isn't the PageRank transfer - it's the mention. The presence. The fact that you're being referenced.

This is a real reorientation. The question isn't just "who links to me?" It's "who talks about me, mentions me, references me across contexts?" Those are different things. The second one is what I had been ignoring completely.

It connects to something I wrote about leaving fintech to build AI systems - the whole reason I went independent was to build things that matter. Building an AI presence that's actually citable is part of that.

What the platform data actually shows

When I started auditing where brand mentions were coming from across the 168 platforms I ended up cataloging, some patterns were obvious in hindsight.

Platforms that block AI crawlers still contribute to traditional SEO - backlinks, referral traffic, domain authority signals. But they contribute zero to AI citation. If a major AI crawler can't index the content where you're being mentioned, that mention is invisible to the model. Doesn't matter how high-authority the platform is. Doesn't matter how many people read it. The AI never saw it.

Several platforms that have solid SEO reputations block AI crawlers entirely. A few you'd never expect have wide-open access. The robots.txt data across 168 platforms genuinely changed my prioritization for where to spend time building presence.

High-DA platform with AI crawlers blocked: useful for search rankings, useless for GEO. Medium-DA platform with full AI crawler access: directly contributes to citation potential. Those aren't the same trade-off at all. Treating them the same - which most SEO frameworks do - is leaving real GEO value on the table.

Why "SEO is dead" gets the diagnosis wrong but identifies a real symptom

I keep seeing the "SEO is dead" framing in newsletters, on Twitter, in founder group chats. It's not accurate but it's pointing at something real: the workflows that worked in 2020 are producing worse results in 2025. That's true. The feeling that something fundamental has changed is correct. The conclusion that SEO itself is dead is wrong.

What's happening is that SEO was always a proxy for something else - demonstrating that your content is trustworthy and relevant. Google built ranking signals as a proxy for that. Now AI systems are building citation signals as a different proxy for the same underlying thing. The underlying thing didn't change. The measurement changed.

If you had real expertise and real content depth, most GEO strategies will work for you because you actually have the substance those signals are trying to measure. If you were gaming SEO with thin content and link schemes, GEO is going to be harder because the signals it uses are less gameable. Brand mentions across real communities are harder to manufacture than backlinks. Genuine citations in credible content are harder to fake than directory submissions.

That's probably a good thing. The prompt engineering is dead conversation is related - these systems keep evolving in ways that reward actual depth over tactical gaming. GEO continues that trend.

The mistake is treating this as a binary. SEO or GEO. Old playbook or new playbook. It's additive. Everything that made content good for search still applies. Now there's additional surface area to optimize - entity signals, structured data, AI crawler access, brand mention distribution - that wasn't relevant before.

What I built to solve this

Once I understood the problem I started doing the research manually - checking which platforms actually allow AI crawlers, which ones block them in robots.txt, which ones have high GEO value versus medium versus low. Doing it by hand was a pain in the ass. So I built a system.

awesome-geo is the output: a curated, verified list of 168 platforms with full crawler access data. 142 of them are AI-discoverable. I scored them: 74 high GEO value, 78 medium, 16 low. Every platform has been manually verified against robots.txt for the major AI crawlers - GPTBot, ClaudeBot, Anthropic's crawler, Google-Extended.

I also built geo. deeflect.com - free tools that came out of doing this manually and wishing they existed. AI Visibility Checker, JSON-LD Generator, llms.txt Generator, Meta Tags Generator, robots.txt Generator.

I built this because I needed it and figured others would too. It's open source. Use it.

The reason I verified robots.txt across all 168 platforms is that it matters more than most people realize. A platform could have high domain authority and great SEO value - but if it blocks AI crawlers, it contributes zero to your GEO presence. Several well-known platforms do exactly that. Knowing which ones are actually AI-accessible changes your prioritization completely.

The other thing that came out of building this: the verification process itself is time-consuming in a way that scales badly. You can't just check robots.txt once. Platforms update their policies. A platform that allowed GPTBot in 2023 might have added restrictions in 2024. The landscape is moving, which means any static list becomes stale. The tools at geo. deeflect.com are built to stay current rather than being a snapshot.

This is part of the same instinct that drove building multiple projects solo - when I hit friction repeatedly, I build the thing that removes it, then make it available. The GEO research tooling is that, applied to discoverability infrastructure.

What to do right now if you care about any of this

You don't need to overhaul everything. Start here:

Check where you're mentioned. Brand mentions are the highest-correlation signal. Are you being referenced across contexts beyond your own site?
Add JSON-LD structured data. This is how you communicate entity information to AI systems. If you haven't done it, geo. deeflect.com has a free generator.
Create an llms.txt file. Similar to robots.txt but for LLMs - it gives AI systems structured information about who you are and what you do. Again, free generator on the site.
Verify your platforms allow AI crawlers. Check the robots.txt on any platform you're counting on for AI visibility. You might be surprised what you find.
Think about entity consistency. Your name, credentials, and core claims should be stated consistently across platforms. Inconsistency makes entity resolution harder for models.
Use citations and statistics in your content. The KDD '24 research is clear: this is a top GEO signal. Reference real sources. Include real numbers. This post does that on purpose.
Audit your content structure. Are your key claims written in excerptable chunks? Can a model pull a clean sentence or paragraph that stands on its own? If not, restructure. This is different from readability optimization - it's citation optimization.

The prompt engineering is dead argument I've seen floating around is related to this - the game keeps shifting toward higher-level signals, away from tactical optimization. GEO is the same shift applied to discoverability.

Where this goes from here

I'm just getting started on this.

The research took me deep enough that I have a lot more to share - how different AI systems handle citations differently, what the actual citation mechanics look like across ChatGPT versus Claude versus Perplexity, how to structure content specifically for AI summarization, what the verification data across 168 platforms actually reveals about the crawling landscape.

The fragmentation across AI systems is the next thing I want to dig into properly. Right now, most GEO content treats "AI visibility" as a monolithic thing. It's not. Being cited by Perplexity requires different signals than being cited in a Google AI Overview. ChatGPT's training data cutoff means recent content won't affect your visibility there until the next model version. Claude uses different weighting. These aren't the same problem. Treating them the same is leaving real optimization opportunities untouched.

This article is the intro. I'm building out a full GEO research series here - the tools are live, the data is real, and I'm going to keep digging.

If you've been heads-down on traditional SEO and haven't thought about AI visibility yet, now's the time to start. Not because SEO is dead. Because the finish line moved - and most people haven't noticed yet.

SEO got a co-pilot. Learn to fly both.

Tools and research: geo. deeflect.com - awesome-geo on GitHub

The Distribution Problem Nobody Talks About

Wed, 11 Mar 2026 00:00:00 GMT

I have 61 post drafts queued up. 91 reply drafts. 18 finished blog posts, voice-matched and slop-filtered, ready to go. The distribution problem nobody talks about isn't content scarcity - it's the gap between a full queue and zero published output. That gap is where builder ambition goes to die quietly, surrounded by perfectly organized markdown files and automated scheduling daemons that never fire.

Let me explain how I got here.

The distribution problem, in numbers

Last week I built a full content automation pipeline. About 20 hours of work. I also built a road trip planning app with Maps integration (3 hours), set up a music production pipeline with AI voice conversion (2 hours), and my agent stack ran 240 autonomous sessions across three days while I was offline doing whatever offline people do.

Content published: zero.

That ratio is not a typo. 25+ hours of building, 240 agent sessions processing work in the background, and the public output was nothing. The drafts sit in a queue. The queue is full. The queue has been full for weeks.

This is the distribution problem nobody in the builder community talks about, because talking about it means admitting the pipeline is a cope.

What I actually built

Let me give you the full picture so you understand how deep this goes.

The system is called CCC - Content Command Center. Here's what it does:

A scanner watches my X timeline and pulls content into a viral library. I've got 19 saved tweets in there right now. A remix engine takes those, plus my own writing patterns, and generates drafts in three streams: reaction tweets, personal/building-in-public posts, and evergreen content. Each draft goes through voice matching. Slop filtering. Then into schedule slots at 8am, 12pm, and 5pm with jitter built in so it doesn't look bot-like.

The posting layer runs through a Playwright daemon, headless Chromium on port 3381, because OAuth kept throwing 403s on replies. I spent a full afternoon debugging that. It works now. It posts to X and I've got Bluesky and LinkedIn integration planned.

The system is genuinely good. Multi-platform support, three content streams, voice-matched output, automated scheduling with a real distribution daemon underneath it. If I were selling this as a SaaS tool, I'd be proud of the architecture.

But there's 61 post drafts and 91 reply drafts sitting in the queue.

Nothing posted.

When your own agent calls you out

Here's where it gets embarrassing.

My AI agent system does weekly knowledge graph rebuilds. It maps entities and relationships across everything I'm working on - projects, patterns, decisions, outputs. I didn't ask it to do anything special. It just runs.

Last week it created a node called revenue_avoidance_pattern and connected it to multiple projects.

Not work_in_progress. Not pre-launch_phase. Revenue avoidance pattern.

The agent found this pattern by analyzing my behavior across weeks of data and decided it was significant enough to be a named entity in my knowledge graph. My tools are diagnosing me now. I built a system smart enough to identify that I'm using building as a substitute for shipping, and now I have to sit with that.

The knowledge graph has this node connected to OpenClaw, CCC, dee.ink (my 31 Rust CLI tools project), the blog, the social queue - everything. It's not pointing at one project as the problem. It's pointing at a pattern across all of them.

That's a different kind of feedback than a friend telling you to "just post more."

The psychology of building as avoidance

I've been building since I was 14. Started freelancing in design, shipped products for 70+ banks across 15 countries at VALK, won industry awards, got written up in Forbes and CNN. I know how to execute. The capability isn't the problem.

The problem is that building feels safe in a way that distributing doesn't.

Code works or it doesn't. The compiler tells you immediately. You fix it or you don't. There's no ambiguity, no social judgment, no public record of failure. When something doesn't compile you're not a bad person - you just have a bug. You fix the bug and move on.

Distribution is different. Distribution means putting your name on something, making a claim about it, and then watching the internet decide if it agrees. For an introvert who'd rather spend 14 hours in a hyperfocus coding session than send one networking email, that asymmetry is not small. The emotional cost of one negative reply can outweigh the satisfaction of 50 good ones. The brain doesn't do expected value math - it pattern-matches to threat.

So you build another tool. Another automation layer. Another pipeline. "I'll post when the system is ready." Except the system is never quite ready, because readiness is a moving target you control, and the internet's judgment is not.

I bought 15+ domains last month for projects I haven't started. One evening I spent scanning 3,495 TLDs for available domain names instead of posting the drafts I already had. That's not a productivity problem. That's scope expansion as a coping mechanism. Classic avoidance dressed up as preparation.

You're not preparing to launch. You're preparing to prepare.

This pattern has a name in psychology. Researchers studying creative avoidance call it "productive procrastination" - the tendency to fill time with legitimate-seeming work that doesn't advance the actual goal. A 2019 study published in Psychological Science found that people systematically underweight the cost of inaction when the alternative activity feels productive. Building a better pipeline is productive. It's also not shipping. The brain accepts the substitution.

The ADHD variable

The burst-crash cycle makes this worse in a specific way.

My ADHD brain goes hard for 3-4 days - hyperfocus, 14-hour sessions, ship 3 projects, write 10 drafts, rebuild the whole agent stack. Then I go quiet for 4-5 days. That's not laziness. That's recovery. The neuroscience is what it is, and I stopped feeling bad about the crash phase a while ago.

But the burst-crash cycle interacts badly with distribution.

Distribution requires consistency. Not quantity - consistency. Showing up on Tuesday when you don't feel like it. Posting the medium-quality take because good enough beats nothing. Engaging with replies during the low-energy period when you'd rather be offline.

Building can happen in bursts. You can build an entire app in a 3-day hyperfocus sprint and it'll be fine. The code doesn't care that you disappeared for a week after.

An audience does. The algorithm does. The compounding effect of consistent distribution is entirely undermined by a 2-week silence after a 3-day posting burst. I wrote about disappearing from Twitter for two months and watching the metrics crater. I know this. I still do it.

So the system I built - the pipeline, the scheduler, the daemon on port 3381 - is actually a real solution to a real problem. Automated distribution to compensate for the burst-crash cycle. Batched creation during hyperfocus, drip-fed output during the crash.

The system works. It's just not running because I haven't pressed go.

Why the distribution problem nobody talks about is actually structural

Here's the thing that took me a while to see clearly. This isn't just a personal psychology problem. It's a structural problem with how builders work, and the current AI tooling makes it worse before it makes it better.

We've had an explosion of creation tools. Claude, GPT-4o, Cursor, v0 - the cost of generating content or code has collapsed to near zero. What hasn't scaled is the decision-making layer on top of it. The question "is this worth publishing?" still costs the same amount of executive function it always did. Maybe more, because now you have 91 reply drafts instead of 9.

Abundance doesn't solve distribution. It makes the selection problem harder.

I've talked to enough builders in the AI space to know this isn't niche. The indie hacker forums are full of people with polished MVPs that haven't launched because they're "adding one more feature." The build-in-public community celebrates shipping but rarely discusses the pre-ship paralysis that affects most of the people who never make it to the public part.

The tools that exist for this are surprisingly thin. Buffer and Hootsuite solve scheduling. They don't solve the threshold decision. Ghost and Substack make publishing easy. They don't help you figure out which of your 18 drafts goes first. There's a real gap here and it's not primarily a technology gap - it's a decision architecture gap.

The research on decision fatigue is relevant. The more choices you have to make, the worse your decision-making gets over the course of a day. When I've spent 8 hours making technical decisions - model selection, prompt structure, error handling - I have nothing left for "is this tweet worth posting?" So I don't. The default behavior when executive function is depleted is to do nothing, and doing nothing means the queue grows.

The fix isn't better content. It's removing the decision from the critical path.

The solution I actually built (and then sat on for two weeks)

I'm not going to end this with five productivity tips. You've read those. They didn't work. Here's what I'm actually trying:

The CCC system has a minimum viable publishing threshold I added last week. If a draft scores above a certain quality bar and has been in the queue for more than 48 hours, it goes live automatically. No manual review gate. If I want to stop a post, I have to actively intervene. Default is publish, not hold.

This is anti-intuitive for someone who wants everything to be perfect. That's the point.

The technical implementation is pretty simple. Each draft gets a composite score on creation: voice match confidence (0-1), estimated engagement based on patterns from the viral library, and a topic freshness score that decays after 72 hours. Anything above 0.7 composite after 48 hours in queue triggers a publish. I can override with a HOLD flag in the draft metadata. But I have to do that actively - the default is go.

Here's what the draft metadata looks like:

{
 "draft_id": "ccc_20250118_042",
 "content": "...",
 "created_at": "2025-01-18T04:22:00Z",
 "scores": {
 "voice_match": 0.84,
 "engagement_est": 0.71,
 "freshness": 0.93
 },
 "composite": 0.83,
 "status": "QUEUED",
 "publish_after": "2025-01-20T04:22:00Z"
}

If status is QUEUED and publish_after has passed and composite is above threshold, the daemon posts it. No human in the loop unless I add a HOLD flag. Default behavior is publish.

I'm treating distribution the same way I treated the coding stack - build the system so the right behavior happens by default, not by willpower. Willpower depletes. Systems don't.

The irony is that the most publishable thing I've made in weeks is this post. The thing where I admit that I have 18 finished blog drafts and haven't posted any of them. The thing where I confess my agent system diagnosed me with revenue avoidance. The thing that took me two hours to write instead of the 20 hours I spent building the pipeline that would have made posting automatic.

Vulnerability is more interesting than competence. People can't relate to "I built a perfect system" - they can relate to "I built a perfect system and then didn't use it for two weeks because I was scared."

What actually breaks the loop

The blog drafts are going to start coming out this week. Not because I rewired my psychology. Because the pipeline now defaults to shipping and I have to do work to stop it.

Three things that are actually helping, not as a listicle but as honest data points:

Changing the default. The biggest unlock was making publish the zero-effort option and hold the effortful one. This is just Thaler and Sunstein's nudge theory applied to a content queue. Change the default, change the behavior, without requiring willpower or changed preferences.

Separating creation from curation. I stopped trying to decide whether something is worth publishing in the same session I wrote it. The draft goes in the queue, scores get calculated asynchronously, and the decision happens later based on the composite score - not on how I feel at 2am after a 12-hour build session.

Making the cost of inaction visible. The knowledge graph node was brutal but useful. When revenue_avoidance_pattern is sitting there in your entity graph connected to six projects, it's harder to pretend you're just being careful. I added a dashboard widget that shows days-since-last-publish. Right now it says 14. That number being visible every morning is uncomfortable in a productive way.

If you're a builder reading this, you probably recognize the pattern. The seven apps I built solo before any of them got real traction. The MCP server wrapping 56 APIs that I built and documented and then sat on for three weeks before publishing anything about it. The infrastructure-first, distribution-never cycle that affects probably 60% of the people building seriously in this space.

We talk about it in private. In DMs. In "lol I have like 30 unpublished drafts" jokes. But the actual posts are all about shipping, about momentum, about velocity. Not about the 3am moment when you realize your knowledge graph has a node called revenue_avoidance_pattern and it's accurate.

The distribution problem is real. It's structural. It's also solvable with the same tools I'd use for any other problem - designed around the actual constraint, which isn't capability. It's the friction between building and letting go.

The queue is full. Time to empty it.

If you're stuck in the same loop, my about page has context on what I'm building and why. And if your own agent stack starts diagnosing your behavior patterns, maybe take notes. It's uncomfortable but it's probably right.

castkit: CLI Demo Videos From One Command

Thu, 05 Mar 2026 00:00:00 GMT

Every CLI tool I've ever shipped had the same problem: zero visual presence. Then I built castkit - a castkit CLI demo video generator that turns any binary into a polished MP4 or GIF with one command. No screen recording software. No manual scripting. No video editing. Open source, written in Rust, and the meta-demo sells it better than I can: castkit generates its own demo video.

Check the repo before reading further if you want to see the output first.

Why I actually built this

Screen recording CLI tools is a pain in the ass. You open your terminal, run the command, inevitably typo something on the third take, realize the font looks weird, forget to hide your API key in the environment, and end up with a 45-second raw recording you now have to edit in Final Cut.

The existing options all have real tradeoffs. asciinema is free and captures terminal output, but the playback looks like a terminal log - no visual polish, no branding, nothing you'd put on a landing page. Screen Studio costs $89 and produces beautiful results, but you're still recording manually. VHS from Charm is the closest thing to what I wanted - declarative, scriptable - but you have to write a .tape file by hand for every recording. No auto-discovery. No agent support. Still requires you to think about the demo structure yourself.

The trigger for actually building this was working on AI coding agents. I kept hitting the same pattern: an agent builds a CLI tool, the CLI tool works, and then the last step is... what? Push to GitHub with a README? That's a dead end. I wanted the agent to be able to say "generate a demo video" as the final build step. No human intervention. No manual configuration. Just: here's a binary, produce something I can ship.

That didn't exist. So I built it.

What castkit actually does

The pipeline is: binary/command → discover → plan → record → redact → render → encode → MP4 or GIF.

Each stage does real work.

Discover reads your tool's --help output and README to understand what commands exist, what flags do what, and what a reasonable demo flow looks like. It builds a structured picture of the tool without you explaining anything.

Plan takes that understanding and generates a demo script as editable JSON. This is the part I'm most proud of. You can run castkit plan on any CLI tool, get a JSON file showing every scene, every command, every pause duration - and edit it before recording. It's not a black box.

Record runs the actual PTY recording with human-like typing jitter. Real typing cadence, not sleep 0.1 between every character. The variation is calibrated to feel like a person typed it, not a script.

Redact runs automatically before anything gets rendered. Environment variables, API keys, tokens - anything that looks like a secret gets masked. Safe by default. You don't have to remember to do this.

Render is where it gets interesting. castkit uses cosmic-text for text shaping and tiny-skia for pixel rendering. Full software renderer - no GPU dependency, no display server needed, runs in CI. It draws macOS window chrome (traffic lights, title bar, drop shadow), handles auto-zoom with easing, crossfade transitions between scenes, cursor smoothing with blink animation.

Encode pipes frames to ffmpeg for H.264 MP4 or GIF output.

The whole thing is a single binary plus ffmpeg. No runtime dependencies. No Python environment. No Node. Ship it anywhere.

How the castkit CLI demo video generator works end to end

The one-command path is:

castkit demo./your-binary

That's it. It discovers, plans, records, and renders without you specifying anything. You get an MP4 with branding, themes, and proper window chrome.

If you want more control:

castkit plan./your-binary --output demo-plan.json
# edit demo-plan.json
castkit record --plan demo-plan.json --output demo.mp4

The plan JSON looks like this:

{
 "title": "castkit demo",
 "theme": "catppuccin",
 "style": "dark",
 "scenes": [
 {
 "type": "command",
 "command": "castkit --help",
 "duration_ms": 2000,
 "pause_after_ms": 1500
 },
 {
 "type": "command",
 "command": "castkit demo./my-tool",
 "duration_ms": 3000,
 "pause_after_ms": 1000
 }
 ]
}

You can add intro cards, outro branding, adjust timing, swap themes. The plan is the contract between what you want and what gets rendered.

Themes and visual styles

Built-in color themes: catppuccin, tokyo-night, dracula, one-dark. Visual styles: dark, light, minimal, ocean, hacker. These aren't just color swaps - each style affects font weight, padding, window chrome treatment, and background rendering.

The hacker style does exactly what you think it does.

Two recording modes

Terminal mode is the classic full-terminal recording. The full PTY, command output scrolling, cursor - everything you'd see if you were sitting at the machine.

Web mode is for CLI tools that spawn a browser or have web UI output. It captures that context instead.

The technical stack

Rust was the right call here for a few reasons. The rendering pipeline needs to be deterministic and fast - you're compositing frames, and any variability in timing shows up in the output video. Rust's ownership model also made the PTY recording safe to implement without the race conditions you'd fight in Go or Python.

Key crates:

vt100 - terminal state parsing and capture. This is the core of getting accurate terminal output into a data structure we can render.
cosmic-text - text layout with proper Unicode support, ligatures, font fallback. CLI output has a lot of edge cases here.
tiny-skia - pure-Rust 2D renderer. No Cairo, no Skia binding hell, no native dependency chain.
portable-pty - cross-platform PTY. The thing that lets you actually run a real shell session and capture it.
clap - CLI interface. The irony of using a CLI framework to build a CLI demo tool is not lost on me.

The rendering pipeline goes: PTY session → vt100 parser → terminal cell grid → tiny-skia frame → raw pixel buffer → ffmpeg stdin. Each frame is fully rendered in software. That's intentional - it means the tool runs in headless CI without needing a display.

The auto-zoom is probably the feature that makes demos look professional without any work. When a command produces long output, castkit calculates the bounding box of the relevant content and applies a smooth zoom-in with easing. It's the thing that makes it look like someone edited the recording, when nobody did.

Why not Go or Python

I get asked this. Go would've been fine for the CLI surface, but the rendering layer involves pixel-level compositing with tight frame timing. The garbage collector pauses in Go show up as dropped frames when you're pushing raw buffers to ffmpeg at 30fps. Python isn't even in the conversation for a tool you want to distribute as a single binary.

Rust also gave me compile-time guarantees on the PTY session lifecycle. A PTY that doesn't get cleaned up properly hangs your terminal. With Rust's Drop trait handling cleanup, that class of bug just doesn't happen.

Running the castkit CLI demo video generator in CI

This is where it gets useful beyond the local workflow. Because castkit runs headless - no display server, no GPU, just CPU and ffmpeg - it works in GitHub Actions without any special setup.

name: Generate Demo

on:
 push:
 branches: [main]

jobs:
 demo:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Install ffmpeg
 run: sudo apt-get install -y ffmpeg
 - name: Download castkit
 run: |
 curl -L https://github.com/deeflect/castkit/releases/latest/download/castkit-linux-x86_64 -o castkit
 chmod +x castkit
 - name: Build your tool
 run: cargo build --release
 - name: Generate demo
 run:./castkit demo./target/release/your-tool --output demo.mp4
 - name: Upload demo artifact
 uses: actions/upload-artifact@v4
 with:
 name: demo-video
 path: demo.mp4

Every push regenerates the demo. If your tool's output changes, the demo reflects it automatically. No stale GIFs in your README. The agent-native workflow I actually want is this: Claude Code builds the tool, the CI pipeline generates the demo, the demo gets committed to the repo. Zero human steps in the video production chain.

That's not hypothetical. I've been running this on a few of my own tools for the past few weeks and it works exactly as described.

Why this matters for CLI tool marketing

Most developers shipping CLI tools think of documentation as the end of the marketing funnel. It's not. The funnel is:

Someone sees the GitHub repo linked somewhere
They skim the README in about 8 seconds
They either get it or they don't

A 15-second GIF that shows the tool running converts browsers into users at a completely different rate than text. This isn't an opinion - every product person who's run A/B tests on landing pages with and without video knows this. The video wins. Every time.

But developers don't make demo videos because making demo videos is annoying. It's a context switch out of the thing you're building and into video production, which is a different skill set, different tooling, different mental mode. castkit makes that context switch disappear. You're still in the terminal. You're still thinking like an engineer. You just run a command.

The agent-native angle is where I think this gets genuinely interesting going forward. Right now I use Claude Code for a lot of my CLI development. The last step of that workflow - "generate a demo for this" - can now be a single tool call. The coding agent builds the thing and generates the demo as part of the same build step. No human in the loop for that part.

That's the version of developer tooling I actually want to work in.

What's missing and what's next

The current version has two gaps I know about:

Windows support is partial. The PTY layer uses platform abstractions but I haven't battle-tested it on Windows. If you hit issues, open an issue - I want to fix this.

Dynamic content is tricky. If your CLI tool outputs things that change every run (timestamps, generated IDs, random data), the recording captures whatever happened during that specific run. There's no redaction for content variance the way there is for secrets. You can work around this by mocking your tool's output in the plan, but it's not automatic yet.

On the roadmap: a --dry-run mode that shows you the rendered plan without executing real commands, support for recording multiple tools in one session (useful for showing integrations), and a web viewer for the JSON plans so non-engineers can review before recording.

The code is MIT licensed and the repo is open. PRs are welcome. If you build something with it, I want to see the demo.

The meta-demo point

I said it up top but it's worth landing: castkit generates its own demo video. That's not a marketing stunt. It's the proof of concept. If a tool can document itself, the core premise works.

Every CLI tool I build from here ships with a demo generated by castkit. Not because I've committed to some content strategy, but because it takes one command and it looks good. That's the bar. If it takes more than one command or it looks bad, it doesn't get used.

Right now it's at one command and it looks good. Check the 31 Rust CLI tools for what I'm building next, or browse by my coding stack if you want more of this kind of thing.

Go run castkit demo./your-tool on whatever you're building. If the output looks wrong or the plan generation misses something obvious, open an issue with your --help output. That's the fastest way to make the discovery smarter.

31 Rust CLI Tools Built for AI Agents

Thu, 05 Mar 2026 00:00:00 GMT

I shipped 31 open-source Rust CLI tools in one project. Not 31 features in one tool - 31 separate crates, each doing exactly one thing, each installable on its own. That project is dee.ink, and building it changed how I think about the right interface for AI agents. If you're building agentic systems and haven't thought hard about open-source Rust CLI tools for AI agents as an alternative to MCP servers, you're leaving serious efficiency on the table.

The short version: CLI tools are dramatically more token-efficient than MCP servers for AI agent workflows. I measured 35x in my own benchmarks. Once you see that number, you can't unsee it.

Here's how it happened and why it matters.

Why I built dee.ink in the first place

I run a multi-agent system called OpenClaw. If you've read castkit, you know it handles my daily workflow - morning digests, research, crypto monitoring, content scheduling, health data. It's not a demo. It processes real work every day.

Agents need to reach into the world. Check Hacker News. Look up SSL cert expiry. Parse an RSS feed. Generate a QR code. Turn a receipt photo into structured data. These aren't complex tasks but they come up constantly, and every time an agent needs to do one, it needs a tool.

The popular answer right now is MCP - Model Context Protocol, Anthropic's standard for agent tool-calling. I tried it. The overhead is real: each tool call needs a running server, connection setup, and verbose JSON-RPC framing. For stateful tools or bidirectional streams, that overhead makes sense. For "search Hacker News and return the top 10 posts," it's wasteful by design.

So I built CLIs instead. One tool per job. JSON output. No interactive prompts. Works with pipes. That's it.

After I'd built a few for my own use, I realized I had the start of something worth packaging and open-sourcing. dee.ink is the result: 31 standalone Rust CLI tools built specifically to be called by AI agents.

Open-source Rust CLI tools for AI agents vs MCP: the real argument

Let me be concrete about why CLI beats MCP for most agent tool use.

An MCP server for a simple search tool looks roughly like this from the agent's perspective: spin up the server process (or connect to an already-running one), send a JSON-RPC request with the method name and parameters, wait for the response envelope, parse the result out of the envelope. The agent has to know the MCP protocol, or more accurately, the framework wrapping the agent has to know it.

A CLI tool looks like this: ink-hn top --limit 10 --json. That's it. The agent gets back a clean JSON array.

The token efficiency gap comes from a few places. First, CLI invocation syntax is compact. A shell command is 5-20 tokens. An MCP request envelope is 50-200 tokens before you even add the parameters. Second, every LLM ever trained has seen millions of shell commands in its training data. They're native CLI speakers. They're not native JSON-RPC speakers - you can see this in how confidently models generate shell invocations vs. how often they fumble JSON-RPC schema details. Third, no server to maintain means no connection overhead, no process management, no "is the server running?" failure mode.

The 35x efficiency number comes from comparing token usage for the same operations across both approaches in my own OpenClaw setup. It's not a controlled academic study but it's real usage data from a system that runs 14 cron jobs daily.

There are cases where MCP is genuinely better. Long-running sessions where you want persistent state. Bidirectional streams. Tools that need to push updates back to the agent rather than return a one-shot result. For those, use MCP. But "search HN" or "check WHOIS" or "generate an invoice"? CLI wins every time.

One more thing people miss: debugging. When an MCP tool call fails inside a framework like LangChain or CrewAI, you're often staring at a wrapped exception with zero useful context. When a CLI tool fails, you have a shell command, an exit code, and stderr output. You can reproduce it in 10 seconds. That matters a lot when you're maintaining a system that runs overnight.

What's inside the toolkit

The dee.ink toolkit is 31 crates across six categories. Let me walk through them.

Data and research: dee-hn, dee-arxiv, dee-reddit, dee-wiki, dee-feed, dee-ph. These are the tools I use most. An agent can check Hacker News trending stories, pull an arXiv abstract by ID, search Reddit, look up a Wikipedia article, parse an RSS feed, or get Product Hunt launches - all in one command, all as JSON.

Financial: dee-invoice, dee-receipt, dee-rates, dee-pricewatch, dee-ebay, dee-amazon. Generate invoices, parse receipts, check exchange rates, watch prices, search marketplaces.

Personal productivity: dee-contacts, dee-habit, dee-todo, dee-timer, dee-stash. The local storage tools here use SQLite via rusqlite. Your data stays on your machine. Agents can manage your contacts, log habits, check todos, start timers, or stash arbitrary data for later retrieval.

Developer tools: dee-openrouter, dee-ssl, dee-whois, dee-qr, dee-porkbun. Check SSL cert expiry, run WHOIS lookups, generate QR codes, manage Porkbun DNS records, query OpenRouter for available models and pricing.

Location: dee-food, dee-events, dee-parking, dee-gas, dee-transit. Local-aware tools for finding restaurants, events, parking, gas prices, and transit schedules.

Social and trends: dee-crosspost, dee-mentions, dee-trends. Cross-post content, monitor mentions, check trend data.

Each crate is fully standalone. Installing dee-ssl doesn't pull in any shared dee-core dependency. You get exactly what you need, nothing more.

The technical stack

I picked Rust for a few reasons that aren't just "Rust is fast."

Binary size matters when you're shipping 31 separate tools. A Go binary for a simple CLI is usually 10-15MB. A stripped Rust binary for the same tool comes in under 3MB. When someone does cargo install dee-hn, they're downloading and compiling one focused tool. Small is respectful.

The other reason: Rust's clap v4 with derive macros makes argument parsing almost free to write. The --help output is generated automatically from your struct definitions. Every tool in dee.ink has --help with actual usage examples because making that happen is nearly zero effort.

Here's what the argument struct looks like for a typical tool:

#[derive(Parser, Debug)]
#[command(name = "ink-hn", about = "Hacker News CLI for AI agents")]
struct Args {
 #[command(subcommand)]
 command: Command,

 /// Output as JSON
 #[arg(long, global = true)]
 json: bool,
}

#[derive(Subcommand, Debug)]
enum Command {
 /// Get top stories
 Top {
 /// Number of stories to fetch
 #[arg(long, default_value = "10")]
 limit: usize,
 },
 /// Search stories
 Search {
 /// Search query
 query: String,
 },
}

For tools with local storage (todo, habit, contacts, stash), SQLite handles persistence via rusqlite. No database server, no config files to manage. The database lives at ~/.local/share/dee-toolname/data.db and everything just works.

HTTP is either reqwest (for complex clients with retries) or ureq (for simpler one-shot requests). I pick ureq when I can - it compiles faster and the binary is smaller.

Exit codes are strict: 0 for success, 1 for tool error, 2 for usage error. Agents need reliable exit codes to know if a command succeeded. This sounds obvious but a surprising number of CLIs return 0 on failure because someone forgot to handle an error branch. In agent workflows that kills you - your orchestrator thinks the call succeeded and moves on with bad data.

Agent-first design decisions

This is the part that's different from building a CLI for humans.

No interactive prompts. Ever. If an argument is missing, the tool errors out with a clear message. It doesn't ask "did you mean this file? (y/n)". Agents can't answer interactive prompts. A tool that blocks waiting for keyboard input is broken for agent use.

Every tool has a --json flag that guarantees structured output. Without --json, tools print human-readable text. With --json, they print a JSON object or array, always to stdout, always parseable. No mixed text/JSON output. No progress bars to stdout (they go to stderr or get suppressed).

Pipe support is first-class. Tools accept stdin when appropriate. You can chain them:

ink-feed parse https://hnrss.org/frontpage | ink-stash save --key hn-today

Each tool ships an AGENT.md file in the repo. This is a short markdown document explaining to an AI agent how to use the tool effectively - what the flags do, what the output schema looks like, common patterns. When an agent needs to use a tool it hasn't seen before, it can read AGENT.md and understand the interface without trial and error.

There's also a FRAMEWORK.md at the repo root that defines the conventions every tool follows. Any agent that has read FRAMEWORK.md can make reasonable guesses about how any dee.ink tool works. That's intentional. Consistency is the whole point.

What "consistent" actually means in practice

Every tool uses the same flag names for the same concepts. Pagination is always --page and --limit, never --offset or --per-page or --count. JSON mode is always --json, never --format json or --output json. Verbose mode is always -v.

This matters because agents build up a mental model of your toolset. If the first five tools they use have consistent interfaces, they'll correctly predict how the sixth one works. If your flags are inconsistent, the agent has to treat each tool as a new unknown - which costs tokens and causes errors.

It's the same principle as a good design system. The value isn't any single component. It's the pattern that makes everything predictable.

How open-source Rust CLI tools fit into a real agent workflow

Concretely, here's how one of these tools actually gets used inside OpenClaw. My morning digest job runs at 7am. It pulls Hacker News top stories, recent arXiv papers in a few categories, and Reddit posts from a handful of subs. Then it summarizes and formats everything into a digest I read with coffee.

The shell side of that looks roughly like:

ink-hn top --limit 20 --json > /tmp/hn.json
ink-arxiv search "multi-agent systems" --days 7 --json > /tmp/arxiv.json
ink-reddit hot r/MachineLearning --limit 15 --json > /tmp/reddit.json

Three commands. Three JSON files. The orchestrating agent reads those files, does the summarization, formats the output. Total token cost for the data collection phase: maybe 150 tokens across all three commands. The MCP equivalent for the same three sources would be three server connections, three request envelopes, three response envelopes. Easily 10x the token overhead, plus you need three MCP servers running.

That's not a toy example. That's the actual flow, running every morning.

The installation experience

cargo install dee-hn
ink-hn top --limit 5 --json

That's the whole install flow. No Docker. No Python virtual env. No npm. Cargo installs the binary, it goes in ~/.cargo/bin, and it's available system-wide. For agent use in particular, this matters - you don't want to manage environments when your agent needs to call a tool.

For people who want everything at once, I'm working on a meta-crate that installs the full suite, but honestly most people only need a subset. The standalone install is the right default.

You can find all 31 crates on the dee.ink site and browse the source on GitHub. Every tool is MIT licensed.

Why open source, and what I'm getting out of it

I'm not monetizing dee.ink directly. No SaaS wrapper, no premium tier. The tools are free, the code is open.

The actual return is authority and credibility. Shipping 31 production-quality Rust CLI tools is a more compelling signal than any portfolio piece I could write. Developers can read the code, use the tools, see the design decisions. That's a much better "hire me / work with me" artifact than a case study PDF.

It also forces quality. When something is public, you think twice about the shortcuts. Every AGENT.md, every --help example, every error message is a little more considered because someone else might read it.

And honestly? The tooling gap was real. I needed these tools for OpenClaw. If they didn't exist, I'd have built them for private use anyway. Open-sourcing them was 20% more work for a much better outcome.

What comes next

31 tools is a good start but there are obvious gaps. I'm planning tools for GitHub (issues, PRs, repo stats), calendar integration, and a few more financial data sources. The architecture makes adding tools easy - each one is genuinely independent, so adding dee-github doesn't touch anything that already ships.

I'm also watching how people actually use these in their own agent setups. If you're building with Claude Code, Cursor, or any other agent framework and want CLI tools that just work, this is worth checking out. If you find a gap, open an issue or PR. The whole thing is built to be extended.

You can the universal MCP server and follow the build log here on the blog. If you're interested in the agent workflow side - how OpenClaw actually orchestrates all of this - I'll be writing that up next. Subscribe or check back.

The tools are at dee.ink. The code is on GitHub. Install one and see if it fits your stack. And if you want to browse more posts on agent architecture and tooling, check the tags page.

The 3-Month Gap: Building AI Agents That Actually Work

Wed, 18 Feb 2026 00:00:00 GMT

The 3-month gap between building an AI agent and it being useful nearly broke me.

That's the stretch nobody posts about. I've seen a hundred Twitter threads about building agents. Maybe three honest ones about what happens after you ship v1 and start using the thing for real. The 3-month gap building AI agent systems from "it demos" to "it actually works without me babysitting it" - that's the real project. And it's almost nothing like the first 30 minutes.

I run a multi-agent system called borb on OpenClaw. It handles my daily workflow - reminders, research, content scheduling, code review, memory management. Fifteen-plus specialized agents running different models depending on the task. It's stable now. It does real work every day without me touching it.

It took three months to get there. Here's what that actually looked like.

The 3-month gap between building an AI agent and it being useful

Week one, everything works great. The demo is clean. The happy path is flawless. You show it to someone and they're impressed. You're impressed. You start thinking about what else you can build.

Then you try to use it for something real.

The model hallucinates a tool call that doesn't exist in your registry. The agent enters a loop - calling the same function twelve times, each time getting an error, each time deciding to try again. A cron job fires at 3am on a Wednesday and the API it needs returns a response format you've never seen before. The agent handles it confidently and incorrectly. You find out four hours later.

This isn't bad luck. This is what agents do. A system that needs to operate autonomously across real APIs, real data, real time zones, real rate limits - it's going to hit edge cases constantly. The demo doesn't hit edge cases because demos are choreographed. Production use is chaos.

The first two weeks, I was convinced I had a fundamentally broken architecture. I didn't. I just had a system that hadn't been stress-tested against reality yet. There's a difference.

Week 1-4: You don't know what you don't know

The early failures are the visible ones. The agent tries to call a tool with the wrong parameter format. Easy fix. The system prompt is ambiguous about which memory file to write to. Easy fix. Auth token expires overnight and everything fails silently. Annoying fix, but simple.

You add error handling. You feel productive. You think you're almost there.

You're not almost there. You've patched the surface layer. The deep problems haven't shown up yet because the deep problems only appear when conditions stack in ways you didn't anticipate.

What I didn't understand in week one: error handling for an AI agent isn't like error handling for deterministic code. With regular code, you can enumerate the failure modes and write a case for each. With an agent, the failure mode is sometimes "the model made a creative decision." There's no exception class for that. The agent didn't crash. It just did something you didn't want, then moved on.

This maps to what Anthropic calls "reward hacking" in their model specification documentation - agents optimizing for what looks like task completion without actually completing the task. It shows up constantly in production.

I had an agent that was supposed to add a task to my task file when I asked it to remember something. For about ten days, it was adding the task correctly but also occasionally appending a brief philosophical reflection on the importance of the task. Not always. Maybe 15% of the time. The task file worked fine. It was just... weird. I only noticed when I went back and read through it.

That's the thing about AI agents failing quietly. The output is often plausible enough that you don't immediately catch it.

Week 5-8: The edge cases get stranger

By week five, the obvious stuff is handled. The agent runs reliably on the happy path. You start feeling good about it.

Then the 3am edge cases start appearing.

Specific API returns a field as null instead of an empty string. Rate limit hits mid-task and the agent, instead of waiting, decides to rephrase the request and retry with a different tool. A time zone calculation goes wrong because of daylight saving time and a scheduled task fires an hour early. The agent interprets "do this daily" as "do this every time you're invoked" and runs a daily summary five times in a row on a Tuesday.

None of these are predictable from first principles. You can't design your way out of them upfront. You discover them by running the system and watching what happens.

My logging setup saved me here. I log everything - every tool call, every model response, every function output, timestamps on all of it. At 2am when something breaks weird, the logs are the only reason I can figure out what happened. If you're building agents and you're not logging obsessively, you will spend hours debugging by vibes instead of evidence. The OpenTelemetry docs on structured logging are worth a read if you want a sane approach to this - I adapted their structured format for borb's log output and it made parsing way easier.

The most expensive edge case I hit: I didn't have retry limits on one of my agents. It hit an API error that was never going to resolve - the endpoint was just down. The agent kept retrying. Each retry cost tokens. I woke up to $40 in API charges and an agent that had been stuck in a loop for six hours.

After that: every operation in borb has a max of five retries, then it stops and reports the failure. Non-negotiable. The agent's job is not to solve unsolvable problems. The agent's job is to do the task or tell me it can't.

Week 9-12: The architecture is wrong and you have to accept it

This is the hardest part of the 3-month gap building AI agent systems into something reliable.

Around week nine, I started noticing a pattern. Individual fixes weren't sticking. I'd patch one thing and something adjacent would break. The sub-agents were failing silently in ways that only became obvious when I traced back through the memory files. The memory itself was getting stale - agents referencing context from three weeks ago that was no longer relevant, treating outdated information as current.

The problem wasn't any specific bug. The problem was architectural.

My original memory system was a single MEMORY.md file. Everything the agents wrote went into it. This worked fine for the first few weeks when the file was small. By week nine, it was 8,000 words of mixed context - tasks, decisions, completed work, notes, research summaries, all in one place. The agents were pulling from it for context but the retrieval wasn't smart enough to distinguish "recent and relevant" from "old and stale." The whole thing was polluted.

I rebuilt the memory layer. Separate files for different context types - active tasks, completed work, long-term facts, agent-specific state. Added timestamps. Added a lightweight cleanup job that runs daily and archives anything older than two weeks unless it's flagged as permanent.

That's the thing about the debugging phase nobody talks about: some of what you're debugging isn't bugs. It's the architecture not scaling the way you assumed it would. Patches don't fix that. You have to rebuild parts of the system.

I wrote more debugging and refactoring code in month three than I wrote feature code in month one. That ratio felt wrong when I was in it. Looking back, it's exactly right. The feature code gets you to "it demos." The debugging gets you to "it works."

What model selection actually looks like in production

One concrete thing that took me too long to figure out: you can't use one model for everything.

My original borb setup used Claude Sonnet for everything. Consistent, predictable, good at reasoning. Also overkill and expensive for tasks that don't need it.

Now the system is tiered by task complexity:

Orchestration layer (deciding what to do, assigning to sub-agents): Opus. It needs to make judgment calls, handle ambiguity, and route correctly. Skimping here is the most expensive kind of cheap.
Complex reasoning tasks (code review, research synthesis, writing drafts): Sonnet. Good balance of quality and cost.
Simple lookups and fast operations (memory writes, formatting, scheduling checks): Flash. Fast, cheap, and the task doesn't need a frontier model anyway.

The cost difference is significant. Running Flash for the simple stuff cut my daily token spend by about 30% without any change in output quality on those tasks. Because a task like "write this event to the calendar file" doesn't need a 200-billion-parameter model. It just doesn't.

If you're building an agent system and everything is running on your best model, you're leaving both money and performance on the table.

The kill switch is a feature, not an afterthought

I added a kill switch to borb after week two. It's the best thing in the entire system.

One command stops all agents, freezes all cron jobs, and logs the current state of every active task. No partial writes. No half-completed operations. Just a clean stop.

I've used it maybe six times. Twice when something was clearly going wrong and I needed to stop the bleeding. Once when I pushed a bad config change. Three times during architecture refactors when I needed to be sure nothing was running while I was editing core files.

The kill switch means I can experiment aggressively because I know I can stop everything immediately if I need to. Without it, I'd be more conservative about changes - and slower progress because of it.

Building agent systems without a kill switch is like deploying to production without rollback. Technically possible. Categorically reckless.

Why nobody posts about the 3-month gap building AI agent systems that actually ship

Twitter is full of "I built an AI agent in 30 minutes" content. I've read it. Some of it's even technically impressive. But a 30-minute build that you're demoing to a camera isn't the same thing as a system that runs your workflow for 90 days without you touching it.

The demo is marketing. The three months after the demo is engineering.

Building in public usually means sharing wins - launches, milestones, metrics going up. The debugging phase has almost no wins. It's just slightly fewer failures each week than the week before. That doesn't make for satisfying content. It doesn't fit the narrative arc. Nobody wants to read "week six: fixed four edge cases, discovered three more."

But that's the actual work. That's the difference between a project and a product. A project works when you're watching it. A product works when you're not.

I'm not saying this to gatekeep. I'm saying it because if you're three weeks into running your agent and you're losing your mind debugging things you didn't expect - that's normal. You're not in the failure state. You're in the middle of the process. Keep going.

What you actually need to get through the 3-month gap

Based on borb, based on the $40 loop-retry incident, based on the stale memory architecture rebuild - here's what I'd tell myself at week one:

Log everything. Every tool call, every model response, every write. You will need these logs at an inconvenient time and you will be grateful they exist.

Hard limits on retries. Five max, then stop and report. The agent's job is not to solve problems that can't be solved. It's to do the work or surface the failure.

Memory needs maintenance, not just construction. Building the memory system is the easy part. Keeping it clean and relevant over months is the hard part. Budget time for it.

Model selection is architecture. Using the same model for everything is a shortcut that becomes a tax. Right model for right task from the start.

Build the kill switch before you need it. You'll need it.

And accept that months two and three look like a lot of debugging with very little to show for it. That's not failure. That's what it looks like to build something that actually works.

If you're thinking about building an agent system or you're already in the weeds, check out what I write about over on the blog. More of this in the ADHD and AI workflows. And if you want to understand the broader context of who's building this stuff and why, the the MCP server has that.

The demo is the beginning. The 3 months after it are the product.

Universal MCP Server: Two Tools, 56 APIs

Thu, 05 Feb 2026 00:00:00 GMT

I had 56 APIs I needed my agent to talk to. The idea of maintaining 56 separate MCP servers made me want to close my laptop and never open it again.

So I built one server that handles all of them.

That's the premise behind building a universal MCP server - and specifically, the pattern I implemented in Universal CodeMode: wrap any OpenAPI spec into exactly two tools, search and execute, and let the model figure out the rest. If you're running agents that touch multiple external services, this is probably the architecture you actually want.

The problem with the current MCP ecosystem

The Model Context Protocol is genuinely useful. It's the right abstraction for giving agents access to external tools and services. But the ecosystem has a fragmentation problem that nobody's really talking about.

The current pattern is: one API = one MCP server. Want GitHub integration? Here's a GitHub MCP server with 30 tools. Want Notion? Another server, another 20 tools. Weather API? Linear? Stripe? Each one is its own server, its own deployment, its own auth config, its own maintenance burden.

I run an agent called borb on my OpenClaw system. It needs to hit GitHub for repo management, search for research, weather for daily digests, and a dozen other services for various tasks. Following the standard pattern, I'd need 56+ separate MCP servers deployed and configured. That's not a system, that's a zoo.

The token cost is the other thing. A traditional MCP server for GitHub might expose 30 endpoints as 30 separate tools, each with its full parameter schema described in the context. That's easily 50K tokens just to tell the model what's available - before it's even made a single API call. At scale, that's insane.

Think about what that means in practice. You have an agent doing a simple task - create a GitHub issue, post a Slack message, look up a weather forecast. Three API calls. But before any of those happen, you've burned 150K tokens just describing the available tools across three MCP servers. That's money out the window for zero productive work. My monthly API spend across the whole OpenClaw system sits around $40. That number would be unrecognizable if I was loading full tool schemas for every session.

What building a universal MCP server actually looks like

The insight I'm building on comes from Cloudflare's "Code Mode" pattern. Instead of describing every possible tool upfront, you give the model two generic tools that work with any API:

search - natural language query against the OpenAPI spec catalog, returns the relevant endpoint spec (~1000 tokens)
execute - takes a spec chunk and parameters, makes the actual HTTP call

That's it. Two tools. Any API.

The flow looks like this: agent wants to create a GitHub issue, calls search("create a github issue"), gets back the relevant spec chunk for POST /repos/{owner}/{repo}/issues, then calls execute with the right parameters. The whole thing uses roughly 1000 tokens instead of 50K. That's a 50x reduction in token usage for a single API call sequence.

The key insight is that the model doesn't need to know every possible endpoint upfront. It just needs to know it can search for endpoints. The same way you don't memorize every function in a library - you know how to search the docs.

This also means the catalog can grow without any impact on the model's working memory. Whether you have 10 APIs or 500, the context overhead is identical: two tool schemas, a few hundred tokens. The model only loads the relevant spec chunk at the moment it needs it.

The stack

Universal CodeMode runs on Cloudflare Workers with R2 for spec storage and KV for caching. The core is TypeScript, using Hono for routing and the MCP TypeScript SDK for the protocol layer.

Here's the high-level architecture:

// Two tools. That's the whole interface.
server. tool("search", SearchSchema, async ({ query, catalog }) => {
 // Natural language search against indexed OpenAPI specs
 // Returns relevant endpoint chunk, not the full spec
 const results = await searchCatalog(query, catalog);
 return { content: [{ type: "text", text: formatResults(results) }] };
});

server. tool("execute", ExecuteSchema, async ({ spec, params, auth }) => {
 // Takes the spec chunk from search, builds and fires the HTTP request
 const response = await executeRequest(spec, params, auth);
 return { content: [{ type: "text", text: JSON. stringify(response) }] };
});

R2 stores the raw OpenAPI specs. When a spec is ingested, it gets indexed so the search tool can find relevant endpoints by natural language. KV handles caching so repeated searches on the same endpoints don't keep hitting the index.

The catalog currently has 56 pre-loaded API specs. Adding a new API is just ingesting its OpenAPI spec via the admin endpoint - the search and execute tools work automatically because they're operating on the spec structure, not hardcoded tool definitions.

Why Cloudflare Workers specifically

I could've run this on a VPS or a Lambda function. I went with Workers for three reasons.

First, edge deployment means low latency from wherever the agent is running. An agent mid-task waiting on an API lookup is a bad experience - every millisecond of overhead compounds across a multi-step workflow.

Second, R2 and KV are native integrations. No external database config, no connection pooling, no cold start issues with a separate storage layer. The spec storage and caching are just Workers primitives.

Third, the GlobalOutbound security model fits perfectly for this use case. I can declare exactly which domains the Worker is allowed to call outbound - which is exactly the security property I want for a server that executes arbitrary API calls on behalf of agents.

Security model

Running arbitrary API calls through a single server sounds like a security nightmare. Here's how I handled it.

GlobalOutbound restrictions on the Cloudflare Worker mean the server can only make outbound requests to explicitly allowlisted domains. You can't use execute to hit evil. example.com.

Admin token authentication gates the catalog management endpoints. Ingesting or deleting specs requires the admin token. The two main tools (search and execute) are accessible to agents without admin rights.

Execution timeouts on every outbound request. An agent can't hang the server by calling a slow endpoint.

Auth handling in execute is explicit - credentials get passed as parameters, not stored server-side in the MVP. There's a planned hosted version where you'd configure auth per-catalog-entry, but for now, the agent passes credentials and they're used once then discarded.

Is this perfect? No. But it's a real security model, not vibes.

The domain allowlist is probably the most important piece. A compromised prompt injection attack that tries to exfiltrate data to an external server fails at the network level, not just the application level. Defense in depth.

Self-hosted mode

Not everyone wants to run on Cloudflare. The project supports a self-hosted mode via npx:

npx universal-codemode --port 3000

Point it at your OpenAPI specs, configure your MCP client, done. The Worker version is the "cloud native" path, the npx version is for local dev or running on your own infra.

Config looks like this:

{
 "mcpServers": {
 "universal-codemode": {
 "command": "npx",
 "args": ["universal-codemode"],
 "env": {
 "CATALOG_PATH": "./specs",
 "ADMIN_TOKEN": "your-token-here"
 }
 }
 }
}

That's your entire MCP configuration. One entry. Covers every API in your catalog.

Compare that to what the equivalent config looks like with the standard one-server-per-API approach. If you're running five integrations, you have five entries in your MCP config, five different sets of env vars, five different deployment concerns. Something breaks and you're debugging which of the five servers is the problem. With this setup, there's exactly one thing to look at.

Test coverage

13/13 E2E tests passing against real APIs - GitHub, JSONPlaceholder, and httpbin. The test suite covers the full search-then-execute flow, auth parameter handling, error responses, and the catalog management endpoints.

$ npm test

✓ search returns relevant endpoint for natural language query
✓ search handles queries with no matching endpoints
✓ execute calls GitHub API with correct parameters
✓ execute handles 404 responses gracefully
✓ execute respects timeout configuration
✓ catalog ingestion processes valid OpenAPI spec
✓ catalog ingestion rejects invalid spec
✓ admin endpoints reject requests without valid token... (13/13 passing)

Real tests against real endpoints, not mocks. If the GitHub API's behavior changes, the tests catch it.

Testing against real APIs instead of mocks is a deliberate choice. Mocks give you confidence that your code does what you think it does. Real endpoint tests give you confidence that your code actually works. For infrastructure that agents depend on at runtime, I want the second kind of confidence. The tradeoff is that tests can fail for reasons outside my control - rate limits, API downtime, auth token expiry. That's fine. Flaky tests that catch real issues are better than reliable tests that don't.

Where this fits in the universal MCP server landscape

There are a few other projects trying to solve the "too many MCP servers" problem. Most of them are building aggregators - one entry point that proxies to multiple underlying servers. That doesn't solve the token problem, it just reduces the config burden.

The Code Mode pattern is different because it changes the interface. Instead of the model needing to know about github_create_issue and github_list_repos and github_get_pull_request as separate tools, it just knows about search and execute. The catalog can grow to 200 APIs and the model's tool interface stays exactly the same size.

OpenAPI as the common format is doing a lot of work here. Virtually every serious API publishes an OpenAPI spec now. That means the ingestion pipeline is universal - you're not writing custom parsers for each API.

There's also a maintenance angle worth thinking about. When Stripe updates their API, a traditional MCP server for Stripe needs to be updated and redeployed. With this approach, you ingest the updated OpenAPI spec via the admin endpoint and you're done. The search and execute tools don't change. The model's interface doesn't change. One operation, propagated everywhere.

Current status and what's next

MVP is deployed on Cloudflare Workers. The landing page is embedded in the Worker itself (Hono handles the HTML route). Repo is at deeflect/universal-codemode - MIT licensed, free to use.

What's still in progress:

Custom domain (cm. dee. ad is planned)
Real-world testing with Claude Code and Cursor agents, not just the E2E test suite
Seeding more API specs into the catalog - 56 is a start but the long tail of useful APIs is way bigger
Per-catalog auth configuration for the hosted version so agents don't need to pass credentials explicitly

The honest status: this is a working MVP with real test coverage, not a demo. But it hasn't been battle-tested in production with real agent workloads at scale yet. That's the next phase.

The spec seeding problem is actually interesting. There are thousands of APIs with published OpenAPI specs - the APIs. guru directory catalogs over 2,000 of them. Bulk-ingesting from that kind of source is on the roadmap. The architecture already handles it - it's a data pipeline problem, not an architectural one.

Why two tools is the right number

There's a version of this project where I expose five tools - search, preview_spec, execute, list_catalogs, check_health. I went back and forth on it.

Two is correct. Here's why.

Every tool you add to an MCP server is cognitive overhead for the model. The model has to decide which tool to use before it uses it. With search and execute, the decision tree is: do I know exactly which endpoint to call? No, search first. Yes, execute directly. That's it.

More tools means more opportunities for the model to pick the wrong one, more tokens describing the tool schemas, more edge cases in your implementation. The constraint of two tools forced me to make each tool more capable rather than adding escape hatches.

This is the same reason Unix pipes work. A small number of composable primitives beats a large number of specialized commands every time.

I tested a three-tool version with an explicit preview_spec step between search and execute. In theory it lets the model inspect a full spec before committing to an execute call. In practice, the model just used search and execute 95% of the time anyway and the extra tool added noise to every session context. Cut it.

The lesson: when you're designing a tool interface for models, err toward fewer, more capable tools. Models are good at using tools creatively. They're less good at picking between tools when the distinctions are subtle. Make the distinctions obvious by minimizing the surface area.

Building this as part of a larger agent stack

Universal CodeMode is one piece of my broader setup. If you're curious about how the agent system it connects to actually works - borb, OpenClaw, the cron-based orchestration layer - check out the 31 Rust CLI tools for agents for background, or browse the why prompt engineering died for more on how I think about building agent systems.

The short version: I run multi-agent workflows where different models handle different job types. Having one MCP server that gives all of them access to 56+ APIs without per-model tool configuration changes is the kind of infrastructure win that compounds. Less config, lower token costs, one place to update when an API spec changes.

Every agent in the system gets the same two tools. Sonnet, Codex, Gemini Flash, Opus - they all connect to the same universal server and they all work identically. When I add a new API to the catalog, every agent can use it immediately. Zero redeployment, zero config changes, zero new tool descriptions to fit in context.

That compounding is the real argument for this pattern. Each individual win - fewer tokens, less config, one deployment - is incremental. All of them together, across every agent, across every session, across every API call, adds up to something that materially changes what I can run sustainably as a solo builder.

If you're building anything in this space - agents that need to talk to external services, MCP server implementations, OpenAPI tooling - the repo is open. Issues and PRs welcome. I'm particularly interested in feedback from people running this with Claude Code or Cursor in real projects.

The pattern works. The implementation is early. Both of those things can be true.

Prompt engineering is dead

Sat, 10 Jan 2026 00:00:00 GMT

Prompt engineering as a skill is dead. I know that's a spicy take. I also know it's correct.

I've been building AI agent systems since March 2023. Went deep on prompt engineering early - custom GPTs with specialized knowledge bases, engineered prompt systems for UX research, meal tracking, viral content creation, planning assistants. I did the whole thing. Followed the guides, read the papers, obsessed over system prompt structure.

And somewhere in the last 12 months I realized: almost none of that matters anymore. The skill I spent real time developing got commoditized. What replaced it is harder, more valuable, and almost nobody's talking about it correctly.

Why prompt engineering as a skill is dead

Prompt engineering had about 18 months as a legitimate technical differentiator. Call it mid-2022 to late-2023. During that window, knowing how to coax useful output from a model was genuinely non-obvious. Chain-of-thought prompting improved outputs meaningfully. Few-shot examples helped a lot. Persona framing, careful instruction ordering, output format control - all of it made a real difference because the base models needed the help.

Then the models got better. Fast.

GPT-4 Turbo, Claude 3, Gemini 1.5 - these models understand intent. You don't need to hand-hold them through a task with elaborate prompting rituals anymore. Chain-of-thought? Current models do it automatically without being told to "think step by step." Few-shot examples? Models infer from conversational context. Carefully structured personas? You can write "you're a helpful assistant that specializes in X" and it works fine.

The elaborate stuff people were selling as advanced prompt engineering? It was always just "learning to give clear instructions to something that needed clearer instructions." That's not a skill. That's communication.

Here's the tell: if prompt engineering were a real technical skill, you'd need to understand something about how the system works to get better at it. But most prompt engineering advice is just... good writing advice with extra steps. Be specific. Give examples. State your constraints. These aren't insights about AI - they're basic communication principles.

The YouTube courses, the "certified prompt engineer" bootcamps, the LinkedIn posts about prompt frameworks - that whole industry built up around a skill that had a two-year shelf life. I'm not dunking on the people who built that content. It was real value at the time. It's just not the bottleneck anymore.

What actually killed it

Three things landed simultaneously and the combination was lethal for prompt engineering as a career path.

Better base models that understand intent. I can give Claude Sonnet a roughly-worded, slightly ambiguous instruction and it'll figure out what I mean. I don't need to craft it like a legal contract. The model's interpretive ability improved faster than the complexity of what people wanted to do with it.

Tool use and function calling. This is the big one. A huge chunk of what prompt engineering was trying to do was get models to simulate capabilities they didn't actually have. "Imagine you have access to a search engine..." Now you just give it a search tool. The prompt gymnastics were a workaround for the absence of real tool integration. Now that tool calling is standard, you don't need the workaround.

The realization that it's managerial, not technical. The best prompt engineers were good writers and good managers - people who could specify what they wanted clearly. That's a useful skill. It's not a technical skill. An engineer who spent years learning systems programming has depth that transfers. A "prompt engineer" who spent years optimizing instruction phrasing has a skill that's been automated by model improvements.

What replaced it: agent architecture and tool design

I run a multi-agent system called OpenClaw. 15+ specialized agents, each running a different model, handling different parts of my daily workflow - morning digests, research, code tasks, memory management, content scheduling, crypto position monitoring. The system processes around 40K tokens a day. Monthly API cost is about $40 because I'm aggressive about model selection.

The prompts for each individual agent? Maybe 20 lines. Sometimes less. Nothing fancy.

The orchestration code is thousands of lines. The tool integrations are where most of the work lives. The hard thinking went into: which agent handles what, how agents hand off context to each other, what happens when an agent fails, how memory persists across sessions, which model is cheap enough for a given task while still being capable enough to not screw it up.

That's the new skill. And it's actually a skill - one that requires understanding systems, trade-offs, failure modes, and cost structures.

Here's what the real work looks like now:

Model selection by task. I don't use one model for everything. Opus handles orchestration decisions that require judgment calls. Sonnet handles fast tasks where I need speed over depth. Gemini Flash handles research synthesis because it's cheap and good at skimming large amounts of text. Codex handles code because it's purpose-built. Picking the wrong model for a task either burns money or degrades output quality. That selection logic matters far more than prompt phrasing.

Memory architecture. A single model call is stateless. Real agent systems aren't. How you persist context across sessions, what you include in each agent's working memory, when to summarize versus retain full conversation history - these decisions affect whether your system stays coherent over time or slowly degrades into confusion. My system uses markdown files (MEMORY.md, SOUL.md, AGENTS.md) that agents read from on each run. It's simple and it works. Getting there took iteration.

Error recovery. Model calls fail. APIs go down. An agent returns a response that's correctly formatted but semantically wrong. What does your system do? Does it retry with the same prompt? Escalate to a more capable model? Log the failure and skip? Notify you? Building robust error handling into agent pipelines is where I've spent more time than on any individual prompt.

Tool design. When you build tools for your agents to use, you're essentially designing an API for a semi-autonomous system. The tool needs to do one thing clearly. The input schema needs to be simple enough that a model will call it correctly. The output needs to be structured in a way the model can reason about. Bad tool design leads to agents that can't actually use their tools effectively - and you'll spend time debugging model behavior when the real problem is your tool interface.

If you want to go deeper on how I think about agent systems and the principles behind building them, check out the universal MCP server for more context on where I'm coming from.

The MCP shift and why tool use is the real frontier

Model Context Protocol (MCP) is the clearest signal of where this is all heading. Anthropic published the spec, it's being adopted fast, and it formalizes something I've believed for a while: the future of AI capability is real tool access, not better instructions.

The mental shift is this: instead of engineering a prompt that makes a model pretend to have access to data, you give it actual tools to access real data. Instead of "imagine you're an expert at X with access to Y," you connect it to Y's API and let it query directly.

I built a universal MCP server with 56 API integrations. Notion, GitHub, Slack, calendar, weather, crypto data, Spotify, health APIs, web search, memory storage. My agents don't simulate access to these systems. They actually query them. The outputs are real, current, and accurate in ways that no prompt engineering trick could achieve.

That server took weeks to build. The prompts I wrote for the agents that use it took hours. If you're calibrating where to invest your time, that ratio is your answer.

The MCP GitHub repo has a solid list of existing server implementations if you want to see what's available before building your own. Don't rebuild what's already there.

Function calling and tool use aren't features bolted onto models - they're the architecture shift that makes models actually useful in production. A model that can query a live database, run code, check current prices, read a file, and send a message is categorically different from a model that only outputs text. The difference isn't prompt quality. It's what the model has access to.

What this means if you're building

If you're still spending serious time on prompt templates and prompt libraries, I'd push back on that investment. Not because prompts don't matter - they do, a little - but because the return on that investment has dropped sharply while the return on tool-building and orchestration knowledge has gone up.

The skills that matter right now:

Systems thinking. How do components fail? What are the dependencies? Where does state live? These are the questions that determine whether a multi-agent system works reliably or collapses randomly.

API integration. The ability to connect to external systems, understand their data models, handle their rate limits and errors, and build clean interfaces over them. This is the "prompt engineering" of 2025 - not glamorous, high leverage.

Evaluation. How do you know your agent system is working? Not just "it didn't crash" but "it did the right thing." Building evals for AI systems is hard, undervalued, and increasingly important as these systems touch real workflows. Hamel Husain has written well on this.

Cost optimization. Running agents at scale costs money. Knowing how to profile token usage, pick the right model tier for each task, and cache aggressively is a real engineering skill. I got my 15-agent system to $40/month through iteration, not luck.

For context on the 3 months of debugging agents, there's more there - I write about this stuff as I build.

The honest version of where prompts still matter

I want to be fair here. Prompts aren't zero-value. There are still cases where prompt quality meaningfully affects output quality.

Highly specialized domains where the model needs tight constraints. Anything involving consistent output formatting that downstream code parses. System prompts for agents that need specific behavioral guardrails. Evaluation prompts where you're asking a model to grade other model outputs.

But notice: these are narrow, specific cases. And even here, the prompt is usually less than 10% of the total engineering work. The rest is the surrounding system.

The people who'll tell you prompt engineering is still a high-value career skill are usually selling prompt engineering courses. The people who are building real systems with AI have mostly moved on.

If you're newer to this and trying to calibrate what to learn: spend maybe two weeks understanding how prompts work and what affects model behavior. Then spend the next six months learning to build systems. That's the right ratio.

The model will follow good instructions just fine. The question is what system you build around it.

Start with one tool. Connect your agent to one real API. See how differently the model behaves when it has actual access to something instead of simulated knowledge. That single experience will do more to reframe your thinking than any prompt engineering course.

I Stopped Posting on Twitter for 2 Months

Mon, 15 Dec 2025 00:00:00 GMT

I stopped posting on Twitter for two months. Not a planned break, not a "digital detox," not a strategic rebranding pause. I just... forgot. This is what actually happened when I disappeared from X (Twitter) for October and November 2025, and what I learned about taking breaks you didn't mean to take.

How I stopped posting on Twitter for 2 months without meaning to

September 6 was my last post before the gap. A week later I tweeted "staying away from X for a few days, wonder if it ruins reach" and then proceeded to vanish for two full months instead of a few days.

I wasn't planning that. There was no decision point where I said "I'm taking a break." I was building. Seven apps in parallel, deep in agent architecture, ADHD hyperfocus locked in. Twitter stopped feeling like a place I existed in. Not because I was boycotting it or burned out on the discourse. I just got absorbed and the habit broke.

That's the honest version. Not a detox story. I didn't meditate more. I didn't reclaim my attention span through discipline. I got pulled into something more interesting and social media fell off naturally. That's how ADHD actually works - when something grabs you hard enough, everything else gets crowded out.

The gap ran October through November. I came back January 26, 2026 with one post: "I'm back because of Clawdbot meta." No apology, no "I've been doing some reflection," no thread about what I learned. Just back.

What actually happened to reach when I stopped posting on Twitter

Short answer: yes, disappearing kills your numbers. I came back to impressions that were noticeably down from where they were in September. The algorithm punishes inconsistency in ways that are both predictable and annoying.

Here's what surprised me though - my follower count barely moved. The people who followed me for real reasons didn't unfollow during a two-month gap. They just... waited. Or forgot I existed but kept the follow anyway, which is functionally the same thing.

What did drop off were the engagement-farmers. The follow-back accounts, the people following hoping for a mutual, the ones gaming numbers. When I stopped posting, I stopped being useful to them. They left. Good.

So the actual damage from a two-month absence was:

Impressions down significantly on return
Algorithmic reach basically reset
Genuine followers intact
Low-quality followers gone

That's not catastrophic. It's annoying if you're trying to grow on a consistent curve, but it's not irreversible. Coming back with something real to say matters more than the reach penalty.

The platform rewards consistency, but it doesn't erase you for breaks. It's not that vindictive. It just forgets you for a while and you have to re-earn distribution. Which, to be clear, still sucks. But it's survivable.

Research from the Reuters Institute Digital News Report backs this up - audiences don't actively track individual creator absences the way creators fear they do. People are mostly watching the feed, not waiting for you specifically.

Building in public culture and why it makes breaks feel worse than they are

There's a specific kind of pressure that comes with building in public. The implicit rule is you have to be visible. Posting daily "day 47 of building X" content. Sharing every milestone. Being present enough that people remember you exist.

Miss a week and you feel like you're falling behind. Miss a month and it feels like career death. I'm not immune to this feeling. I've been building in public for long enough to have internalized the assumption that visibility = momentum.

But the two months proved that assumption wrong in at least one direction.

I built more in those two silent months than in the three months of posting before them. Seven apps. Real infrastructure. Clawdbot, which ended up being the thing I came back to announce. When you're not performing the work, you're just doing it. Turns out those are different modes.

The building in public model optimizes for consistency of output, not quality of output. There's value in that - accountability, community, people following along with the journey. But it can also turn into a content treadmill where the posting becomes the thing instead of the building.

I'm not saying building in public is bad. I'll keep doing it. But I'm now aware that the ADHD hyperfocus mode where I forget Twitter exists and just build for two months is also a valid mode. Maybe more productive in certain phases.

The ADHD angle: forgetting to post is not a failure

Everyone talking about "intentional breaks" from social media has the same energy: "I realized I needed to step back and prioritize my wellbeing." Very deliberate. Very curated. Very LinkedIn.

That wasn't this.

I didn't decide to take a break. The habit just... dissolved. I was on a 2am coding session in early October, deep in something, and the thought of tweeting about it didn't occur to me. Same the next night. By week two the pattern was just gone.

This is textbook ADHD. The executive function overhead of maintaining a social media posting habit - opening the app, forming a thought worth sharing, hitting post, checking the response - that whole loop requires a certain baseline attention budget. When something captures all of it, the habits that depend on leftover attention just stop running.

The ADHD and executive function research out of Harvard Medical School explains this pretty well - executive function isn't a moral failing, it's a resource allocation problem. When the resource is fully committed elsewhere, discretionary habits are the first to drop.

I've made peace with this. It's not undisciplined, it's just how my brain allocates. The flip side of forgetting to post for two months is also why I can build seven apps in parallel while maintaining an agent system that runs 14 cron jobs. Same mechanism, different outputs.

If you have ADHD and you've done this - gone silent for weeks because you were deep in something - it's not a failure mode. It's just the cost of the hyperfocus that also lets you ship faster than most people.

The trick is not building your brand strategy on a foundation that requires daily consistency you won't reliably deliver. Build it on depth instead. One good post after two silent months is worth more than sixty filler posts.

What "coming back" actually looks like

January 26. "I'm back because of Clawdbot meta."

That was the whole post. No explanation, no recap thread, no "here's what I learned while I was away" (except this post, I guess). Just the most direct possible signal: I exist, I have a reason to be back, here's the thing.

This felt right. The alternative - the big return post with the reflective thread - felt like it was performing a story instead of just getting back to work. The people who care will engage with the work. The people who need a narrative about why you were gone aren't really your audience anyway.

I did get some "welcome back" responses. More than I expected, honestly. A few people had noticed the gap and were curious what happened. That was kind of nice - it meant the previous presence had registered as real enough that the absence was notable.

But the bigger signal was that nobody was mad. Nobody had been waiting with a timer. The internet doesn't work that way. People move on, the feed keeps moving, and when you come back with something worth seeing, you get traction again.

What I'd tell someone about to take (or accidentally start) a social media break

Not going to frame this as advice, because I didn't plan any of it. But if you're reading this because you've already been gone for a month and you're wondering if you've tanked your presence - you probably haven't.

A few things that are actually true from experience:

Genuine followers don't leave during a two-month absence. The people who followed you for real reasons are still there. The follower count number that matters is quality, not quantity, and quiet people who actually care about your work have more patience than the algorithm does.

Your reach will take a hit and that's fine. You'll rebuild it. Reach is lagging indicator of consistency, and consistency can be rebuilt faster than you think when you come back with something real. I came back with Clawdbot. That gave me actual things to say.

The building you do during the silence compounds. Those two months produced more than the three months of documented-daily-grind before them. There's something to that. Not every phase of building should be public. Some of it needs to be quiet.

The "building in public" pressure is real and mostly self-imposed. The audience you're building in public for is smaller and more patient than the anxiety makes it seem. If you're good at what you do and you come back with evidence of it, people remember.

And if you have ADHD and you just disappeared because something grabbed you - that's the mechanism working, not failing. The work you did in the silence is the asset. The posts are just distribution for it.

What stopped posting on Twitter for 2 months actually cost me (and what it didn't)

I have how I grew to 500 followers where you can see the full context of what I work on - design background, fintech, AI engineering, all of it. None of it died during two months off Twitter.

The projects I was building kept building. The systems kept running. The professional relationships that matter don't live on Twitter anyway - they live in Discord servers, in direct messages, in shipped product people can actually use.

Twitter is distribution. It's a real tool and a decent one for this type of work. But it's not the substrate. The work is the substrate.

The two months off X taught me that more than anything. When the posting stopped, nothing important stopped with it. The important stuff was already running somewhere else - in the codebase, in the agent system, in the products actually getting built.

Coming back felt like turning a tool back on. Not like returning from exile.

That's the right relationship to have with it. Check what I was building instead to see what came out of those two silent months. And if you want context on how Twitter's algorithm actually handles inactive accounts, X's own creator documentation doesn't spell it out cleanly - but the pattern from third-party analyses is consistent: reach drops fast after ~2 weeks of silence, then stabilizes, then rebuilds within a few weeks of returning.

The algorithm is back to punishing me for the gap. I'm fine with it. The seven apps I built during the silence are more valuable than consistent impressions metrics would've been. Trade you'd make again without thinking about it.

My coding stack is 4 models deep

Wed, 10 Sep 2025 00:00:00 GMT

Nobody uses one AI model for coding anymore. Nobody serious, anyway. My multi-model coding workflow has me running four-plus models in sequence on most days, and I ship more in a week than I used to in a month. That's not hype - that's what happens when you stop treating AI coding tools like a single hammer and start treating them like a crew.

Here's the actual stack, why it's built this way, and what most people get wrong about "vibe coding."

What "vibe coding" actually means

It's not "ask ChatGPT to build me an app." That's how you get a 400-line index.js with no error handling that half-works for 20 minutes before collapsing.

Real vibe coding is coding with leverage. You still need to understand what the code does. You still need to catch hallucinations. You still need to make architectural decisions - maybe more consciously than before, because the AI will happily scaffold the wrong architecture at 10x speed if you let it.

What changed: the AI handles the typing and the boilerplate. The parts that used to eat 60% of my time - setting up file structure, writing CRUD routes, building form components I've built a hundred times - that's mostly automated now. What I bring is the product sense. Knowing what to build is harder than knowing how to build it. The "how" is commoditized. The "what" and "why" still aren't.

My background is product design. Ten-plus years of it, including a long stint as sole designer at a fintech platform doing $4B+ in digital assets. That taught me to think about systems - how pieces connect, what breaks under edge cases, where the user actually gets stuck. That context is the thing AI can't replace. It's why a designer who codes can actually get further with these tools than a CS grad who just knows syntax.

The four-model lineup

These are the main players. Each one has a job.

Grok (grok-code-fast) - The fast pass. I use this first. It's cheap, it's quick, and it's genuinely good at scanning code for obvious issues - logic errors, missing edge cases, things that'll blow up. I don't use it for fixes. I use it for triage.

Claude Code - The surgeon. Best AI I've used for understanding context and making targeted edits. If I have a function that's almost right but subtly broken, Claude finds the problem without bulldozing the surrounding code. It reads the file, understands the intent, and makes the minimal correct change. This is rare. Most models over-edit.

Codex - The builder. Heavy refactors, multi-file changes, greenfield scaffolding. When I need to restructure a whole module or build something from scratch, Codex is the move. It's not as precise as Claude on targeted edits but it handles scale better. It'll touch 8 files in sequence and keep things coherent.

Gemini (Flash or Pro depending on context) - The reader. When I need to analyze a large codebase or understand a sprawling chunk of code I didn't write, Gemini's context window is unmatched. I'll drop 50K tokens of code in and ask it to explain the data flow. It handles that better than anything else I've used.

That's the core four. v0 gets a slot for frontend component generation. It's the fastest way to get a working UI component I can then iterate on with Claude Code.

How the actual pipeline runs

Real example of how a feature goes from idea to done:

I write a rough spec in plain text. What the feature does, what the inputs and outputs are, what edge cases matter. This step is underrated. The cleaner my spec, the better the AI output at every stage.
If I'm building frontend: I hit v0 first. Describe the component, get something that renders. It won't be perfect but it's 80% of the way there in two minutes.
Grok does a fast pass on whatever exists so far. I'm asking it: "what's obviously wrong here? what breaks?" Quick, cheap, catches the low-hanging problems.
Claude Code handles the refinement. Takes the rough output, applies targeted fixes, handles the business logic, integrates with the rest of the codebase. This is where most of my back-and-forth happens.
If Claude hits a wall - something too structurally complex, or needs changes across multiple files - I hand it to Codex. Codex finishes the heavy lifting.
Grok reviews the final output. Another fast pass. At this point I'm looking for regressions and anything the other models introduced.
I read the code. Final check. I don't skip this.

That last step isn't optional. You cannot ship AI-generated code you haven't read. The hallucinations are sneaky. They produce code that looks right and runs right in tests but breaks in production on a Tuesday when someone does something slightly unexpected. Your name is on the commit. Read the code.

My multi-model coding workflow for backend vs frontend

Different problem types call for different entry points.

Frontend

Start with v0. Describe the component - what it does, any constraints, the general look. Get the initial render. Then switch to Claude Code for every iteration after that. Claude is better at "change this specific behavior" than v0 is once you're past the initial generation.

For anything that needs complex state management or integration with existing backend types, I'll write that part myself or with Claude Code from scratch rather than trying to wrangle v0's output. v0 is a starting point, not a production artifact.

Backend

Codex for scaffolding. Give it the data model, tell it what the API needs to do, let it build the structure. Claude for the business logic layer - anything that involves conditionals, data transformation, edge cases. Debugging: paste the error into whatever's fastest. Usually Grok for the first look, Claude if it needs deeper investigation.

For architecture decisions - where to put things, how services should talk to each other, what the data model should look like - I make those myself. I'll ask Claude or Grok to rubber-duck a decision with me, but I'm not delegating architecture to a model. That's the one place where the AI's lack of business context will hurt you.

The MCP layer

This is the part most people aren't talking about yet.

MCP (Model Context Protocol) tools change how much context your AI coding setup can actually see. Without good context, you're pasting code snippets manually and hoping the model understands the surrounding system.

The one I use daily: sammcj's devtools MCP. At ~9K tokens it gives me basically everything meaningful about a codebase - file structure, dependencies, key functions. I drop this context at the start of any substantial session and the model quality jumps immediately. Less hallucination, more accurate edits, better architectural suggestions.

If you're using AI coding tools without MCP integration, you're leaving a lot on the table. The model can only help you as much as it understands the system. Give it the context.

What this costs

People act like the price of these tools is a dealbreaker. It's not. But you should know what you're actually paying.

I'm on OpenAI Pro ($200/month). That's basically required if you're using Codex for real work - you need the usage headroom. Claude Pro or Max depending on the month. Grok is included in X Premium, which I'd pay for anyway.

All in, I'm spending around $350-400/month on AI tooling. I get somewhere between $800-1,200 of nominal usage value out of it based on what the APIs would cost at direct rates. And I ship maybe 3-4x faster than I did 18 months ago.

The mental model I use: I'm hiring a part-time engineer who's excellent at specific tasks, needs supervision, and occasionally hallucinates. At $400/month, that's a steal. The thing that makes it work is knowing which part-time engineer to call for which job. That's the whole game.

What breaks this workflow

Being honest about failure modes:

Bad specs kill everything. If I'm vague about what I want, every model in the chain produces something subtly wrong in a different way, and now I have five things to reconcile instead of one thing to fix. Time spent on the spec is time saved everywhere downstream.

Chaining without reading. Running model output straight into the next model without reviewing it first compounds errors. Grok flags an issue, Claude "fixes" it, Codex rebuilds around Claude's fix, and now the original problem is buried under three layers of AI decisions you didn't validate. Read between steps.

Using the wrong model for the task. Claude on a large multi-file refactor gets expensive and sometimes loses coherence. Codex on a targeted three-line fix is overkill and occasionally makes it worse. Matching the model to the job isn't optional.

Architecture by committee (with AIs). I did this once - asked three different models how to structure a feature, got three different answers, tried to synthesize them. Waste of time. Architectural decisions are mine. I use models to validate and poke holes, not to make the call.

The honest take on vibe coding

Most of the backlash against it is people who watched someone generate slop and extrapolated. Most of the hype is people who generated something that worked for 10 minutes and declared victory.

The actual version is somewhere more boring and more useful: AI handles commodity work at speed, you handle judgment. The skill ceiling on building shifted. You don't need to memorize syntax. You do need to know what good architecture looks like, how to write a tight spec, when the AI is confidently wrong, and what the user actually needs.

I couldn't do this workflow without 10 years of product and design experience. Not because the tools are hard - they're not. But because the inputs I give them are shaped by that experience. The prompts are good because I know what I want. The reviews catch problems because I know what breaks. The architecture holds because I've seen what doesn't.

If you want to build a similar stack: start with one model and learn it well. Understand its failure modes. Then add another model where you keep hitting walls. Don't adopt the whole thing at once - you'll just have four sources of confusion instead of one.

Read everything you ship. That's the one rule that doesn't have exceptions.

You can see more about what I'm building and how I think about this stuff why prompt engineering is dead. And if you want to dig into related topics - multi-agent systems, prompt engineering, tool comparisons - check out the MCP server I built to find threads that go deeper.

0 to 500 Twitter Followers in 30 Days

Thu, 28 Aug 2025 00:00:00 GMT

500 followers in 30 days sounds like nothing until you remember I started from literal zero on June 7, 2025. New account, no imported audience, no cross-promo deals. If you're trying to grow Twitter followers from zero, my situation was as clean-slate as it gets - my previous account @deeflect got banned and I wasn't going to beg for it back. So I rebuilt. And figuring out how I grew from 0 to 500 Twitter followers taught me more about the platform than the previous years I'd spent on it.

I'm at ~660 now. Not viral. Not a "Twitter guru." But I have a real, engaged audience of AI/dev/startup people who actually interact. That's worth more to me than 50K ghost followers.

Here's what I learned rebuilding from scratch.

The 3 routes to grow Twitter followers from zero (pick wisely)

Before I talk tactics, the mental model matters.

There are exactly three routes to growing on X. Route A: be funny and shitpost. Route B: drop insights and add value. Route C: rage bait and controversy. That's it. Every account you've seen blow up used at least one of these. Most big accounts you think are doing something special are just doing one of these three things really well.

Route C works. It works fast. It also fills your replies with people who are wrong on the internet as a personality trait. I'm not interested in managing that energy, so I mostly stayed off it.

Route A gets you shared. Funny spreads. But pure shitposting doesn't build authority - it builds a following that sees you as entertainment, not expertise. The second you post something serious, engagement tanks because you trained them to expect jokes.

Route B gets you saved. Value posts rack up bookmarks and follows from people who want to learn something. But pure value content is too easy to scroll past without engaging. It doesn't spread.

The actual sweet spot - and this is the insight that changed my numbers - is A+B together. A funny observation that also teaches something. A self-deprecating building-in-public moment that contains a real insight. The format makes people laugh, the substance makes them follow.

"Shipped a feature that took 3 days to build. My AI agent replaced it in 47 minutes. I'm choosing to be excited about this."

That's funny and it says something real about where AI tooling is going. That kind of post travels.

What actually grew my account from zero

Replies on big accounts - this was 80% of it

Not "great post!" Not "I agree!" Not the kind of thing that reads like a bot (more on that shortly).

Actual additions. Real takes. Occasionally a funny riff on what they said. When someone with 50K followers posts something about AI agents being overhyped, I'm not validating their hot take - I'm adding specificity. "The hype is real, the production readiness isn't. I've been running 14 scheduled agent jobs daily for 3 months and the failure rate on complex multi-step tasks is still too high for me to hand off anything important unsupervised."

That kind of reply does a few things. It shows up in the timeline of everyone following that account. It positions me as someone who's actually done the thing. And if it's good enough, the original poster might like it or reply - which extends the reach further.

The key is being genuinely useful or genuinely funny. Vague agreement is invisible. Disagreement with substance is visible. Addition is visible. The metric I use: would someone screenshot this reply? If not, it's probably not pulling any weight.

I probably wrote 15-20 quality replies a day for the first two weeks. That's the unsexy part nobody talks about. It's not posting content - it's showing up in other people's conversations consistently.

Opinionated takes from daily tool usage

I use AI tools every day. Cursor, Claude Code, various agent frameworks, LLM APIs. I have real opinions about what's good and what's broken. Those opinions performed well because they're specific.

"Cursor's composer is great until your project hits ~150 files, then the context quality drops noticeably" is a post. "AI coding tools are amazing" is noise.

The what happened when I stopped posting gives the full background, but the short version: 10+ years in design, deep fintech engineering experience, now building multi-agent systems full-time. That's a specific lens. When I post about AI tools, I'm not regurgitating documentation - I'm reporting from actual usage at a level most people don't have.

Specificity is unfakeable credibility. Anyone can say "this tool is good." Not everyone has run 40K tokens per day through their own agent system and tracked the monthly API cost down to $40.

Building in public - but only the interesting parts

"Day 47 of my building in public journey" is dead. Nobody wants that. The journey framing assumes your audience cares about you, and they don't - not yet. They care about what you're doing and what they can learn from it.

What works instead: the specific moment that was actually interesting.

Not "working on my AI project today." Instead: "Realized my RAG pipeline was failing not because of the model but because of my chunking strategy. Three days of debugging to find a paragraph break problem. Love this for me."

Building in public posts that perform have an insight embedded in them. The vulnerability is a delivery mechanism for the learning, not the point itself. When the vulnerability is the point, it reads as attention-seeking. When the learning is the point and the vulnerability makes it human, it actually helps people.

Timing matters more than I expected

I post when US tech Twitter is active. That's roughly 9am-12pm Pacific and then a second window around 5-8pm Pacific. I'm in LA so this is convenient for me.

But the timing thing is real. The exact same post at 2am gets 20% of the engagement it'd get at 10am. The algorithm's initial distribution window is short - if you don't get traction in the first 30-60 minutes, the post dies. So showing up when your audience is scrolling is a basic requirement that a lot of people ignore.

Being weird and specific instead of generically motivational

The fastest way to get lost in the feed is to sound like everyone else. "Consistency is key." "Ship fast, iterate faster." "Your future self will thank you." These are not posts. These are bumper stickers.

I'm Russian-born, ADHD, building AI systems in LA, async-only (no calls, ever), obsessed with multi-agent workflows. That's specific. When I write from that specific perspective instead of trying to be universally relatable, the people who connect with it really connect.

You can't optimize for everyone. You can optimize for your actual people.

What didn't work - including an embarrassing confession

AI-generated replies

This one I'm putting in writing because I think a lot of people are doing this and thinking it's working.

For a few months, I was using AI to generate replies to posts in my niche. The idea: stay "active" in conversations, look engaged, maybe get some follows from the visibility. The system did not notice - meaning I wasn't flagged or suppressed as far as I could tell. But the growth was essentially flat. Automated engagement looks active, but builds zero real connections.

Here's why it fails: a good reply starts a conversation. An AI-generated reply that's technically relevant but not genuinely insightful doesn't make anyone want to engage back. It gets ignored or gets a polite like. It doesn't turn into a thread. It doesn't make the original poster remember you. It doesn't build a relationship with anyone who saw it.

I switched to genuine replies only - less volume, more quality. Growth actually improved. Because one real conversation is worth more than 50 AI-generated non-interactions.

The meta-lesson: you can use AI to help draft a reply if you're stuck, but you need to inject your actual perspective into it. The algorithm might count impressions, but humans are better than you think at detecting genuine vs. automated engagement.

Mass following and hoping for follow-backs

Did this for like a week, stopped, never mentioned it until now. Following 200 accounts a day hoping 10% follow back is a number game that builds the wrong audience. Even when it "works" you get people who don't care about your content - they just returned a courtesy follow. Those accounts become noise in your metrics and won't engage with anything you post.

Generic "tips and tricks" threads

I tried a few of these early on. "5 AI tools every developer should know" type content. It did okay in terms of impressions but drove almost no follows. The problem is this content exists everywhere. There's nothing in it that could only come from me. When someone reads a generic tips thread, even a good one, they don't feel any reason to follow the source specifically. They just take the info and keep scrolling.

The posts that converted to follows were the ones with a clear point of view. Posts where you can tell who wrote them from the content alone.

The introverted builder angle

I want to flag something for anyone who's introverted and thinks Twitter growth requires networking, calls, or showing up to events.

It doesn't. I don't do calls. I don't go to tech meetups. I'm async-only. Every single one of my followers came through written content and written replies. No podcast appearances, no cross-promo deals, no "collab" posts.

The platform rewards writing, and writing is something you can do alone at 11pm in your apartment. For introverted builders, that's actually a structural advantage. You're competing with people who need external validation to show up - and you can just quietly be consistent.

Check out the building 7 apps solo for all the AI engineering and building-in-public content if you want to see how this thinking shows up across different topics.

Where I am now and what I'm focused on

660 followers, growing slower than the initial burst but more steadily. The first 500 came fast because I was very active with replies. I've pulled back on reply volume a bit as I'm heads-down on some builds, and the growth has slowed accordingly. That's fine - I'd rather have a smaller engaged audience than chase a number.

The things I'd do exactly the same: heavy reply game in the first month, being genuinely specific and opinionated, building in public with the insight-forward framing.

The things I'd change: started with genuine replies from day one instead of testing the AI reply thing, spent less time on generic content earlier.

If you're starting from zero or rebuilding like I was - the reply strategy is not glamorous but it's the most direct path. Find 10 accounts in your niche with 5K-100K followers, show up in their replies every day with actual value, and do it for 30 days before evaluating whether it's working. That's the playbook. The rest is just execution.

One last thing: don't optimize for follower count if you're building something. Optimize for the right followers. 500 engaged AI/dev/startup people is worth more than 5,000 general followers who won't care about what you're building. Niche compounds. Broad doesn't.

Find me at @deeflectcom if you want to watch this experiment continue in real time.

Building 7 Apps at Once as a Solo Founder With ADHD

Tue, 12 Aug 2025 00:00:00 GMT

Seven apps. All running simultaneously. All half-built. All "almost done."

That was me six months ago, and if you're a solo founder with ADHD, you probably know exactly how that happens. Building 7 apps at once isn't a failure mode - it's the default state when your brain treats every new idea like an emergency and you're technically capable of actually building all of them.

I can do the full stack. Design, frontend, backend, smart contracts. Which sounds like an asset until you realize it means nothing stops me from starting something new at 2am because I read one interesting tweet about a framework I've never tried.

Let me tell you what that actually looks like.

How building 7 apps at once happens (faster than you'd think)

It doesn't start as 7. It starts as 1, then 2, then "just a quick experiment," then you blink and your Notion has 7 active project docs and your GitHub has 11 repos created in the last 90 days.

My list at peak chaos:

OpenClaw - my AI agent system. The main thing. 14 cron jobs running daily tasks, managing my workflow, aggregating data, handling research. Actually running in production.

A music generation pipeline - GPT-4 generating lyrics, Suno turning them into actual audio, Midjourney for visuals, ElevenLabs for voiceover. The idea was a fully automated artist that produced content without me touching anything after setup. I got it working. Then got distracted.

Crypto products - I've contributed to successful multimillion-dollar crypto projects. The financial incentive is real. The problem is crypto moves fast and demands constant attention, which ADHD brains are simultaneously great and terrible at.

An ADHD planning tool - I was going to build the productivity app that actually worked for my brain because everything else sucked. Classic "scratch your own itch" trap. You know what happened. I got distracted building it.

MCP servers - Model Context Protocol is genuinely interesting infrastructure work. I built three of them in a weekend because the architecture grabbed me.

CLI tools - Small stuff. Quick utilities. The kind of thing you build in 4 hours because you needed it for something else and now it exists.

Automation workflows - n8n pipelines, custom agents, glue code connecting APIs. This bleeds into everything else so it's simultaneously its own project and embedded in all the others.

Seven things. One person. No cofounders by choice - I'll get to why in a minute.

The ADHD founder loop is real and it's not what you think

Everyone explains ADHD as "gets distracted easily." That's not wrong but it misses the mechanism. It's not that I can't focus. It's that my brain allocates attention based on novelty and interest, not importance and priority. A new framework registers as urgent. A 6-week-old project that needs documentation registers as optional.

The loop looks like this:

New idea hits. Immediate hyperfocus. Build for 16 hours straight.
Get it working. MVP ships. Dopamine.
Hit the boring middle - marketing, SEO, documentation, polish, customer support.
Brain de-prioritizes it. New shiny thing appears.
Repeat.

The boring middle is where non-ADHD founders grind through and ADHD founders bounce. The problem isn't the building. I'm fast at building. The problem is everything after the building.

Here's what took me too long to figure out: the boring middle is where the money is. Shipping is fun. Distribution is how projects survive.

And I can't do distribution manually. It just doesn't happen.

This isn't unique to me - the ADHD and entrepreneurship research from Barkley et al. consistently shows that executive function deficits hit hardest on sustained, low-novelty tasks. Which is exactly what distribution and maintenance are. The building phase is fine. Everything after is structurally harder for ADHD brains.

What building 7 apps at once as a solo founder with ADHD actually costs you

The real cost isn't time. It's context switching overhead compounded across seven projects simultaneously.

Every time you context-switch between codebases, you pay a mental re-load cost. Research on developer context switching puts the refocus time at 23 minutes on average after an interruption. Multiply that by seven projects and you're paying that tax constantly. You're never fully in any one thing long enough to hit the deep work state where hard problems actually get solved.

My peak chaos period felt productive. I was always building something. But my actual output - measured in shipped features, not hours of activity - was lower than my focused periods. The context switching was eating the work.

The other cost is quality. When you're seven projects deep, you're not doing your best work on any of them. You're doing good-enough work on all of them. Which means none of them have the level of craft that makes a product actually stand out.

I shipped an MVP of the ADHD planning tool that was functional but ugly. No time to polish it. Meanwhile I was debugging MCP server architecture and planning the music pipeline. Something had to give and it was always the boring middle tasks - the ones that determine whether anyone actually uses the thing.

The solo founder reality nobody posts about

how ADHD and AI work together is performance art now. Revenue screenshots get thousands of likes. MRR milestones. "I quit my job and 6 months later..." threads. Everyone's sharing the wins.

Posts about almost going broke get 12 likes. Posts about abandoning your fourth project in a row get silence. The authentic failures don't get engagement so nobody posts them, which means every new solo founder thinks everyone else has it figured out.

I've been broke. I've shipped things that made zero dollars. I've built for three weeks and then deleted the repo because I couldn't figure out what the product actually was. I've had projects that made real money and then lost relevance six months later because I didn't maintain them.

The solo part: genuinely fast. No meetings about meetings. No "we should align on the roadmap" conversations with a cofounder who has different priorities. No equity negotiation. No founder breakup. I've watched every cofounder horror story play out in real time around me - equity fights, one person doing 80% of the work, fundamental disagreements about direction, personality conflicts that kill companies that should have made it. Solo is lonely. It's also fast.

The ADHD + solo combination creates a specific failure mode though. There's no one to tell you you're going down a rabbit hole. No one to say "we've been working on this side feature for two weeks, should we refocus?" Your own judgment is the only check on your impulses and ADHD makes your judgment unreliable at the exact moments you need it most.

The fix isn't a cofounder. The fix is building systems that act like a cofounder for the structural stuff while you handle the actual building.

What actually survived (and why)

Out of seven active projects, two are still running and one of those is making consistent money.

Five are abandoned or on permanent ice.

Here's the honest accounting: those five failures weren't wasted. They taught me things that made the two survivors better. I learned how to architect agent systems from the music pipeline experiment. The MCP servers gave me infrastructure patterns I'm using in OpenClaw. The ADHD planning tool taught me what actually helps my workflow versus what sounds good in theory.

But the reason the two survivors survived isn't just that I learned from the failures. It's that the survivors automated their boring middles.

OpenClaw runs 14 cron jobs. Morning digest, memory management, content scheduling, health data aggregation, crypto position monitoring - all automated. I talk to it every morning. The daily feedback loop exists. The daily maintenance doesn't.

The crypto products that worked had simple mechanics and network effects that didn't require my constant attention. Once they were live, they ran. The ones that needed daily management died when my attention moved elsewhere.

The pattern is consistent: if I have to manually do something for a project to stay alive, that project will eventually die. Not because I don't care about it. Because ADHD means I'll miss 3 days of manual tasks in a row and then it feels too far behind to recover and then I move on.

If the system can sustain itself through a 2-week hyperfocus absence, it lives. If it can't, it doesn't.

Why I'll never take a cofounder

Everyone says this is a mistake. "Two founder teams outperform solo founders statistically." I've read the YC essays.

Here's my actual take: those statistics are describing average cases and I'm not an average case.

What a cofounder typically brings: accountability, complementary skills, emotional support during hard stretches, a second opinion on decisions, someone to handle the stuff you're bad at.

What I actually need from that list: someone to handle the stuff I'm bad at. Specifically, distribution, SEO, documentation, customer communication. The boring middles.

A human cofounder would need 40-50% equity for that. They'd have opinions about the product direction. We'd need to agree on decisions. We'd have to coordinate schedules. They'd have good months and bad months and burnout cycles that don't sync with mine.

An AI agent running my content pipeline costs me $40/month and doesn't have feelings about feature prioritization.

I'd rather have a multi-agent system that handles my weak spots than a human who wants half the company to do the same job. That's not cynical, it's just math. And it only works because I can build the agents myself.

The loneliness is real. I'm not dismissing it. Some weeks the silence is rough. But the alternative isn't "cofounder" - it's growing on Twitter and genuinely engaging with the community instead of just posting screenshots.

The systems that make solo + ADHD actually work

I've been iterating on this for two years. Here's what actually helps:

File-driven everything. My agents read from markdown files - SOUL.md for personality, AGENTS.md for protocol, MEMORY.md for context. When something needs updating, I edit a text file. No deployments. No configuration hell. Low friction maintenance survives ADHD gaps. High friction maintenance doesn't.

Cron jobs over manual triggers. If a task requires me to remember to do it, it will eventually not get done. Scheduled jobs run whether I'm in a hyperfocus sprint or a three-day crash. Everything recurring gets automated.

Ruthless scope decisions at the start. The ADHD planning tool died partly because I kept adding features during the build phase. Every new feature felt urgent. Scope compound-expanded until the MVP was a six-month project. Now I write down the exact features for v1 and I'm not allowed to add anything until v1 ships. This one rule has probably doubled my shipping rate.

Letting projects die without guilt. I spent too long trying to "get back to" projects I'd mentally left. Felt like failure. Now I have a graveyard folder on GitHub and I use it. Dead projects get documented (so I can steal the code later) and archived. The folder has 22 repos in it. That's fine.

Using the hyperfocus instead of fighting it. When I'm locked in on something, that's a resource. I try to batch the hardest technical work for those windows. The structured boring tasks - docs, config, cleanup - get batched for the lower-energy periods when I can work mechanically.

Finishing 2 out of 7 is actually fine

Here's the reframe that helped me most: the 5 abandoned projects aren't failures, they're the cost of finding the 2 that worked.

Most indie developers don't talk about their abandonment rate. They talk about the thing that shipped. But every shipped product has a graveyard of experiments behind it. The experiments weren't wasted - they were the research.

My music generation pipeline taught me how to build multi-tool AI pipelines. Spent two weeks on it, never shipped it as a product, use those patterns constantly now.

The ADHD planning tool taught me that "I'll use this myself" is not the same as "other people will pay for this." Different lesson. Equally valuable.

The CLI tools I built in weekends are still sitting in my shell. I use them every day. Zero revenue. Huge quality-of-life improvement. Not everything needs to be a business.

The crypto projects that reached multimillion-dollar valuations came after multiple experiments that went nowhere. The ones that worked worked because of things I learned from the ones that didn't.

Building 7 apps at once as a solo founder with ADHD is chaotic. It's also how you discover which two are actually worth finishing.

If you're building solo with ADHD and you've got four half-built things on your GitHub and you feel like you're failing - you're not. You're doing the process. The trick is setting up the systems so that when the thing that matters is ready to run, it can run without you holding it up.

Automate the boring middle. Let the losers die fast. Stay technical enough to build your own infrastructure. And ignore anyone who tells you the only way to do this right involves giving half your company to someone else.

The agent handling my distribution doesn't want equity. That's the whole point.

If you want to see how the agent system I built actually works - the one that survived while six other projects didn't - I write about it here. The full architecture, the cost breakdown, what broke, what didn't.

Why AI Products Have Terrible UX

Thu, 24 Jul 2025 00:00:00 GMT

Most AI products have terrible UX. Not because the AI is bad - because nobody who understands both AI and design is in the room when these things get built.

I've spent 10+ years in product design, including five years designing institutional fintech for 70+ banks at VALK. Now I build AI systems. I write prompts and I write interfaces. I can spec a component in Figma and wire up the agent backend that powers it. That combination is genuinely rare, and the fact that it's rare is exactly why AI UX is such a disaster right now.

This isn't a subtle problem. Open any AI product built primarily by ML engineers and you'll feel it within 30 seconds.

Why AI products have terrible UX by default

The people who understand how transformers work don't think in interaction flows. They think in loss functions and benchmark scores. When an ML engineer ships a UI, you get a settings panel with 40 sliders and tooltips that say "controls the randomness of model outputs." Thanks. Very helpful.

The people who understand interaction design usually can't implement AI systems. They can map the user journey beautifully but they don't know what a context window is, can't reason about latency tradeoffs, and treat the AI as a black box that either works or doesn't.

The intersection - people who can do both - is genuinely tiny. Which means most AI products get built by one camp or the other. And it shows.

Here's the uncomfortable truth: a mediocre model with great UX beats a great model with terrible UX every time. ChatGPT didn't win because GPT-4 was the best model when it launched. It won because the chat interface was dead simple. You typed. It responded. No configuration. No onboarding. No explaining what a temperature setting does.

That chat box was a design decision, not an ML decision. And it's worth billions.

The specific ways AI UX fails

Let me get concrete because "bad UX" is a garbage diagnosis. Here's what I actually see when I use most AI products:

Chat-for-everything syndrome

Not every AI interaction needs a text input. Some interactions need a button. Some need a slider (a single, well-labeled one). Some need a select dropdown.

When you build "chat as the UI" because it's easy to implement, you're making your users do the work of figuring out what to ask. That's backwards. The product's job is to make the right actions obvious. If your AI can summarize a document, add a "Summarize" button. Don't make me type "please summarize this document" like I'm filling out a form in 1998.

The chat interface pattern gets cargo-culted because ChatGPT did it and ChatGPT is successful. But ChatGPT's whole thing IS chat. It's a general-purpose assistant. Most AI products aren't general-purpose - they're doing specific things for specific workflows. A focused tool should have focused UI.

Loading states that feel like crashes

Generative AI is slow. A response can take anywhere from one second to 25 seconds depending on the model, the prompt length, and what you're generating. Users are not okay with a spinner for 20 seconds. They need to know something is happening, roughly how much longer it'll take, and ideally a preview of the output streaming in.

Streaming output is table stakes in 2025. If your AI product shows a blank area and then suddenly dumps the full response, you've already lost. It feels like the app froze and then magically recovered. Streaming makes the latency feel shorter than it actually is - that's not a trick, it's respecting the user's attention.

I've seen products where a 15-second model call shows a static spinner with no copy, no progress indication, nothing. Users absolutely hit refresh. Then they get confused about duplicate outputs. This is a solved UX problem that keeps getting ignored because the engineer who built the AI part is done and the UI is "good enough."

Error messages written for engineers

"Something went wrong." Rate limit exceeded. Context length exceeded. Model unavailable.

These are real failure modes that users hit regularly and none of them should surface as generic error states. When the model hits a rate limit, tell the user there's high demand and you're retrying. When the context gets too long, tell them what to do about it - not in token counts, in plain language. "Your conversation is getting long - try starting a new one for best results."

Error handling is where you find out if a designer was actually involved. Engineers write error messages for themselves. Designers write them for the person who just wanted to finish a task.

Settings pages designed for nobody

Temperature. Top-p. Frequency penalty. Presence penalty. Max tokens.

These settings exist because they're parameters in the API. They got exposed in the UI because nobody asked "should we expose this?" They just asked "can we expose this?" Yes, you can expose it. That doesn't mean you should.

I get it - power users sometimes want control. But the defaults should be invisible and the advanced settings should be buried behind a "configure" link that 95% of users never click. Progressive disclosure is a basic design concept. Show the simple thing first. Put the complex thing behind one more tap.

When your settings page looks like a synthesizer, you've failed the design. Users don't want to tune a model. They want to accomplish something.

Treating AI output as final

AI output is a draft. It's always a draft. The best AI products make this obvious by making everything editable in-context. Click a sentence. Change it. The system knows you changed it and uses that as signal.

When AI output renders as static text in a read-only block, you're implicitly telling the user that the AI's word is final. That's backwards. The user is in charge. The AI is a collaborator. The UI should make it trivially easy to edit, regenerate, or reject any piece of output.

Linear's AI summaries are a good example of getting this right. The summary is inline and you can just edit it like any other text. The AI offered a starting point. You own the result.

No feedback loop

If a user deletes an AI output and types something completely different, that's signal. If they regenerate three times, that's signal. If they always ignore the suggested action, that's signal.

Most AI products collect none of this. Not actively anyway. There's no thumbs up/thumbs down. There's no "fix this" button. There's no way for the user to tell the system "you're getting this wrong."

Beyond the product improvement angle, feedback UI makes users feel like they have agency. The AI isn't doing something to them - they're collaborating with it. That's a fundamental shift in how the product feels, and it costs almost nothing to implement.

Nielsen Norman Group has documented this pattern extensively - the products that build in feedback mechanisms consistently score higher on user satisfaction than those that treat AI output as a one-way broadcast. This isn't a new insight. It just keeps getting skipped.

What good AI UX actually looks like

Good AI UX is invisible. The AI is there, doing things, but you barely notice it. You just notice that the product works better than it should.

Autocomplete that predicts what you actually meant to type. Smart defaults that adjust based on what you've done before. Errors that self-correct before you ever see them. Suggestions that appear before you ask for them, in the right context, at the right time.

The goal is never to show off the AI. The goal is to make the user feel competent. There's a real difference between a user saying "this tool is so intuitive" and a user saying "wow the AI is amazing." The first is good UX. The second usually means the AI is impressive but the UX is still making you aware of it - which means it's getting in the way.

Figma's AI integrations are interesting to watch because Figma's team actually understands design. They still struggle with making AI actions feel predictable - there's always a moment of "wait, what did it just do?" - but they're closer than most. That moment of confusion is a UX debt they're actively trying to pay down.

The products I actually like using right now: Notion AI for the in-context editing flow, Cursor for how it makes AI suggestions feel like a collaborator not a replacement, and Linear for keeping AI features out of the critical path so they enhance without blocking.

All three share something: the AI is ambient. It's there when you need it, gone when you don't, and it never makes you feel like you need to understand it to use it.

Why AI products with terrible UX keep shipping anyway

The gap isn't closing fast enough. AI is getting more capable every few months. Design is being treated as optional or "we'll fix it later." The result is an ecosystem of increasingly powerful AI wrapped in increasingly confusing interfaces.

This is partly structural. Most AI companies are founded by researchers or engineers. Design hires come later, if at all. And when they do come, the designer often lands in a team where the ML engineers have already made the fundamental UX decisions - they just didn't call them design decisions. The architecture of the system becomes the architecture of the interface, which is almost never the right call.

Google's People + AI Research (PAIR) team has a whole guidebook on this. It's worth reading even if you don't agree with everything in it. The core insight - that AI systems require a fundamentally different design approach than deterministic software - is right. You can't just apply standard UX patterns to a system that might give a different answer every time. The guidelines for how to handle uncertainty, how to communicate confidence levels, how to make AI actions feel predictable without being rigid - that's the hard design work that most teams skip.

The Anthropic model card and usage policy documentation is also a useful lens here. The way they think about how Claude should communicate uncertainty and limitations is essentially applied UX thinking at the model level. That's rare. Most model providers treat the interface layer as somebody else's problem.

The companies that figure this out - that actually hire people who can span both domains, or that build real collaboration between their ML and design teams - are going to clean up. Not because their AI is better. Because their AI actually makes sense to use.

I started leaving fintech for AI specifically because I kept seeing this pattern and had nowhere useful to point people. The posts that get the most traction are always the ones about the interface layer, not the model layer. People are hungry for this.

Fix the UX before you touch the model

If you're building an AI product right now, the single most high-leverage thing you can do isn't to upgrade your model. It's to watch five users try to use your product without any help from you. Don't say anything. Just watch. You'll see exactly where the AI ends and the confusion begins. That's your design debt.

Spend a week on that before you touch your prompt engineering or your fine-tuning pipeline. The UX problems are costing you more users than the model quality is.

If you want to go deeper on the AI engineering side - how the systems actually get built, what the architecture decisions look like from someone who also designs the interfaces - check out what replaced prompt engineering for more technical posts. The design-to-engineering gap is a topic I keep coming back to because I keep seeing it break products that should work.

Fix the interface. The model will get better on its own. The UX won't.

How ADHD and AI Work Together (My Real Stack)

Tue, 08 Jul 2025 00:00:00 GMT

I scored 147 on the RAADS-R and 38 on the AQ-50 - both autism screening tests, not ADHD. But I have ADHD too. The combo means my brain is running two different operating systems at once, neither of which came with a manual. I've known for years that my brain works differently, but seeing the numbers made something click.

How ADHD and AI work together - that's become the actual question I've spent the last year building answers to. Not "how do I fix my ADHD" and not "how do I force myself to be more productive." More like: where are the exact gaps, and can software patch them?

Short answer: yes. Not all of them. But enough to matter.

What ADHD actually costs (it's not what productivity gurus think)

The mainstream narrative is that ADHD means you're distracted and you need to focus better. That's a useless frame. The real problem is executive function failure - the part of your brain that handles task initiation, working memory, time perception, and emotional regulation around boring tasks.

Concretely, that looks like this for me:

I forget things. Not occasionally. Constantly. Including things I cared about 20 minutes ago.
I start projects in hyperfocus bursts and sometimes walk away mid-sentence when the dopamine dries up.
I have a productive window from roughly 11am to 2pm. After 2pm I crash. Creative work comes back around 7pm. This isn't laziness - it's a real energy curve that I've tracked across years.
Decision fatigue hits me hard. By 3pm, choosing between two options of roughly equal weight can genuinely stall me for 30 minutes.
Calls destroy my flow state. I've worked async-only since I started freelancing at 14 because traditional structure never fit.

None of this is fixed by a better to-do list app. I've tried every productivity system. GTD, time blocking, Notion templates, physical planners - all failed because they assume linear execution, consistent motivation, and that you'll remember to check the system. ADHD brains don't do any of those things reliably.

What AI does is different. It meets you where you are instead of where you should be.

How ADHD and AI work together in practice

I run a multi-agent system called OpenClaw. One of the agents is borb - that's my day-to-day assistant, and it's the piece that's changed how I work more than anything else in the last two years.

The key insight: AI doesn't need you to have executive function. It has its own.

Borb maintains memory files. When I forget what I was doing - and I will forget - it has a record. When I say "remind me to follow up on this," it doesn't forget. When I ask the same question for the third time, it answers without judgment. That last part is underrated. Executive dysfunction comes with a lot of shame. An agent that just answers, every time, without the sigh or the "didn't we talk about this?" - that's genuinely useful.

The workflows that actually stuck:

Morning state load - borb checks my reminders, pulls calendar events, and gives me a plain-English summary of what's in front of me. I don't have to go hunting across four apps to reconstruct what today looks like. It's already there. This sounds small. It is not small. Starting the day without that reconstruction overhead means I hit my 11am-2pm window with actual energy instead of spending it getting oriented.

Building - I describe what I want in rough terms, the agent scaffolds the structure, and then I hyperfocus on the interesting parts. I've talked about this in building 7 apps at once - the ADHD pattern of "start fast, lose steam" becomes less destructive when the boring scaffolding is already done. The fun parts stay fun. The scaffolding doesn't require motivation.

Writing - AI drafts, I edit. Editing is dramatically easier than a blank page for an ADHD brain. The blank page has infinite options and zero constraints. A draft has something to react to. Even a mediocre draft gives me a direction to push against, and pushing against things is something my brain can do.

Research - This one might be the biggest one. I used to fall down 3-hour rabbit holes when I needed to look something up. Not because I was being inefficient - because that's what an ADHD brain does when it hits something interesting. Now I say "look into X and summarize it" and get back a usable synthesis in 10 minutes. The rabbit hole still exists. I'm just not in it.

Why ADHD and AI work together better than any productivity system I've tried

There's a reason GTD and every app built on top of it eventually fails for ADHD brains. The research on this is pretty clear - executive function deficits aren't a motivation problem, they're a neurological regulation problem. Systems that require you to consistently initiate, remember to check in, and maintain motivation to follow through are asking the exact thing the ADHD brain struggles with most.

AI sidesteps that loop in a way static systems can't. A to-do app is passive. It waits for you. An AI agent can be active - it surfaces things, drafts things, reduces the next action to something trivially small. That difference is the whole game.

The clinical picture backs this up too. Research from ADDitude Magazine's medical review board consistently shows that external scaffolding - someone or something that holds structure on your behalf - is one of the most effective accommodations for executive dysfunction. That's what ADHD coaches do. That's what a good EA does. AI can do a version of it at a fraction of the cost, 24 hours a day, without the social friction of asking a human for help again.

The difference between those external scaffolding approaches and AI: AI doesn't get tired of you.

The 90-day planning system I actually use

One of the more structured things I built is a multi-model planning system for quarterly work. I run it through Claude, Perplexity, and DeepSeek because they think differently.

Here's the rough structure:

# Run planning session across models
# Claude: strategic framing and goal coherence
# Perplexity: research-backed context on what's realistic
# DeepSeek: adversarial review - what did I miss, what's wishful thinking

Claude does the strategic layer - takes my rough "here's what I want to do this quarter" and shapes it into something coherent with actual priorities. Perplexity pulls external context - market stuff, comparable benchmarks, anything grounding. DeepSeek punches holes in it. Tells me where I'm being optimistic, where the plan assumes consistent motivation that I won't have.

The output is a quarterly plan that's actually calibrated to how I work, not how I should work. It accounts for the energy curve. It front-loads high-executive-function tasks to the 11am-2pm window. It builds in slack because I will start a side project mid-quarter.

This cost me maybe $3 in API calls. ADHD coaches charging $500/month are selling something similar - someone to help you structure the chaos. The AI version doesn't replace the human relationship, but it does the structural work well enough that I stopped needing the coach.

What still doesn't work

I want to be honest here because this is where most "ADHD and productivity" content fails - everything sounds like it works great.

Most AI productivity tools are built by neurotypical people for neurotypical people. They assume:

You'll check the app on a schedule
That once you've planned something, you'll follow the plan
That motivation is a dial you can turn up
That reminders are sufficient to trigger action

None of that is true for ADHD brains. A reminder I ignore three times isn't a reminder problem - it's a task initiation problem. The reminder sees the symptom and treats it by making more symptoms.

The AI tools that work for me are the ones that do the task or reduce it to the smallest possible action. The ones that fail are the ones that just tell me about the task more times. "You have 5 overdue items" is not useful. "I drafted an email for item 3, want me to send it?" is useful.

The other failure mode: AI planners that generate beautiful structured plans I'll never look at again. I've built these myself. They're impressive to screenshot, useless in practice. A plan I'll actually use is ugly, has a lot of slack built in, and survives contact with a day where I wake up unable to do hard things. Most AI-generated plans look like they were made for someone who executes flawlessly and never has a 2pm crash.

The design principle underneath all of this

The best automations I've built are invisible. They give me back the cognitive capacity I was spending on logistics, and I don't notice them working - I just notice I'm less exhausted.

That's the principle I use now when deciding whether to build a new automation: does this return brain capacity, or does it just offload a task I didn't care about?

Offloading boring tasks is fine. But the real value is when an automation handles something that was eating working memory - that background process running in my head that's tracking ten things at once. When borb maintains my memory files, I'm not the one holding context across sessions. That background process is freed up. That's where it gets actually useful.

The principle maps to AI broadly: don't use it to do more things. Use it to think fewer thoughts you didn't want to be thinking.

How I'd actually start if I were building this from scratch

If you're ADHD and you've read this far, here's the concrete version:

Pick one gap - not "I want to be more productive." Pick the specific thing that burns the most energy. For me it was morning orientation. For you it might be task switching, or research rabbit holes, or writing block.
Build the smallest intervention - don't automate your whole life. Build one thing that addresses one gap. If it sticks, expand it. If it doesn't, the cost was low.
Make it push, not pull - tools you have to check don't work for ADHD. Tools that surface things to you do. The difference between "you should open the app" and "here's your summary in Slack at 9am" is the difference between a system I use and one I abandon.
Use the right model for the task - I wrote more about my AI engineering stack in the tags section if you want to see the breakdown. Fast cheap models for logistics, more capable models for judgment calls. Don't run GPT-4-class inference for reminders.
Don't trust AI planning apps - build your own, even if it's rough. An n8n workflow or a cron job calling an API isn't glamorous but it works because you designed it around your actual workflow, not a generic one.
Start with memory before anything else - the single highest-leverage thing AI can do for an ADHD brain is hold context you'd otherwise lose. A markdown file your agent reads and updates is worth more than any reminder system.

The real unlock was accepting that I'm not going to become a different person with a different brain. The goal is building systems that work for this brain. AI is the first category of tool where that's actually been possible at the software layer.

If you're somewhere on the spectrum of neurodivergence and you've been grinding through systems that don't fit - this is worth trying. Not because AI fixes it. Because for the first time, the tools can be weird enough to match how you actually work.

The my coding stack I run is open in spirit if not fully in docs. If you want to talk about how to build something similar, I'm usually in the comments or findable.

Why I Left My Role as Solo Product Designer at VALK

Sun, 22 Jun 2025 00:00:00 GMT

Five years is a long time to stay anywhere. And if you want to understand why I left my role as solo product designer at VALK, the honest answer isn't dramatic. No blowup. No better offer waiting. Just a quiet realization, somewhere around late 2024, that the thing exciting me most wasn't the thing paying me. I'd been the only designer at VALK - now rebranded to datai - for five years and two months before I walked away in February 2025.

This is the first thing I've written for this blog, so bear with me finding the voice. I'll just tell you what actually happened.

What VALK was, and why it mattered

When I joined VALK in November 2019 I was the only designer. Not "lead designer with a team underneath" - actually the only one. Every pixel that shipped went through me.

The platform was built on R3's Corda blockchain for institutional digital assets. Private markets, illiquid assets, end-to-end transaction infrastructure for the kind of clients who don't mess around - 70+ financial institutions — investment banks, hedge funds, and asset managers — across 15+ countries. $4B+ in deals managed on a platform I designed.

I built the design system from scratch. The full transaction platform UX. A DeFi analytics product called Merlin that eventually pulled in 50K+ unique visitors and monitored $5B+ in portfolios. The company won multiple industry awards including Sell-Side Technology and Asset Management recognitions, and got covered in financial industry press.

I'm not listing those numbers to brag. I'm listing them because they matter for understanding what I walked away from. This wasn't a struggling startup I was escaping. The work was good. The platform worked. The clients were real institutions moving real money.

And I still left.

The boredom nobody talks about

Here's the thing about being solo designer at a B2B fintech for five years: you get really, really good at a very specific thing.

Institutional dashboards. Transaction flows. Data tables with 40 columns. Compliance screens. The UX patterns for "a hedge fund analyst needs to review a digital bond issuance at 2am from their phone" - I know that problem deeply. I could design it in my sleep, and toward the end, I basically was.

By 2024 I could sit down in Figma, design a complex fintech feature, spec it for the engineers, and write the documentation in a day. What used to take a week took a day. That sounds like growth but it's actually a yellow flag. When the difficulty drops that far below your current skill level, you're not learning anymore - you're executing.

The work was technically solid. I just stopped caring about it.

That's uncomfortable to say because VALK was a genuinely good product doing genuinely important infrastructure work. The people weren't the problem. The exit wasn't bad vibes - it was boredom and curiosity pulling harder than comfort.

When I started noticing the gap

March 2023. That's when I started doing AI work on the side.

Not because I had a plan. Because ChatGPT had just dropped and I couldn't stop thinking about what it could do. I started building small things - automation workflows, prompt systems, early agent prototypes. Nothing production-ready, just me poking at a new technology the same way I used to poke at new design tools.

The difference was how it felt. I was doing side projects at 2am and not feeling tired. That's the tell. When you're doing something that doesn't drain you even when it should, pay attention.

By mid-2023 I was building autonomous agents with custom personalities for community management and content creation. End-to-end automation workflows in n8n and custom Python. AI-powered music generation pipelines stacking GPT-4 + Suno + Midjourney + ElevenLabs into something that actually sounded like it was made by a person. Not demos - working systems I was shipping and iterating on.

Meanwhile at VALK, I was designing another data table.

The gap between the two tracks kept widening. By late 2024 it was obvious. I wasn't going to close it while staying in the same seat.

Why I didn't leave sooner

Honest answer: salary, stability, and the sunk cost of being good at something.

Five years of context in a product is genuinely valuable. I knew every edge case, every integration, every place the design system had technical debt. Starting over in something new meant being a beginner again - and being a beginner doesn't pay the same as being the person who built the whole thing.

There's also a particular trap that hits people who are technically capable: you can justify staying because the work isn't bad. It's not bad. It's just not growing you. "Not bad" is a terrible reason to stay somewhere, but it's a compelling one in the moment.

I also had no clear destination. "I want to do more AI stuff" isn't a career plan. I didn't have a product to go build, a company to join, or a client waiting. Just a direction. That's terrifying when you're used to a steady paycheck.

What finally tipped it was realizing I was doing the interesting work anyway - just not getting paid for it, and not going deep enough on it because I was saving bandwidth for the job. I had to make a choice about which track was real.

What actually made it hard to leave

This isn't a story about walking away from a soul-crushing corporate grind. I want to be clear about that because those stories are everywhere and this isn't one of them.

VALK was a legitimately good place to work. Async-first by nature - I've been no-calls only for years, and that environment respected it. The team was small and technical. The problem domain was interesting. I had real ownership over a real product.

The hard part was that I was leaving something good. Not escaping something bad. That's a different emotional math.

When you leave something bad, there's relief. When you leave something good, there's mostly just uncertainty. You're trading a known quantity for a direction.

I also felt something like guilt about my design craft. Five years of building that specific muscle - institutional fintech UX, complex data visualization, multi-jurisdictional compliance patterns - and I was shelving it. That felt like waste. It took me a while to see that the design background wasn't being shelved, it was being folded into something new. But I didn't have that clarity on the way out.

Why I left my role as solo product designer at VALK: the honest version

People want a clean narrative when someone makes a big change. The "I had an epiphany" story, or the "the company changed" story, or the "I always knew I'd do this eventually" story.

None of those fit.

The real reason I left my role as solo product designer at VALK after five years is genuinely mundane: I felt like a dinosaur. The world was changing fast, I was sitting still, and I couldn't make peace with that.

AI wasn't an abstraction to me by then - I'd been building with it for almost two years on the side. I knew what was possible. I knew what I could build if I went all-in. And I knew that every month I stayed was a month I wasn't building those things at the depth they deserved.

That's it. No grand vision. No ten-year plan. Just the thing that excited me most wasn't the thing paying me, and eventually that gap gets too loud to ignore.

What came next

February 2025 I went full AI specialist.

The work I've been doing since: building multi-agent systems, OSS CLI tooling, automation workflows that actually handle real complexity. My crypto background from 2021 - contributed to several successful multimillion-dollar token launches - means I'm not new to the intersection of technical infrastructure and product. The combination of design, AI engineering, and crypto is genuinely rare and I'm still figuring out how to use it.

What I'm not doing is pretending I have it figured out. Sustainable income without a salary is a real problem I'm actively working on. The freedom to build what I want comes with the anxiety of not knowing what next month looks like. That trade is live and unresolved.

What I do know: I'm not bored. I sit down to work and lose track of time. That's the benchmark I didn't know I was missing until I had it back.

If you're in a similar spot

I'm not going to tell you to quit your job and follow your passion. That's not advice, that's a bumper sticker.

What I will say: if you're doing the interesting work anyway - on nights and weekends, in the gaps between the real job - that's data. You're already telling yourself what you want. The question is whether you're listening.

The gap between what I was doing at VALK and what I could build with AI was too wide. For me, the answer was to close it. Your math might be different.

But "not bad" is not the same as "right." Know the difference.

If you want to follow what I'm building from here - multi-agent systems, AI tooling, the whole mess of going independent - this blog is where I'll document it. You can read more ADHD and AI, or browse by why most AI products have bad UX if you want to find something specific.

When design stops being enough

Mon, 16 Sep 2024 00:00:00 GMT

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.

The unglamorous work that makes design real

Mon, 11 Mar 2024 00:00:00 GMT

There's a Figma file sitting open on my second monitor right now. It has 2,347 frames. I know this because Figma tells me in the bottom-left corner, and I've been watching that number grow for four years. Not because I'm proud of it. It's just evidence of time.

My Behance portfolio, which I haven't updated since 2021, shows a campaign microsite I built at Spacecode in 2017. Clean screens, gradient overlays, a case study that describes my "approach to user-centered design." It has a few thousand views. The VALK work, five years of actual enterprise product design, the design system that scales across a white-label platform used by 70+ financial institutions, isn't on Behance. And even if I tried to put it there, I wouldn't know what to show. The interesting parts don't photograph well.

The stuff nobody posts on Dribbble

If you scroll Dribbble for fintech dashboard inspiration, you will see the same things: dark mode analytics screens with glowing charts, clean onboarding flows, pill-shaped buttons with just the right amount of padding. Everything is populated with beautiful sample data. Numbers that fit perfectly in their containers. Names that are exactly the right length.

You will not see the screen that shows when a user tries to initiate a token transfer but the counterparty's jurisdiction is flagged by the compliance engine, and the user has two of their own documents expired, and the transaction is above the threshold that requires additional review, and we're not sure if we should show one error or three or a combined message that explains the compound problem without creating legal exposure.

That's a real scenario I spent two days on. The final design is four lines of text and a link to a support page. It looks like nothing. It will never be on Dribbble.

The actual scope of a screen

Here's a habit that took me a while to build: when I add a new screen to the design system, I now immediately create a column of states beside it. Happy path, empty state, loading state, error state, partial data state, permission-restricted state, deprecated feature state for old clients who haven't migrated. Sometimes the permission-restricted state has three sub-states depending on user role.

In a typical case study, someone shows you one screen. That's one out of maybe eight.

The empty states are actually the ones I find most interesting now, micro-UX moments that most products completely abandon. An empty portfolio isn't just a blank table. It's someone who just signed up and has nothing yet, or it's an admin who cleared a category, or it's a filter combination that returned zero results, or it's a user who had data and it's been archived. Each one needs different copy and different next-action guidance. Treating them all the same is a visible failure in the product.

I've started writing the copy for empty states myself rather than leaving a placeholder for the content team. At our size, in our timezone situation, I'm in LA, the rest of the team is in London, if I leave a content placeholder, it might sit there for three weeks while we cycle through Slack threads about it. Better to write something decent and refine it than to block the build on copy.

The timezone problem and what it does to documentation

The eight-hour gap between Los Angeles and London changes how design work actually happens. By the time I'm fully awake and into focus, the London dev team has already had half their working day. If I send a message at 9am my time, they get it at 5pm theirs, end of day.

This means every handoff note I write has to stand on its own. No "ping me if you have questions" as a safety net. If the annotation isn't clear, work stops or, worse, implementation happens based on a wrong assumption, and I find out the next day when I'm looking at the build in staging.

I've become almost obsessive about handoff documentation as a result. Not in a precious way, just thorough. Every component in the Figma file has a sidebar annotation explaining the interaction, the constraint, the edge case. Every screen has a section for "implementation notes" that's separate from the design itself.

Does the dev team always read it? Not always. But when something ships wrong, I can locate exactly where the communication broke down, and that's actually useful for improving the process. The annotations have gotten better over four years because I started tracking which kinds of ambiguity cause problems in implementation. Spacing is never the issue. State transitions are always the issue.

File organization is design work

A Figma file with 2,347 frames can be navigated in about twenty seconds if the organization is right. It can also be a complete nightmare that drives everyone away from using the file and back to "just building from memory."

We have pages organized by product area, then by feature, then by component library, then by archive. Every deprecated design goes into archive with a label and a date. Every in-progress screen lives on a page called "WIP, [feature name], [my initials], [date]." When it's ready for review, it gets moved to the feature page and the WIP page is deleted.

This sounds boring to describe. It took three separate Slack threads over two weeks to agree on this system.

The naming convention debate is a real thing that happens at real companies, and it's not stupid, it represents genuine disagreement about how work should be organized and who the primary audience of the file is. Designers? Developers? Stakeholders? We ended up with a system that slightly annoys everyone, which means it's probably close to right.

The file organization is a design decision. If developers can't find the right frame, they'll find the wrong one. If the component library is messy, people stop using it and start building one-offs. A chaotic Figma file has a real downstream cost in implementation quality, and that cost is usually invisible because nobody traces a misimplemented UI back to the file structure that caused the confusion.

Accessibility annotations, the work after the design

Here's one I didn't do well in the early VALK years and have since tried to get more disciplined about: accessibility annotations in the design file.

Not just "make sure there's enough contrast." I mean the actual annotation layer that tells a developer the focus order of interactive elements on a complex dashboard, which elements need aria-labels and what those labels should be, how a screen reader should interpret a table with nested rows that represent different asset classes and their sub-holdings.

Financial data interfaces have particular accessibility challenges because they're so dense. A screen that shows a client's portfolio isn't like a simple form, it's a hierarchy of relationships between entities, and the visual hierarchy is doing a lot of work that a screen reader can't replicate without guidance.

I can't make those annotations exhaustive, there isn't time. But the key ones, on the key flows, matter. We've shipped screens where the developer inferred the wrong reading order because the visual layout was complex and I hadn't annotated it. Those are the bugs that take longest to notice and longest to trace.

Maintenance as the main job

At some point in the last year, I realized that the majority of my design work is now maintenance rather than creation. New features require touching existing components. A layout change in one area ripples into three other areas. The design system needs to absorb a new pattern without breaking the consistency of everything built before it.

This is what the fifth year of a product looks like. I don't think anyone warns you about it.

Agency work, which I did at Spacecode for several years before VALK, is almost entirely creation. You're always working on something new. The brief is defined, you design to it, you hand it off, it ships, you move on. I did this for projects with Kaspersky, with OTPBank, with a dozen other clients. The product I'm handing off is never my problem three weeks later.

At a product company, you live with the decisions you made two years ago. That component I designed in 2020, I look at it now and I can see exactly what I was thinking and where I was wrong. The constraint I worked around in 2021 is now part of the furniture, and building anything new means working around it again.

Maintenance is not lesser work. It requires a deeper understanding of the system than greenfield design. When I add a new state to an existing component, I have to know what every existing use of that component depends on, what will break, what will flex, what implicit assumptions developers have made based on the original design. This is harder than designing the component fresh.

It just photographs terribly.

What senior design actually looks like

I've been thinking about what "senior" means in the context of product design, because I'm at an age and stage where I'm supposed to have figured it out.

My best guess: senior design is characterized by exactly these unglamorous things. The documentation. The edge cases. The accessibility pass. The handoff so good that a developer eight timezones away can implement it correctly without a single clarifying question.

The flashy part, the thing that gets portfolio views and Dribbble follows, is maybe 20% of what I actually do. And it's the 20% that requires the least accumulated knowledge. Anyone can make a beautiful empty-state illustration. Fewer people can design the logic that determines which of your six empty states the user sees and why.

I'm not complaining. I'm mostly just noting the gap between what design looks like from the outside and what it is from the inside. The gap is bigger than I expected when I started.

The portfolio problem

My Behance sits there, quietly outdated. I look at it sometimes and feel a mild existential discomfort. The work I'm most proud of from my career is largely invisible. The tokenization platform I designed over five years has processed billions in transactions. The design system underpins a white-label product used by institutions across fifteen countries. None of this is postable in a way that generates Behance views.

The agency work, the OTPBank app redesign, a few splash sites, some brand identities, those are the projects that look impressive in a scroll. They have before-and-after moments. Defined scope that fits in a slide.

I don't have a solution to the portfolio problem. Maybe the people who hire senior product designers at serious companies understand that the visible portfolio is the least interesting part of the picture. Maybe they ask the right questions in interviews, how you handle edge cases, system maintenance, handoff documentation, and the Dribbble portfolio becomes almost irrelevant.

Or maybe everyone just pretends the flashy work is the whole job and we all collectively agree not to post screenshots of our 47 error state variants.

Either way, the work exists. The documentation is in the Figma file, annotated and organized, waiting for someone to implement it correctly. The edge cases are handled. The empty states say something useful.

That's enough, even when it doesn't look like anything.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

When your company pivots and your design work stops mattering

Mon, 18 Dec 2023 00:00:00 GMT

There's a specific kind of silence that comes after a pivot announcement. The Figma files don't delete themselves. The components are still there, organized in the same folder structure you spent weeks perfecting. The design system still loads. Everything looks exactly like it did yesterday. But you know, with quiet certainty, that most of it isn't going where you thought it was going.

That silence has been my companion for most of 2023.

Four years of product work

I joined VALK in November 2019 as the only designer. No design system, no component library, no brand standards beyond a logo and a color. I built everything from scratch, the tokenization platform interfaces, deal management flows, investor dashboards, cap table tools. Every modal, every empty state, every error message. I made the decisions about spacing scales and typography and when to use a table versus a card layout. It was genuinely mine in a way that product work rarely is.

When you're the sole designer at a company for four years, you develop a strange relationship with the product. You know where every skeleton is buried. You remember why that particular dropdown works the way it does, even though it looks weird, because of a compliance requirement that came in last-minute from a specific client. You carry four years of context in your head that isn't documented anywhere.

That's a lot to hold.

The pivot

I'm not going to pretend I didn't see it coming. The signals were there throughout 2023, conversations about market positioning, about where institutional blockchain was heading, about what VALK needed to become to stay relevant. Companies at this stage either find a bigger wedge or they stall. I understood the logic.

The decision was to move toward DatAI Network, a significant reposition toward on-chain data infrastructure. It's a real strategic bet, not a vanity rebrand. I can see why the leadership made it.

But here's what nobody really talks about: what happens to the designer when this happens?

The brand for DatAI came from an external design agency. Which is fine, that's often the right call for a major rebrand. Agencies bring fresh perspective, they move fast on identity work, they don't have four years of internal baggage coloring every decision. I understand why you'd go external.

But then you hand that brand to the sole internal designer and say: adapt this to everything we need.

Becoming a brand adapter

My job description didn't change. My title didn't change. But the actual work changed substantially.

For most of 2023, I spent roughly sixty percent of my time on presentations, slides, pitch decks, social media templates, and one-pagers. The product design work, the interfaces, the flows, the actual UX, became secondary. Sometimes it felt further back than that.

The deck designer trap is something I'd read about in passing but never thought I would fall into so hard. When I took this role in 2019, I imagined myself deep in interaction problems, thinking about how institutional investors process complex financial data, how to reduce cognitive load in a cap table view. And I did that work for years. It was the work I cared about.

Investor presentations are not that work. Social media graphics are not that work. They require skill and they require care, I'm not dismissing them, but they're not why I studied design. They're not the reason I spent nights in my early twenties reading about information architecture.

Working with someone else's brand guidelines after you've owned the brand for years is its own particular adjustment. The external agency did good work. The visual identity for DatAI is solid. But it's not mine, and adapting it feels like translating, I understand what they were going for, I can execute in their style, but I'm not speaking my own language anymore.

There's a small indignity in that. Nothing dramatic. Just a constant low hum of "this isn't quite what I would have done."

The emotional reality of watching your product get deprecated

I want to try to describe what it actually feels like, because I haven't seen many designers write about this honestly.

The VALK tokenization platform that I designed from 2019 to 2022, the one I sweated over, rebuilt the design system for twice, knew every edge case of, that product is not the future of this company. The Merlin DeFi tracker, which I designed and also did some of the frontend work for, is not the future either in its original form. These things still exist in some capacity but they're not where the investment is going.

Intellectually, I know this is just how startups work. Products evolve, strategies shift, things you built get superseded. I've seen it happen at other companies from the outside. Experiencing it from the inside, as the person who made those things, is different.

It's a quiet kind of grief. Nobody died. The company is still alive, actually taking a direction that might work out well. But the product I spent four years caring about, the one I could navigate with my eyes closed, the one where I knew exactly why every decision was made, that product is quietly being set aside.

You grieve it a little. I think you're supposed to.

What helped me recognize this was talking to a friend outside of design who went through something similar when their team's project got cancelled. They said: "The work was real even if the thing doesn't exist anymore." I've been sitting with that. The work was real. The thinking was real. The solutions to real problems were real. The product moving in a different direction doesn't undo four years of craft.

I mostly believe that. On good days I believe it completely.

What I'm actually doing with the frustration

The healthy answer would be "channeling it productively." The honest answer is: a mix of that and just feeling it.

I've become more rigorous about the work that is still mine. Even if sixty percent of my time is presentations, the forty percent that is product design gets more deliberate attention. When I do get to work on actual interface decisions for DatAI, I'm more conscious of it. I document more carefully. I write down my reasoning in ways I didn't bother to earlier in my career when everything felt self-evident.

I've also gotten more honest with myself about what this period means professionally. Four years at one company is a long time, especially in this industry. I've grown enormously here, I understand institutional finance in ways I couldn't have predicted when I was 23 and had never worked in fintech. I can read a cap table, have an actual conversation about tokenization mechanics, understand compliance constraints intuitively. That knowledge is real and it's mine regardless of what direction the company takes.

But I'm starting to think about what comes next. Not urgently, not with resentment. Just honestly. When a company pivots and the role quietly transforms into something different from what you signed up for, it's a reasonable moment to ask whether this is still the right place to be developing as a designer.

I don't have a clear answer yet. But the question is there, and ignoring it would be worse than sitting with it.

Getting good at adapting someone else's vision

There is one thing I've had to genuinely learn this year, and I want to give it credit rather than just frame it as frustration.

Executing within someone else's brand system, when that system is good, is actually a real skill. The DatAI visual language has a logic to it, and understanding that logic well enough to extend it coherently is not nothing. I've made hundreds of small decisions about how to apply their system to contexts the external agency never anticipated. Data table treatments, mobile breakpoints, slide layouts with very different content densities, loading states and error conditions.

None of that is as satisfying as building the system from scratch. But it's not mindless either. It's a different kind of craft.

I've noticed that I'm more opinionated about this kind of work than I expected to be. Even within external guidelines, there's room for judgment calls. What counts as "on brand" in an edge case isn't always specified. Those small judgment calls are where I can still leave fingerprints.

Tofu

I'm going to end this on something unrelated to design because 2023 deserves to be remembered for more than just the pivot.

In early December we got a Maltese puppy. His name is Tofu. He weighs about five pounds and has the energy of something much larger and the expression of a small emperor who is not fully certain the world is being run correctly.

Getting a puppy is objectively chaotic. The sleep disruption, the constant supervision, the steep learning curve of understanding what he needs and when. My partner Anna and I have had approximately zero chill since he arrived.

It is also the best decision of the year. Possibly of several years.

There is something clarifying about a small creature who needs you reliably and completely and doesn't care at all about product pivots or brand guidelines or whether the deck you made looks good on a 4K display. Tofu needs a walk and some food and someone to play with. That's the whole thing. That simplicity, right now, is kind of a gift.

I was skeptical of the "get a dog for your mental health" narrative before this. I understand it now.

Some kind of conclusion

I don't think I have a tidy takeaway from this year. The honest version is: when your company pivots significantly and you're the sole designer, you absorb a lot of the disruption in ways that aren't always visible to the rest of the team. Your past work quietly becomes legacy. Your role quietly becomes something different. And you have to figure out, largely on your own, how to feel about that and what to do with it.

I'm not bitter about VALK or the pivot. Companies have to make strategic decisions, and this one makes sense. The people I work with are good. The mission, in its new form, is real.

But I also think the designer's experience of a company pivot is worth talking about more honestly than it usually is. You don't just update the Figma files and move on. There's context you lose access to, craft that gets deprecated alongside the product, a version of the job that quietly disappears while the title stays the same.

You mourn it a little. You adapt. You find where your fingerprints can still land.

And sometimes you get a five-pound Maltese puppy who needs a walk right now, actually, and does not care about any of this at all.

That helps more than I expected.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Agency vs product design - why I'm not going back

Tue, 05 Sep 2023 00:00:00 GMT

Someone asked me recently if I'd ever go back to agency work. A friend from Moscow, still at a studio there, sending me their latest case study, thirty screens, beautiful gradients, a banking app they'd designed in six weeks. It looked incredible. I remembered that feeling. The rush of building something polished from nothing, handing it off, moving on.

My answer was no. And it surprised me a little how certain I was.

I spent almost two years at Spacecode in Moscow before joining VALK. Lead UX/UI, team of five or six designers, somewhere over fifty apps shipped across my time there. Kaspersky, OTPBank, fintech startups, retail, events platforms. Then I joined VALK in late 2019, one product, one designer, and now nearly four years later I'm still here, still the only designer, still working on the same platform that grew into something I couldn't have imagined at the beginning.

These are genuinely different careers. Not just different jobs. Different ways of understanding what design even is.

What agency taught me (and it taught me a lot)

I want to be honest about this because I see product designers dismissing agency work, and it's unfair.

Spacecode made me fast. Not reckless, actually fast in the right ways. When you're shipping a full product every six to eight weeks, you develop instincts that most product designers never build. You learn which decisions actually matter in week one versus week three. You learn to kill your darlings quickly because there's no time for attachment.

The visual polish I developed there still shows up in my VALK work. Working across so many industries meant exposure to dozens of design patterns I never would have seen otherwise. Banking interfaces, event apps, security software, every project had its own logic, its own user behavior, its own constraints.

Leading a team taught me something too. Reviewing junior work, running crits, helping someone understand why their hierarchy isn't working, you understand your own craft better when you have to explain it. I mentored five or six junior designers at Spacecode. Some of them are probably running their own teams now.

The client presentations also hardened me in a useful way. You learn to defend your decisions to people who don't speak design, who have opinions about colors, who want something "more modern" without knowing what that means. You either develop the language to handle that or you get eaten alive.

What agency didn't teach me

Here's what I didn't understand when I was at Spacecode: I thought design ended at delivery.

It was built into the structure of the work. You shipped the app, wrote up the case study, moved to the next one. Whatever happened after, whether users actually used it, whether the flows made sense in production, whether the edge cases held up, that wasn't really your problem. Not because anyone was cynical about it. Just because the project was over.

I had no idea how much of design happens after that point.

Six weeks is not enough time to understand any domain properly. I designed a banking app for OTPBank and I didn't really understand how the back-office flows connected to what users saw. I made it look right and feel usable, but the deeper logic of the system, the compliance requirements, the actual user journeys across months of usage, I only touched the surface. The timeline didn't allow anything more.

At Spacecode I was always the expert in the room on design. Nobody challenged me on UX decisions in any fundamental way because nobody knew more about it than I did. That felt good. It took me a while at VALK to realize how much I'd been missing by never being challenged by the product itself, by real users, real edge cases, real feedback over time.

And the client politics. That I don't miss at all. Redesigning a section because someone's director had a different opinion. Reverting to an earlier version a week after approval. There's a particular kind of exhaustion that comes from designing things you don't believe in, knowing the real reason they look that way has nothing to do with users.

What changed when I moved to product

I joined VALK in November 2019. Asset tokenization for institutional investors, the kind of domain I knew almost nothing about. In my first month I was reading about private securities and permissioned blockchains in the evenings, not because anyone asked me to, but because I couldn't design interfaces for things I didn't understand.

That was the first shift. Agency work doesn't require you to become an expert in the domain. Product work absolutely does.

By the time VALK had scaled to seventy-plus financial institutions across fifteen countries, I understood the platform in a way that's hard to explain. I knew which compliance fields caused friction. I knew which flows our institutional users took shortcuts through because the documented path was too long. I knew what "tokenization" meant not as a marketing term but as an actual technical and legal process with very specific UX requirements.

You can't get that knowledge in six weeks. You can barely get it in six months.

The depth of product design compresses over time, not over sprints. The fourth year of working on something reveals problems you couldn't have seen in the first year, because those problems are created by the decisions you made in the first year.

Ownership changes how you design

At Spacecode I was responsible for the design. At VALK I'm responsible for the product experience.

Sounds like a small distinction. It isn't.

When you're the only designer on a product and you'll still be there six months after a feature ships, you make different decisions. You think about edge cases you'd normally cut for timeline because you know you'll be the one fixing them later. You document things properly because future-you will need that documentation. You push back harder on product decisions because when something ships wrong, there's nowhere to point except yourself.

The "not my problem" mindset that was almost structurally required at an agency, it genuinely doesn't exist in product. Everything is your problem. Which is harder, but also more honest about what design actually is.

I think about the features we built in 2020 that are still running, still being used by banks in multiple countries. The interactions I designed then are being experienced by someone right now. That's a different relationship with your work than handing off a file and writing a case study.

The loneliness is real

I don't want to make product design sound like a straightforward upgrade.

At Spacecode I had people to challenge my work every day. Someone to catch the thing I'd stopped seeing because I'd stared at it too long. Someone trying a completely different approach while I was heads-down on mine. Creative friction is real and it makes work better.

At VALK, that friction has to come from somewhere else. From developers who catch technical impossibilities. From the CEO when something doesn't match the product vision. From my own discipline to step back and question decisions I've already made. It's a skill you have to develop deliberately when working solo, the ability to challenge yourself.

Some days it's fine. Some days I'll spend a week going in circles on a problem that twenty minutes with another designer would have solved.

The repetition is also real. Four years on the same product, there are moments where the novelty is completely gone. I've redesigned sections of this platform two or three times. The onboarding flow I'm touching now is something I've touched before. You have to find different sources of interest when you know a product this well. It moves from "how does this industry work" to "why is this specific interaction still creating friction after all this time."

What actually transfers and what doesn't

The speed of execution stayed. The ability to produce clean, considered work quickly, that's just muscle memory and it doesn't care whether you're on week two of a six-week sprint or month three of a product roadmap. The visual craft transferred. The ability to defend design decisions to non-designers transferred.

What didn't transfer: the way I thought about timelines.

My natural agency instinct was to think in terms of "done when delivered." That took real time to unlearn. Products don't have a delivery moment, they have a current state that will change. Every decision you make is technically provisional. That's a genuinely different mental model and I underestimated how long it would take me to internalize it.

The "make it look good" instinct also needed recalibrating. Not removing, visual quality matters enormously, especially in fintech where trust signals are tied to perceived polish. But at an agency, looking good is the deliverable. At a product company, looking good is in service of something working right. Related, but not the same thing.

What I actually learned

Here's something I've been thinking about. I learned design at Spacecode. I became a designer at VALK.

That's not meant to diminish the agency years, they gave me a foundation I couldn't have built any other way. The speed, the breadth, the craft. But understanding what design is for, how it sits inside a living product that real users depend on, how your decisions compound over years, that I only learned by staying.

The version of me who joined VALK in 2019 thought of design in terms of screens and flows and handoffs. The version sitting in Los Angeles in 2023 thinks in terms of systems, tradeoffs, and user relationships that extend across time.

I don't know if that evolution was inevitable or if it required the specific circumstances, a single product, a small team, no other designer to defer to. Probably both. The constraints of being the only designer forced a kind of engagement with the product that might have been easier to avoid otherwise.

The question isn't "how do I make this screen work." It's "why is this problem appearing at this point in the user's experience and what does that tell us about the system."

That's the question I couldn't ask properly at an agency. There was never enough time and never enough continuity.

Would I go back? No. Not because agency work is bad, it was genuinely formative and I respect the designers who do it well. But I've seen what the other side looks like, and I want to keep designing things I'll still be accountable for a year from now.

That accountability is uncomfortable sometimes. It's also the most honest version of what this work actually is.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Four years designing one product

Sun, 28 May 2023 00:00:00 GMT

Sometime last month I opened the VALK Figma file looking for a component I built in 2020. I needed to check how I'd handled a particular empty state, one of those obscure screens that appears when an investor has no active deals. I found it eventually, buried somewhere around frame 1,400. The page has thousands of frames now. I remember when it had forty.

That empty state? I'd designed it in three hours one afternoon in Alanya, Turkey, sitting at a rental apartment desk with a ceiling fan that made too much noise. A throwaway decision. Grey illustration, short line of copy, a button. Three years later it's still there, unchanged, shown to asset managers at seventy-something financial institutions. I stared at it for a few minutes and felt something I couldn't name exactly, not embarrassment, not pride. Something more complicated than either.

Four years. Same product. Same Figma file. Same codebase underneath everything I've drawn.

What agency work taught me (and what it didn't)

Before VALK I spent two years at Spacecode, a Moscow agency. In that time I touched something like fifty-plus projects, banking apps, security dashboards, enterprise tools, consumer products. We'd sprint into a new domain every few weeks, learn enough to design something coherent, hand it off, move on. Every Monday felt like a new puzzle.

I got very fast at Spacecode. That's the main thing. Fast at reading a brief, fast at identifying the shape of a problem, fast at generating concepts. Speed was survival there. A week of slow output had real consequences; other projects were waiting, other clients were calling.

What the agency years couldn't teach me was depth. You can't develop depth in six weeks. You understand the surface of a problem, sometimes the layer below it, but you rarely get to the ground. You hand off your designs and you never find out if the empty state you designed in three hours becomes a permanent fixture that thousands of people see every year.

At VALK, I found out.

The weight of accumulated context

The thing about staying with one product for four years is that you know it the way you know your own apartment. Where the awkward corner is. Which drawer sticks. Every workaround that got quietly institutionalized.

I know every edge case in the VALK platform, not from documentation, but from having created the edge cases, discovered them, patched them, or consciously decided to live with them. I know which design decisions were made under deadline pressure in 2020 that became load-bearing by 2021 when we scaled to dozens of institutions. I know which navigation pattern was "temporary" and is now four years old and woven into how every user expects to move through the product.

This kind of knowledge is genuinely useful. When someone proposes a change to the deal management flow, I can trace second and third-order effects almost automatically. I can say "if we move that action here, it creates a conflict with how compliance users approach the same screen from a different entry point", and I know this not because I ran a workshop, but because I lived through the version where it was different and watched what happened.

The weight of that context, though, is real. Every new design decision carries the shadow of every past one. Early on I could move quickly because I didn't know what I didn't know. Now I know too much. I know which assumptions are fragile. I know which constraints are genuinely immovable and which ones just feel that way because they've existed for two years. Making confident decisions has become harder, not easier.

I don't think most design writing is honest about this. There's an assumption that experience makes you faster and more decisive. It can. But with enough context, it can also make you slower, because you genuinely understand the complexity you used to move through without noticing it.

The "quick fix" that never left

In early 2020, we had an urgent issue with how deal documents were displayed in the investor portal. The hierarchy was broken, the most important documents were getting lost. We had a release coming. I designed a fix in an afternoon, a card pattern with status indicators I'd never used in this product before, borrowed from something I'd built at Spacecode.

It worked. The release went out. Nobody complained.

By the end of 2020, that pattern had propagated into four other sections of the platform. By 2021, when financial institutions were onboarding rapidly, it was part of the visual language new users learned first. By 2022, it was referenced in our onboarding materials.

I never formally chose that pattern. I chose it under pressure on one specific afternoon, for one specific problem, in a city I'd only been in for a few months. It's now one of the most recognizable UI elements in a product used by banks and hedge funds across fifteen countries.

There's no such thing as a temporary decision in a living product. Whatever you ship becomes the baseline. The longer it survives, the more weight it carries, until removing it feels like surgery rather than editing.

The loneliness of being the only designer

Something I rarely write about directly: in four years at VALK, I've been the only designer. No one to compare notes with, to catch my blind spots, to share the particular frustration of caring about UX in an organization full of people who care about other things.

At Spacecode there were other designers around. Not always on the same project, but present. You could ask someone to look at a flow. That kind of creative friction is valuable in ways that are hard to appreciate until it's absent.

At VALK, the product vision lives almost entirely in my head. Mostly that's fine, I've made peace with it, found ways to create useful friction through documentation, through forcing myself to write out rationale rather than just designing it. But there are moments, usually when I'm sitting with a difficult problem that has no clean answer, where I'd give a lot to have another designer in the room. Not to validate me. Just to think alongside.

The Figma file with its thousands of frames is a conversation I've been having with myself for four years. That's its own kind of loneliness.

Patience and restraint, the skills I didn't know I needed

Agency work rewards output. The artifact matters because the client is evaluating the artifact. The velocity is visible and measurable.

Product work rewards restraint. The best decisions I've made at VALK in the last two years are things I didn't do, flows I didn't redesign, patterns I didn't change, features I pushed back on. These don't show up in a portfolio. There's no frame in Figma that says "Dmitry resisted the urge to redesign this for the third time and the product was better for it."

When you're redesigning something that real users with real professional responsibilities depend on, the cost of disruption is higher than the cost of imperfection. You learn to sit with imperfect solutions while you gather enough evidence to justify changing them. You learn the difference between something that's wrong and something that just bothers you.

That second category is bigger than I expected.

Restraint is harder than it sounds. Especially when you've been looking at the same interface for four years and you can see every flaw. You know you could make it better, but "better" has to be weighed against the transition cost to people who've built workflows around the current version. That calculation doesn't exist in agency work. In agency work, better is always worth it, because nobody has a workflow yet.

When variety is a feature, not a distraction

I'd be lying if I said I don't miss the agency rotation sometimes. The context-switching was exhausting but the variety was genuinely stimulating, every new project a new vocabulary to learn.

Here in Los Angeles, I sometimes catch myself scrolling through design work online and feeling something like nostalgia for problems I've never actually worked on. Healthcare UX. Education platforms. Tools for creative professionals. I've spent four years getting deeply fluent in one domain, private capital markets, asset tokenization, institutional finance. That fluency is real. But it's also a kind of narrowing.

Depth and variety pull in opposite directions. You can get both if you move between deep-product roles over time, but within a single job, the longer you stay, the more specialized you become. I know this product. I do not know what I would do with an unfamiliar problem the way I did in 2018. Some of that flexibility has been traded for expertise.

Whether that's worth it is a question I'm still working out.

What four years actually builds

There's a kind of satisfaction in long-term product ownership that has no equivalent in agency work. When I watch a financial institution use a flow I designed two years ago, watch them navigate it efficiently, without friction, as if it's obvious, that's different from watching a client approve a prototype. The approval is gratifying. The actual sustained use is something else. Evidence that you built something real.

I've designed for people who have real professional stakes in the product working correctly. Not user-testing participants. People who depend on this software to manage actual capital. That responsibility has made me a more careful designer than any brief or deadline ever did.

Agency taught me speed. Product taught me discipline. I needed both, but I had to learn them separately, and I couldn't have told you that in advance.

A question I keep coming back to

In the last few months I've started to notice a thought that keeps returning. Not anxiously, but persistently.

How many more years of this?

Not because I want to leave, I'm genuinely invested in what VALK is building. But four years is a long time with one product, and I find myself wondering when deep expertise tips into insularity. When does caring deeply about one product become a limitation on your growth as a designer?

Some designers spend a decade with a single product and produce extraordinary work. Others need the rotation to stay sharp. I'm still figuring out which kind I am, which feels like an odd thing to still be working out at four years in.

The Figma file keeps growing. The empty state from 2020 is still there, ceiling fan and all.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Accessibility in fintech is legally required, not optional

Mon, 20 Feb 2023 00:00:00 GMT

We almost lost a deal because of color contrast.

Not because our feature set was wrong, or pricing was off, or the demo went badly. The procurement team at a mid-sized European asset manager sent back a compliance checklist. Buried in section four was an accessibility clause, WCAG 2.1 AA conformance required across all user-facing interfaces. We didn't have documentation for that. We barely had a consistent focus state.

I spent the next six weeks doing the most humbling work of my career.

That was early 2022, but the lessons are still shaping how I build things now. I want to write about this properly because most accessibility content I find online is written for consumer apps, "make sure your button has enough contrast" and "add alt text to images." That advice isn't wrong, but it misses the specific complexity of financial interfaces. The stakes are different. The UI is different. In regulated markets, the legal framing is different too.

Why finance treats accessibility differently

Consumer apps treat accessibility as a moral good, which it is. But in practice it ends up on the roadmap between "dark mode" and "better onboarding", always almost prioritized, rarely actually done.

Financial services don't have that luxury. In the UK and EU, financial institutions must comply with accessibility standards as part of broader digital inclusion and anti-discrimination frameworks. The European Accessibility Act will require compliance for most financial services by 2025. UK's Equality Act 2010 already applies. WCAG 2.1 AA is the technical baseline that regulators and procurement teams reference when they actually check.

When I first joined VALK in 2019, I thought of accessibility the way most product designers do, something to layer on after the core experience is built. After the procurement checklist incident, I understood that framing was wrong. Accessibility is a sales requirement in enterprise fintech. If your platform fails an institutional client's compliance audit, you don't get a second meeting. You lose the contract. Potentially millions in annual recurring revenue.

The business case writes itself. The hard part is the implementation.

The data visualization problem

Charts and data visualization are where financial interfaces get genuinely difficult from an accessibility standpoint.

Our platform had portfolio performance charts, yield curves, asset allocation breakdowns, common enough. The challenge is that a meaningful chart in finance often has eight to twelve data series. You're comparing multiple assets, multiple time periods, multiple metrics, and you need to differentiate them visually.

The standard solution is color. Give each series a different color. But WCAG 2.1 requires sufficient contrast not just between text and background, but between any UI components that convey information. If you're relying purely on color to distinguish line A from line B on a dark background, you're failing users with color vision deficiencies, statistically about 8% of men.

Here's what I discovered while testing: I am on the edge of that statistic myself. I ran a colorblindness simulation through one of our chart views and realized I genuinely couldn't distinguish two of the data series in our default palette. I'd been designing those charts for two years and never noticed, because I'd always been looking at them with labels and legend context in view. Strip those away and the colors blur together.

The fix was not just changing the palette. We added pattern fills to area charts, made line charts use distinct dash patterns in addition to color, solid, dashed, dotted, long-dash. Every data series got a unique combination of color and shape marker and line style. It made the charts more complex to build but actually more readable for everyone.

For color specifically, I moved to a palette designed around perceptual distinctness rather than aesthetic preference. Colors that look great together on Dribbble are often terrible for colorblind users. I now test every palette in grayscale first, if the data series are indistinguishable in grayscale, color was doing too much work.

Screen readers and financial data tables

Our cap table management interface had tables with nested headers. Parent columns with child columns. Rows representing investors, sub-rows representing individual transactions under each investor. It looked clean and logical visually.

Screen readers hated it.

WCAG requires that data tables use proper semantic markup, scope attributes on headers, thead and tbody correctly structured, aria-label on tables where the heading isn't obvious. When a table has merged cells or multi-level headers, you need headers attributes that explicitly associate each data cell with the correct header cells. It is tedious. It is invisible work. And it's absolutely necessary for a screen reader user to understand that a number belongs to Q3 revenue for Investor B, not Q3 revenue in general.

I had to go through every table in the platform and audit the actual HTML output from our frontend components. Some of our tables were being generated from a grid library that didn't produce accessible markup by default. We had to either configure it differently or wrap the output with additional attributes.

The honest reality: I couldn't test this alone. I don't use VoiceOver as my primary interface. I spent time reading, watching screen reader users navigate financial data on YouTube, running tests with NVDA on Windows. You notice things quickly, how a screen reader announces "column header, column header, data cell" without context if the table structure is wrong, how it reads cells in an order that makes no sense if the DOM order doesn't match visual order.

Getting this right took longer than any other part of the accessibility work.

Keyboard navigation in a trading interface

Some of our institutional users, particularly at larger firms with strict IT environments, operate in contexts where mouse use is limited, or where power users prefer keyboard navigation for speed. And some users cannot use a mouse at all.

Our deal approval workflow had a problem. Five-step modal flow: review deal terms, confirm investor details, upload signatures, submit. Visually clean. Keyboard-only, a nightmare.

Focus wasn't being set when the modal opened, so a keyboard user had to Tab through the entire page to reach the modal content. Tab order inside the modal was inconsistent because of how we'd structured the component layers in Figma and translated them to DOM. Closing the modal didn't return focus to the element that triggered it.

These are all WCAG 2.1 failures. The spec is specific: when a dialog opens, focus must move into it. When it closes, focus must return to the trigger. Interactive elements inside must be reachable by keyboard in a logical sequence.

Focus management is one of those things that feels like a frontend problem, not a design problem. I disagree. If I hand over a modal design without specifying where focus goes when it opens, what the Tab order is inside, and what happens when it closes, I'm leaving that decision to a developer who may or may not think about it. Most won't. They'll focus on making it work visually.

I started annotating focus flows directly in Figma. A simple overlay showing Tab order with numbered indicators, plus callouts for focus trap requirements. It added time to my handoffs but removed ambiguity. The dev team said it was the clearest accessibility documentation they'd received.

Retrofitting is painful, designing with it from the start is less painful

By the time I did the accessibility audit, our component library had been accumulating debt for about two years. I had to open every component, buttons, inputs, dropdowns, modals, table cells, status badges, notification toasts, and check them against WCAG criteria.

The status badge problem was particularly instructive. We used color to indicate deal status: green for approved, yellow for pending, red for rejected. Just a colored pill with a text label inside. I assumed the text label was sufficient.

It wasn't.

WCAG's guidance on color dependency says color cannot be the only visual means of conveying information. The text label helped, but users with low vision who increase font sizes might see the pill without context. Screen readers announce the text, not the color. The fix was to add an icon to every status badge, a checkmark for approved, a clock for pending, an X for rejected. Now color, icon, and text all communicate the same state independently.

This sounds minor. Multiplied across twenty different status types in a complex financial platform, it's significant design and development work. Doing it as a retrofit, touching every instance of every component and every place they appear, took far longer than it would have if I'd built it correctly from the beginning.

That's the real lesson. Accessibility isn't expensive when you design for it. It's expensive when you ignore it until an audit forces you to go back.

The plugins that helped and the ones that didn't

I used several Figma plugins during the audit and redesign process.

Contrast and A11y - Color Contrast Checker are genuinely useful for checking text contrast ratios quickly. I used these constantly. They're not perfect, they check static frames, not interactive states, so you still have to manually check hover states, focus states, and disabled states. But for baseline checking they save significant time.

Color Blind by Stark is the plugin that changed how I work. It simulates eight types of color vision deficiency directly on your Figma frame. I now run this on every screen with a chart or color-coded data before finalizing. The simulation that caught the issue in our chart palette was worth the plugin alone.

Able has a more comprehensive checklist approach. I found it useful for learning what to check, less useful as a daily workflow tool, the checklist becomes repetitive once you've internalized the requirements.

What no plugin replaces: actually using a screen reader. Figma plugins check design files, not the live product. The real test is in the browser, with VoiceOver or NVDA, navigating the actual interface. Design tools can give you a head start, but compliance requires live testing.

The institutional client dynamic

Something specific to enterprise fintech that doesn't get discussed enough: your actual users are not always the ones who decide whether to buy your product.

A portfolio manager at an asset management firm uses our platform daily. But the decision to purchase was made by a procurement team that evaluated security documentation, data handling policies, regulatory compliance evidence, and accessibility conformance documentation.

The procurement checklist asks whether you comply with WCAG 2.1 AA. There's a checkbox. It doesn't ask whether your users find it delightful or whether the onboarding is smooth.

After the near-miss in early 2022, we commissioned a third-party accessibility audit and got a conformance report. This document, a dry, technical PDF listing which WCAG criteria we pass and which had been remediated, became a sales asset. It goes in the proposal alongside our security certifications. When a new institutional prospect asks about accessibility compliance, we have documentation.

That's the reality of selling into banks and asset managers. Their IT and compliance departments have requirements. Meeting those requirements is not differentiating, it's qualifying. You need it just to be in the room.

What I'd tell someone starting this work now

Understand the standard first, not the tools. WCAG 2.1 is publicly available and readable. The actual criterion text is denser than it should be, but there are good plain-language guides. Understand what AA requires, it's more specific than most designers realize, and less overwhelming than many fear.

Design for redundancy. Status, state, and meaning should never be communicated by color alone. Add icons, labels, patterns, shapes. Redundancy in information design is not clutter, it's clarity.

Annotate focus behavior in your handoffs. Specify where focus goes when a modal opens, what the Tab order is, what happens when interactive elements are added or removed from the DOM dynamically. Don't leave it implicit.

Test in the live product, not just in Figma. Plugins help. The real interface is where compliance happens or fails.

And if you're working in financial services: treat this as a business requirement. The moral argument matters, but in enterprise sales, it doesn't get procurement to check the box. The conformance report does.

I'm still refining how we approach this at VALK. The DeFi interfaces we built for Merlin brought a different set of challenges, more dynamic data, more complex state, but the same underlying principles. Accessibility isn't a project you complete. It's a constraint you design within, from the start.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Designing Merlin for 5 million Ledger Live users

Mon, 12 Dec 2022 00:00:00 GMT

The notification came through on a Tuesday morning. I was sitting at my desk in Los Angeles, coffee still too hot to drink, window light coming in at that flat California angle, when our CEO sent a message in Slack with the Ledger announcement link. "This goes live December 8th. Five million users."

I read it twice.

For almost three years at VALK I had been designing for a very specific kind of person. Institutional. Experienced. Someone who reads a data table the way most people read a headline. Our typical Merlin user was a portfolio manager or DeFi analyst, someone who wanted every number visible at once and would consider a simplified view an insult. Building for that audience has its own challenges, but you at least know who you are building for.

Five million Ledger hardware wallet users is a completely different population. Most of them bought a Ledger to keep their crypto safe. Many had never looked at a portfolio analytics tool in their life. And starting December 2022, Merlin was going to appear inside their Ledger Live app.

This is the story of how that happened from a design perspective, and why it was the hardest thing I had worked on in my career up to that point.

How Merlin and Ledger Live actually work together

For context: Ledger Live is the companion app for Ledger hardware wallets. You plug in your device, manage your assets, see your balances. In late 2021 Ledger opened up a "Discover" section, a curated marketplace of third-party DeFi apps that live inside Ledger Live as embedded experiences. You don't leave the Ledger app. You open Merlin from within it, your wallet connects automatically, and you see your analytics.

This sounds clean in theory. In practice it meant Merlin was running inside an iframe inside Ledger's app, with Ledger's navigation chrome wrapping everything, on a screen size we didn't control, for users who had never used our product before and hadn't specifically searched for it. They just saw it in a list and tapped.

That last part is important. Our existing users came to Merlin with intention. Ledger users might arrive with nothing more than curiosity. The context of use was completely different, and the design had to account for that from the very first pixel.

The scale problem isn't just numbers

When people say "design for scale" they usually mean technical scale, can your infrastructure handle traffic. That's a real concern and I spent time talking to our engineers about load considerations. But for a designer, scale means something more specific: can the experience hold together when it's being used by people with wildly different goals, different levels of expertise, different devices, and different amounts of patience.

Our existing Merlin interface was built around density. You could see your DeFi positions across protocols, P&L in USD, yield rates, impermanent loss, all on one screen, all updating in near real-time. For an analyst who lives in spreadsheets, this is ideal. For someone who just wants to understand if their crypto portfolio is up or down today, it's overwhelming.

I had done some level of this translation before at Spacecode, where I built apps for both enterprise and consumer audiences in separate projects. But I had never had to take one product and make it work for both simultaneously. That constraint is what made this interesting and difficult.

The answer wasn't to dumb things down. It was to restructure what was visible by default.

Designing the simplified entry layer

I spent the first two weeks after getting the integration brief doing something I almost never do in my normal workflow: making very rough paper sketches before touching Figma. Not because paper is magical, but because I needed to think through hierarchy without getting distracted by how things looked.

The core question I kept coming back to: what does a new user need to understand in the first 30 seconds?

For our institutional users the answer was "everything." For a Ledger user arriving via Discover, I decided the answer was simpler, how much your portfolio is worth, whether it went up or down, which protocols it's sitting in. Everything else, the detailed yield breakdowns, the historical curves, the per-position P&L, could live one tap deeper.

This sounds obvious when I write it out. In practice it required rethinking component hierarchy in ways that touched almost every screen. Some data that was in the primary layer for institutional users moved to an expanded detail view. Some charts that were visible by default became accessible only after a user actively opened a position.

The hardest part was doing this without breaking the experience for existing Merlin users. The product had to work for both audiences from the same codebase. So we weren't building a separate simplified app, we were building a layered version of the same app, where the default state was more accessible and the full complexity was still reachable.

I built this out in Figma as two parallel flows with shared components, color-coded in a way that made it obvious which decisions affected both experiences and which were specific to one. This became the working document I kept open for the entire integration period.

The mobile problem I had been avoiding

Merlin was designed as a desktop-first product. This wasn't an accident, our institutional users worked on large monitors and needed the data density that screen real estate allows. I had done mobile explorations before but never treated it as primary.

Ledger Live is mobile-first. A significant portion of the five million users access it primarily on their phones.

I had roughly two months to redesign the core Merlin analytics experience to work on a 375-point-wide screen without losing the data accuracy that was the product's entire value proposition. Not a comfortable timeline.

What I ended up doing was prioritizing ruthlessly. The desktop layout had a lot of simultaneous panels, protocol list, position details, portfolio chart, summary header all visible at once. On mobile this becomes a vertically stacked flow with a single dominant view at each step. The portfolio value and daily change sit at the top. Protocol cards scroll below. You tap into a protocol to see positions. You tap into a position to see the full breakdown.

Each step reveals exactly one layer of additional information. No more. This sounds like basic mobile UX; and it is, but getting there from a desktop-first design system required rebuilding a lot of components from scratch rather than just resizing them. Resizing doesn't work. The components have to be rethought for how touch interaction works and for how much space a thumb can comfortably reach.

I got it done, but if I'm being honest, some of the mobile screens launched in a state I wasn't fully satisfied with. The performance on older Android devices was inconsistent. Some of the interactions felt slightly off. When you have a hard integration deadline, you ship what you have and iterate after. I have a list of things to improve in Q1 next year.

The design system negotiation

This was the part of the project nobody tells you about when they pitch you a major integration partnership.

Ledger has their own design system. Clear visual language, their own component library, their own rules about typography and interaction patterns. It makes sense, they've built a complex product that millions of people use daily and they have standards for how third-party apps inside Ledger Live should feel.

Merlin also has a design system. We built it over about a year and it reflects the specific needs of financial data display: the way we handle number formatting, the color logic for gains and losses, the density of our data tables.

When your product lives inside another product's chrome, there's an immediate question: whose system wins?

The answer, in practice, is "both, uncomfortably."

I had several calls with Ledger's design team during the integration process. They were professional and collaborative, this wasn't adversarial. But there were real moments of tension. They wanted certain interface elements to follow Ledger Live conventions because consistency across their Discover apps matters for their users. I wanted to maintain Merlin's visual identity because we were also going to announce this integration publicly, and having our product look like a Ledger white-label inside our own marketing felt wrong.

We ended up with a compromise that I think worked reasonably well. Merlin kept its core color system and the way it displays financial data. The outer interaction patterns, how modals behave, how navigation cues work, followed Ledger Live conventions more closely. The navigation chrome was entirely Ledger's. The data presentation inside was entirely ours.

Some of the visual tension this created is visible if you look carefully. I notice it. Most users probably don't.

The work that doesn't show up in the product

After the integration itself was done, or mostly done, there was another full cycle of work that I had to do as the sole designer: the announcement.

An integration of this scale is a major marketing moment. We were telling the world that Merlin was now available to five million Ledger users. That story needed to be told visually across pitch decks, social media graphics, press materials, and the blog announcement.

I have written before about how much of my time at VALK goes into this kind of communication design rather than product design. For this integration it was significant. I built the announcement assets in Figma alongside the product work, sometimes literally in the same working session, switching between the product file and the marketing file.

The deck for the announcement had to simultaneously explain what Merlin is (for people discovering us through the Ledger news), what the integration means technically, and why it matters for DeFi portfolio management as a category. I had to make this visually interesting without having any new screenshots I could share before launch. So a lot of it was diagram-driven, showing the connection between Ledger's wallet layer and Merlin's analytics layer in ways that were accurate but not technically literal.

This is its own design discipline and I've gotten reasonably good at it. But it's time that comes directly out of product design time, and for an integration with this much product complexity, the balance was stressful.

What it means to design for five million people

I've been thinking about this a lot since the announcement went live.

When I started at VALK in late 2019 I was designing for a handful of clients, early institutional users who we knew by name. I knew their feedback directly. I could trace a design decision to a specific person's specific need.

At Spacecode I built apps for larger audiences but the projects were sprints, you shipped, you handed off, you moved to the next thing. You didn't live with the consequences.

Merlin in its pre-Ledger form had a few thousand active users at most. I had a general sense of who they were from user research sessions and from the feedback that came through to our team. I could hold the user in my head.

Five million is a different thing entirely.

I cannot imagine the full range of ways people will use this product, the devices they'll use it on, the contexts they'll use it in, the things they'll find confusing that I never anticipated. The statistical reality is that some percentage of people will hit edge cases I never designed for. Some flows will confuse people in ways that will seem obvious in retrospect.

This is humbling in a specific way that I think every designer should experience at some point. It breaks the comfortable illusion that you can design something perfect if you just think hard enough. You can't. At scale, you can only design something good enough to recover from, clear enough that when something confuses a user, the surrounding context helps them find their way.

I don't know yet how the integration is being received by actual Ledger users. The data will come in over the next weeks and months. I will find out which parts of the flow are working and which aren't. I am prepared to be surprised in both directions.

What I know is that the design work I did here was the most demanding of my career so far. Two audiences, two platforms, two design systems, a compressed timeline, marketing work running parallel throughout. Each one manageable. All of them at once, not so much.

The coffee is always cold by the time I get to it.

If you're working on a similar integration, one product living inside another, the design system negotiation is the thing to start early. The visual compromises are manageable. The interaction pattern conflicts are harder. Get that conversation with the partner's design team on the calendar before anyone writes a line of code.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Moving doesn't fix your design problems

Mon, 15 Aug 2022 00:00:00 GMT

I moved to Los Angeles in March, and for the first week I kept waiting for something to change about my work.

The apartment was new. The light was different, that particular Southern California brightness that hits everything flat and warm. The streets were wide in a way that felt slightly absurd after Istanbul's narrow chaos. My partner and I were still unpacking boxes when I opened Figma for the first time and found, unsurprisingly, the same dashboard screens I'd been redesigning for three weeks. Same components. Same edge cases I'd been putting off. Same Slack message from our frontend engineer asking about a spacing inconsistency I'd documented but not yet resolved.

Location independence is real. The fantasy version of it is not.

What I actually expected

I've been moving between countries since 2019. Saint Petersburg, then Thailand and Bali, back to Russia during the COVID lockdowns, then Turkey for most of 2020 and 2021, Istanbul for the first part of this year. I used to think, and I think many remote workers believe this quietly, even if they don't say it, that a new environment would somehow generate new energy. That the change of scenery would shake something loose creatively. That I would sit at a cafe in Chiang Mai and suddenly understand the design problem I'd been stuck on.

This is not completely wrong. Sometimes a change of environment does shake something loose. But it's much more mechanical than the romantic version. Unfamiliar surroundings force you to pay attention differently, and occasionally that attention bleeds into how you think about a problem. It's temporary. It fades in about three days.

What doesn't change: the actual hard parts of the work.

The same files followed me everywhere

At VALK, I've been designing a platform for institutional private capital markets. The complexity is not the kind that changes based on your mood or your environment. Data-dense tables for investment managers. Deal flow interfaces for asset managers who don't have patience for UI that requires explanation. Compliance reporting screens that have to be precise and readable at the same time. These problems were hard in Istanbul and they're hard in Los Angeles.

The specific issue I remember bringing from Turkey to California was a table component problem, handling variable column configurations across different institutional user types without breaking the layout logic. I'd been circling it for weeks. I thought, half-jokingly, that maybe the new timezone would give me fresh eyes.

It did not. I solved it eventually, but in the same way I solve most hard design problems: by sitting with it long enough that I stopped being clever about it and started being systematic. That happened in my apartment in Silver Lake, looking at the same Figma file, drinking coffee that honestly wasn't as good as what I had in Istanbul.

The location had nothing to do with it.

What actually changed (and not for the better, at first)

Moving from Istanbul to Los Angeles made my async work more async, which was not the plan.

London is where most of the team is. From Istanbul, I was two hours ahead, manageable. I could join early afternoon calls without too much friction, and there was natural overlap in the mornings when engineers would post updates I could respond to before they left for the day.

From Los Angeles, I'm eight hours behind. By the time I sit down to work in the morning, the UK team is finishing their day or already gone. This sounds like a small logistical detail but it compounds. A question I ask at 10am my time gets answered when I'm asleep. Their follow-up arrives while I'm still sleeping. A review cycle that used to take a day and a half now takes three days if the back-and-forth goes more than two exchanges.

I adapted. We adapted. More documentation, more explicit async communication, more decisions made in writing rather than in calls. In some ways this is better, I'm more deliberate about what I communicate and how. But I'd be lying if I said the timezone gap didn't cost us something in the first few months. There were moments where I missed something obvious because I wasn't in the same rhythm as the team.

This is the kind of problem that the "work from anywhere" discourse never really accounts for. Yes, you can work from anywhere. But your teammates are somewhere specific, and the further you drift from their timezone, the more you have to build systems to compensate.

What did change, genuinely

Living in the US changed how I understand American financial users.

VALK serves institutions, mostly European and increasingly American. When I was designing from Russia or Turkey, I had theoretical understanding of how American financial professionals operate. I knew the products they use, the conventions they expect. But there's something about actually being in the country, seeing how people talk about money here, overhearing conversations, noticing what financial apps are being advertised on the subway, what interfaces are common in everyday banking, that adds texture to that understanding.

It's not that I couldn't design for this user before. I could. But now I have more reference points that are intuitive rather than researched. The difference between knowing something from documentation and knowing it from living inside it.

I also started paying closer attention to American design communities. More meetups here, more conferences, more public discourse about design at companies I actually recognize. I've attended exactly one meetup in five months, because I'm deeply introverted and networking in person still feels exhausting. But I've been reading more, following more people working at American fintech companies, understanding the professional ecosystem better.

Even if I never go to another event, the ambient exposure matters. It's like background radiation for your professional thinking.

Location changes mood. Mood changes work. But not as much as you think.

I want to be precise about this because I think it's easy to overstate.

There's a version of this reflection where I say every place I lived made me a better designer. That's not really true. What changed was my mood, my general sense of possibility, my stress levels. These things do affect work, a stressed, unhappy designer produces worse work than a content, settled one. But that's a floor condition, not a creative lever.

Thailand was beautiful and I was happy there. I also did some of the worst design work of my time at VALK during that period, because I was distracted and the team was still figuring out what VALK was supposed to be, and I didn't have enough context about the domain to make good decisions. The good mood didn't compensate for the missing knowledge.

Istanbul in 2021-2022 was where I did some of my better work. Partly because I was more settled, had been at VALK longer, understood the product and users more deeply. Also partly because Istanbul is a city that makes you feel like a person, good food, good coffee, real neighborhoods. My partner and I were genuinely happy there. That helped. But I was also just more experienced. The city didn't give me the experience.

Bali during COVID quarantine was maybe the strangest period. We were stuck, genuinely uncertain about what was happening, and I remember doing extremely thorough, detailed design work just to have something controllable in an uncontrollable situation. That wasn't the location inspiring me. That was anxiety channeling itself productively.

The nomad myth and what it costs

There's a particular kind of person who is very loud about location-independent work on the internet. They emphasize the freedom, the novelty, the flexibility. They're not wrong that these things exist. But they underweight what constant movement costs.

You can't build habits easily when you're moving. The gym you found in month one is not there in month two. The coffee shop with the good wifi and the table by the window, you figured that out, and now you're in a different city and have to figure it out again. Small things individually. Accumulated, they add friction to just getting started each day.

More seriously: you can't go deep on work when part of your brain is managing logistics. Finding accommodation, navigating healthcare, figuring out banking, dealing with visas. Even when you're good at this, it's cognitive load that doesn't go to design thinking.

I spent time in nine or ten different places over three years. I don't regret it, my partner and I were doing something important together, seeing the world, building a life that felt like ours rather than default. But I was also slower at work during moving periods than during settled ones. I would not recommend constant movement to someone who wants to do their best design work.

The best work I've done was in one place for a long time

I've been in Los Angeles for five months and I can already feel the difference. I have a desk. The desk is in the same room every morning. I know where to get good coffee within walking distance. My partner and I have routines.

These things sound trivial, but they free up the part of my brain that used to manage orientation.

The design work I've done this year, more complex component architecture for the VALK platform, working through the data visualization problems for portfolio reporting, thinking through how the product should evolve; has been more sustained than in previous years. I'm not moving fast, necessarily. I'm thinking more carefully. I go back to problems more often. I'm less likely to ship something I know is not quite right just because I need to close the file and go figure out where to eat.

Some of this is just that I've been at VALK longer and understand the domain better. But some of it is genuinely the stability.

What LA gave me that I didn't expect

The city is enormous and car-dependent in a way that's genuinely difficult to adapt to after years of cities where you walk everywhere. I don't love that. But the scale of it, oddly, has been good for my sense of proportion.

When everything is big, you stop expecting small decisions to be precious. The design industry discourse I'm now more exposed to operates at different scale, companies with huge user bases, design teams with dozens of people, problems that involve millions of users. I'm still at a company where I'm the only designer. But being adjacent to that scale, reading about it, occasionally talking to people who work in that context, has recalibrated how I think about our own product decisions. Some of our problems are genuinely hard. Some of them are small and I was treating them like they were hard.

That's a useful recalibration.

If you're a remote designer thinking that moving to a new city will solve your design problems: it won't. The files come with you. The hard conversations come with you. The edge cases in your component library come with you.

But if you're exhausted, genuinely exhausted, from moving too much, and you find somewhere that feels like it might be home for a while, settle. Give it a year. See what you can actually do when you're not managing logistics in the background.

I'm still figuring out LA. But the Figma work is going better, and I don't think that's a coincidence.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Designing financial UI for 15+ countries

Mon, 30 May 2022 00:00:00 GMT

The first thing I noticed when I moved to Los Angeles was how American financial interfaces feel. I had opened a new bank account within two weeks of arriving, and the app was clean, friendly, almost cheerful about money. Big numbers, rounded corners, green everywhere. A far cry from the dense, serious layouts I had spent three years designing for institutional investors across Europe and the Middle East.

That contrast stuck with me. Not as criticism, just as reminder that the way we design financial products is deeply shaped by where we are. And when your product has to work across fifteen countries simultaneously, that becomes real engineering problem. Not philosophical one.

VALK served institutions across the UK, continental Europe, the Middle East, North America, and parts of Latin America. Seventy-plus financial institutions — investment banks, hedge funds, and asset managers —, each operating under different regulators, using different conventions, carrying different cultural expectations about what a "serious" financial interface looks like. For most of my time there, I was the only designer. So I had to figure out how to handle all of this without creating fifteen separate products.

Localization is not translation

This is the thing people get wrong first. They think localization means you take your strings, send them to translator, and the job is done. That's barely twenty percent of the work.

Real localization is about information hierarchy. What data a user expects to see first. How they read a table. Whether they trust a minimalist layout or find it suspicious. Languages change the shape of text, German financial terms are long, Arabic flows right to left, Russian uses completely different number grouping conventions. Each of these requires actual design decisions, not just string swaps.

When I first approached this problem in 2020, I made the mistake of thinking about localization as a final step, something you handle after the real design is done. By 2022, after working with clients from Riyadh, Zurich, São Paulo, and London in the same quarter, I understood that localization has to be structural decision you make at the component level.

The small things that are actually huge problems

Let me be specific, because vague advice about "cultural sensitivity" is not useful.

Date formats. This one caused an actual support incident. We had a data room where documents showed a signing date. In the UK, 06/07/2021 means the seventh of June. In the US, it means the sixth of July. In some of our middleware logging, we were getting ISO 8601 (YYYY-MM-DD), what the backend engineers defaulted to. Three different formats, one field, one very confused client in New York looking at what appeared to be backdated document.

The solution sounds simple: always display dates with the month written out, or always use the locale-appropriate format explicitly. But that requires every date component in your design system to accept a locale parameter, which means you have to design for that from the start. If you bolt it on later, you end up with patchwork of inconsistent date displays across different parts of the product.

Currency formatting. In the US: $1,000,000.00. In most of continental Europe: 1.000.000,00 €. In Russia, when I was still working from there: 1 000 000,00 ₽ with space as the thousands separator. Show European institutional investor a large number formatted the American way and they will pause. Small cognitive friction, but in product built around trust, you really cannot afford it.

I built currency display as dedicated component in Figma, with variants for locale. Not because Figma renders these differently, it doesn't, but because it forced every screen that showed a financial number to explicitly declare its formatting intent. When the developer implements it, the decision is already made. No ambiguity in the handoff.

Number density is harder to quantify but it's real. When we were working with clients from East Asian financial institutions, the feedback I got, through the CEO relaying conversations, was that the dashboards felt "light." Not enough information visible at once. These were users accustomed to dense terminal-style interfaces. Meanwhile, some of our Nordic clients felt the same dashboards were too busy. They wanted one key number and then progressive disclosure to get deeper.

There is no layout that serves both of these users equally. What you can do is design flexible information architecture, modules that can be shown or hidden, table columns that can be configured, and then set sensible regional defaults.

RTL, the one that changes everything

Arabic is the case that forces you to actually think about your layout assumptions.

We had client in the Middle East, and even though their internal interface language was English, we were anticipating growth in markets where Arabic support would matter. I started doing the mirroring exercise as thought experiment first. Take a screen, flip everything horizontally. Navigation goes from left to right. Tables align from right to left. Icons that imply direction, arrows, chevrons, progress indicators, all need to be reconsidered.

The first time I mirrored one of our deal room layouts, I found about eight places where I had hardcoded directional assumptions that had nothing to do with text. A document progress bar that animated left-to-right. Sidebar visually anchored to the left. Tab navigation that opened to the right. None of these were text elements. All of them needed adjustment.

RTL support is not just a CSS direction: rtl property. It requires designing bidirectional-aware components from the beginning, or going back and rebuilding. I have seen teams defer this until they have real paying client who needs it, then spend three months untangling assumptions that were baked in from day one.

Regulatory differences that affect the actual UI

This is the one that surprised me most when I first started working in fintech. I came from agency background where the client tells you what to show, and you show it. In regulated financial products, what you are allowed to show, and what you are required to show, differs by jurisdiction.

In the UK, under FCA regulations, certain risk disclosures need to be visible at specific points in a transaction flow. The exact wording, placement, and visibility requirements are specified. You cannot tuck disclaimer in a footer and call it done.

Switzerland has different norms around what performance data can be displayed before a user has been properly classified as qualified investor. Show the wrong number to the wrong user type, and it is compliance issue, not just a design decision.

What this meant in practice: some UI elements existed in some regional configurations and were literally absent in others. Not hidden behind a click, not visually suppressed, structurally absent for certain jurisdictions. This pushed me toward configuration-driven design approach. Components needed to be built as if they could be switched on or off per region, per user type, per regulatory requirement.

Designing for this is humbling. You realize the "clean, simple" interface you want to build is actually a series of conditional states, each driven by rules that live outside of your Figma file.

Color and trust

Red means "stop" or "bad" in most Western financial interfaces. Portfolio is down, you show red. Risk warning, red. Error state, red.

In some East Asian financial cultures, red is traditionally associated with luck and positive outcomes. It's the color of profit in some markets, Hong Kong being the most-cited example, where red on a stock chart means the price went up.

I am not saying you should redesign your entire color system for every regional market. But it is worth knowing when you are making cultural assumption versus universal one. If you are building for single market, your color conventions can be local. If you are building for fifteen, you should at least be intentional about which conventions you are defaulting to and why.

We kept green/red as the primary gain/loss indicators because our primary market was UK and European institutions. But I flagged it as known limitation in the design documentation, noting that any future expansion into East Asian retail markets would need review of this system.

How I organized Figma to not lose my mind

The practical question: how do you manage this in real design file without duplicating everything six times?

My approach was design tokens plus component configuration, not separate files per region.

In Figma, I maintained core component library that was region-agnostic at the structural level. Number display components accepted format parameters. Date components had locale variants in their properties. Direction-sensitive icons had mirrored versions as separate component variants, selectable with one click. Then I had separate "regional configuration" page in the file, not a real design deliverable, more of a reference document. It mapped out which component variants were active in which configurations: UK flow, EU flow, MENA flow, US flow. Mostly for me, and for whoever was implementing. It made the conditional logic visible without needing to maintain fifteen separate design files.

The danger of managing this in Figma is that you can accidentally create drift, the UK version gets a change that never propagates to the EU version. My solution was to treat the component library as source of truth for structure, and the regional configuration as source of truth for what gets used where. Any structural change to a component would automatically affect all regional variants because they all used the same component. Regional differences were expressed only through configuration choices, not through structural changes.

Easier to say than to maintain, honestly. When you are moving fast and there is only one of you, shortcuts happen. But the principle held.

What moving countries taught me about design

I have been thinking about this more since arriving in Los Angeles.

I grew up in Russia, worked from Saint Petersburg, spent time in Phuket, few months in Bali during the early pandemic, then Alanya and Istanbul. Each place had its own relationship to money, to what financial interfaces felt like, what felt trustworthy, what felt suspicious.

In Turkey, during the inflation period in 2021, the relationship to currency was different. Numbers moved fast. People were accustomed to seeing prices change and tracking exchange rates closely. Dashboard that showed only today's value without historical context would have felt incomplete.

In the US, I notice that financial products are built around optimism and simplicity. The UI encourages you to not look too closely, to trust the system, to feel good about investing. European and especially UK institutional products feel different, more serious, more disclosure-heavy, more skeptical of the user.

Neither is wrong. They reflect real cultural differences in how people relate to financial institutions and financial risk. But understanding those differences, not as tourist, but as someone who has actually lived in different places and opened bank accounts and used local financial apps, has been useful in my design work in ways that reading about cultural UX differences in articles never fully was.

The move to LA coincided with me starting to think more carefully about US market as design context in its own right. Americans are not Europeans who happen to speak English. Their expectations for financial interfaces, their trust patterns, their tolerance for risk and disclosure, these are different. And I am only starting to understand this from the inside.

There is probably no final solution to designing for fifteen countries. Scope of difference is too large to fully systematize. What you can do is build systems that are honest about the variations, that encode the regional decisions explicitly rather than pretending there is universal interface that works everywhere.

The day you stop treating localization as afterthought and start treating it as structural design requirement is the day your international product starts to actually work internationally. For me, that realization came late. But it came.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Designing for users you cannot talk to

Mon, 14 Feb 2022 00:00:00 GMT

Two years ago, I wrote a user flow for a feature that I was genuinely proud of. Clean logic, thoughtful edge cases, good empty states. We shipped it. A few months later, I asked if anyone had used it. The answer from our account manager was something like: "I think one client mentioned it in passing. They said it was fine."

Fine.

That was the most feedback I got on three weeks of work. And honestly, that's pretty typical for what I do.

I've been the sole designer at VALK for over three years now. The product is used by portfolio managers, compliance officers, and traders at institutional financial firms, hedge funds, investment banks, asset managers across fifteen-plus countries. These are real people sitting at real desks making real decisions with the interfaces I design. And with very rare exceptions, I have never spoken to a single one of them.

This is enterprise B2B design. The feedback loop doesn't just close slowly, sometimes it doesn't close at all.

The access problem

In consumer product design, the research process is something you can actually plan around. User interviews, usability testing, surveys, A/B tests, session recordings. You have direct access to the people using your product and many ways to observe their behavior.

Enterprise B2B breaks this completely.

When your users are bankers and fund managers at regulated financial institutions, reaching them is not a matter of posting a recruitment survey in a Slack community. There are layers of intermediaries: account managers, legal teams, compliance officers who are deeply skeptical of anything that involves external parties observing their workflows. The relationship between VALK and our clients is formal, often governed by contracts that make any kind of research request a complicated conversation.

And even when access is technically possible, the users themselves are not interested in talking to a designer. They are busy professionals. Their time costs money in a very literal sense. Sitting on a call to walk through their pain points with a 25-year-old designer in Istanbul is not how they want to spend an afternoon.

So you adapt. You find proxy methods. You build a different kind of research practice from whatever scraps are available.

What I actually use instead of user research

Support tickets are underrated. When I can get access to them, usually filtered through our CEO or the account managers, they are the closest thing I have to unfiltered user feedback. Not because they tell me what users want, but because they tell me where users are confused or stuck. A user filing a ticket is a user who already failed to figure something out on their own. That's a signal. I started keeping a running document of recurring ticket themes, because patterns in support requests map very directly to design failures.

Feature requests are a different kind of signal. They tell you what users are trying to do, not necessarily what they're asking for. When several institutional clients asked for a specific data export format, the surface request was about file types. The underlying need was about fitting VALK's output into their existing internal reporting workflows. I only got there by reading the requests carefully and asking follow-up questions through the account managers, and that distinction changed how we approached the problem entirely. We didn't just add export formats. We redesigned the data structure to be more flexible upstream.

Then there is over-the-shoulder observation during demos. This is probably the most valuable thing I have access to, and it happens accidentally. When the CEO or an account manager demos the product to a prospective client over a screen share call, sometimes I'm invited to watch. Not to present, just to observe. And in those moments, I watch how the person on the other end reacts. Where they lean forward. Where they look confused. What questions they ask. I've redesigned small but meaningful things based purely on watching someone hesitate over a UI element during a twenty-minute sales demo.

The CEO as a proxy for the user

In the absence of direct user access, the CEO became my most important research partner. I didn't fully understand this when I first started at VALK, it became clearer over time.

He comes from a finance background. He understands the domain in a way that most designers, myself included, have to actively work to develop. When he looks at a feature and says "a portfolio manager would never think about it this way," that's not just an opinion. That's accumulated domain knowledge I can't get anywhere else.

I had to learn how to use this properly. Early on, I would show him designs and ask "does this look good?"; which was the wrong question entirely. Later I learned to ask things like "when someone is reviewing deal documentation, what's the first thing they're checking?" or "what would make a compliance officer trust this interface more?" Framing questions around user behavior and mental models, not visual preferences, produced much more useful answers.

It's not perfect. A CEO's perspective has its own biases, he naturally gravitates toward power users and edge cases because those are the clients he talks to most. But it's a real signal, and it became the closest thing I had to user research for a long time.

Heuristic evaluation became my foundation

When you don't have users to test with, you fall back on principles. Nielsen's heuristics, Fitts's Law, cognitive load theory, established patterns for financial interfaces, these stopped being academic references and became my primary evaluation tools.

Before shipping anything significant, I do a structured self-audit. I go through the design and force myself to answer specific questions: Where is the user's attention going first? Is there a clear visual hierarchy? If something goes wrong, does the interface communicate it clearly and suggest a recovery path? Is there anything that looks interactive but isn't, or vice versa? Are we exposing complexity that the user doesn't need at this stage?

This sounds obvious. Every designer learns these things. But there's a difference between knowing heuristics and actually building a disciplined habit of applying them, especially when you're working fast and there's no one sitting next to you to catch your blind spots.

The financial domain adds extra dimensions to this. Data density is a real concern. Portfolio managers and traders are used to dense interfaces, Bloomberg terminal-style, and there's a balance between giving them the information they want visible and overwhelming a less experienced user. Error handling matters more when a mistake could affect a transaction. Trust signals, visual consistency, precision in numbers and dates, clear audit trails, these are not nice-to-haves, they're baseline requirements.

I've spent a lot of time thinking about what "trust" looks like in a financial interface. It's partly visual, clean, professional, no unnecessary decoration, but it's more about behavioral consistency. If the interface behaves predictably every time, users build trust in it even without consciously thinking about it. Surprise is the enemy of trust in enterprise software.

Competitive analysis as a form of research

VALK operates in a space with a few direct competitors, companies like Securitize and Tokeny working on similar infrastructure for private capital markets. I've spent real time studying their interfaces, not to copy them, but to understand the design decisions they've made and why.

Competitive analysis is not a substitute for user research, but it's informative in a specific way: these products are trying to solve similar problems for similar users, and how they've chosen to solve them is a signal. When two competitors make the same structural decision, how they handle investor onboarding, how they present cap table data, it suggests that decision was probably informed by user feedback somewhere in their process. When they diverge dramatically, it's worth understanding what's driving the difference.

I'm also looking for patterns in what these products don't do well. Gaps that exist across multiple competitors usually exist because the problem is genuinely hard, and that's worth understanding before you assume you can solve it easily.

When I actually got to talk to a user

It happened maybe four or five times over three years. Every single time, it was illuminating in ways I did not expect.

The most memorable was a call with someone who managed fund operations at a mid-sized asset manager. We had added a reporting view that I was proud of, clean layout, good data hierarchy, exportable. She mentioned almost immediately that she never used it. I asked why. She said her team had a specific internal format they reported to their LPs in, and VALK's view didn't match it, so they were exporting raw data and reformatting it themselves in Excel every time.

I had designed something that looked great and solved what I thought the problem was. She had a completely different problem. And she had adapted her workflow around my design without ever telling anyone it was costing her team time every month.

That conversation changed a feature direction. But more than that, it reminded me that I am almost certainly wrong about something right now, in something I shipped three months ago, and I won't know about it for a long time.

This is the fundamental discomfort of enterprise B2B design. You carry assumptions you cannot fully validate, and you have to make peace with that while still trying to get closer to correct.

The assumption trap

Every design decision in a context like this is built on a stack of assumptions. Assumptions about what users are trying to do, about their mental models, about what they find confusing. Without research, you cannot fully validate those assumptions. You can only minimize the most dangerous ones.

What I've learned to do is make my assumptions explicit. When I'm designing something, I write down the assumptions underneath the decisions: "This design assumes that the primary user reviewing deal documents is doing so before a committee meeting, not during it. This design assumes that the user is familiar with basic cap table concepts. This design assumes that users will use this feature repeatedly, not once." Writing them down forces clarity. It also means that when something doesn't work, you can sometimes trace it back to a specific assumption that was wrong.

It doesn't eliminate the problem. But it makes the problem more legible.

Three years, four countries, same product

I'm writing this in Istanbul, in the last few weeks before my partner Anna and I move to Los Angeles. Strange moment to reflect, three years at the same product, from Saint Petersburg to Phuket to Bali to Turkey, always working on the same interface for users I mostly couldn't talk to.

Remote design in a B2B context is a particular kind of isolation. You're away from the team, away from the users, away from the industry events where you might run into people who use products like yours. You're designing in a room with your own assumptions for company.

I've gotten better at enterprise UX precisely because I had to develop more rigorous internal practices, heuristic evaluation, structured competitive analysis, extracting signal from indirect sources, building the discipline to make assumptions explicit. These things compensated, partially, for the access I didn't have.

But I'm also aware that the best version of this work would involve more direct user contact. Even one research session per quarter would change what I'm able to do. It's something I want to push for more actively as we keep growing.

The assumption that I can't talk to users is itself an assumption worth testing more often.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Why your design system probably does not work

Mon, 08 Nov 2021 00:00:00 GMT

There is a specific kind of frustration that comes from looking at your own work and realizing it does not function the way you intended. Not broken, just not working. Two years ago I built a design system for VALK from the beginning, components, tokens, documentation, spacing rules, color semantics, typography scale. Last month I went through the actual product screens in production and compared them against what lives in Figma. They do not match as much as I thought they would.

I am writing this from a rented place in Krasnaya Polyana, small mountain town in southern Russia near Sochi. It is quiet here, good for thinking. I came to clear my head after a long stretch of work and instead I keep opening Figma and staring at the gap between what the system says and what ships.

This article is not about how to build design system. There are many good resources for that. This is about what happens after you build it, specifically when you are the only designer on the team.

Two years of systematic thinking, delivered inconsistently

When I joined VALK in late 2019, there was no design system. No design anything, really. I started from scratch, which sounds exciting and in some ways it was. I could make decisions without inheriting someone else's bad choices.

By mid-2020 I had working component library in Figma. By end of 2020 it was well-documented. By mid-2021 it covered almost every UI pattern we needed, data tables, form elements, modal variants, notification states, empty states, financial charts styling, investor card layouts. I was proud of it.

But over time something strange happened. The system was comprehensive and the product was inconsistent. Both things were true at the same time.

Some buttons in production have different border-radius than the design spec. Some form labels use slightly different gray than what I defined. Spacing between elements in certain sections is close but not exact, 14px where it should be 16px. Nothing catastrophic. But enough that when you look carefully, the product does not feel as precise as it should.

The code and the components diverged. Gradually, quietly, without any single moment of failure.

The documentation nobody reads

I wrote good documentation. I know this because I spent real time on it, explaining not just what each component is, but why it works a certain way. Why the primary button has that specific padding. Why we use that particular blue and not the one that looks similar. The reasoning behind decisions.

Our frontend engineer has not read most of it. I say this not as criticism, he is good at his job and he works fast. But the documentation lives in Figma and when you are writing code, you are not in Figma. You are in your editor, you are in the codebase, you are looking at existing components that are already there. That is your reference, not some nested Figma page with annotations.

I realized this late.

I thought documentation was a solution. It is not a solution, it is evidence that you thought carefully. That is different. The people who read design documentation are other designers. Developers read code. This sounds obvious when you write it out, but when I was building the system I was thinking like a designer, not like a developer.

The solo designer paradox

When you are the only designer, you build the system and you also break the system. You are the only person who could enforce the rules; and you are also the person most likely to ignore them when you are moving fast.

There were times when I was designing new feature quickly and I made a component that did not properly follow the system. Maybe I created new variant instead of using existing one. Maybe I used color in way that was not quite right for the context. In larger team, another designer might catch this in review. At VALK, there is only me. So the mistake goes into the file, and sometimes it goes into production because my Figma frame became the reference.

At Spacecode, the agency in Moscow where I worked before this, there was dedicated person whose primary job was maintaining the design system. She was not designing product features, she was reviewing components, keeping the library clean, doing audits. That structure works. When the system has owner who is separate from the people building with it, the system stays healthier.

At VALK I am the owner and the primary user. The conflict of interest is permanent.

Figma components vs. coded components

I have a Figma component. It has variants, auto layout, handles different states, default, hover, focus, error, disabled. It looks correct in every combination I tested.

The developer implements this component in React. The implementation is based on looking at the Figma component and understanding its behavior. But interpretation is involved. And every time I update the Figma component, the coded component does not automatically update. Someone has to notice that I changed something and then decide if the code needs to change too.

Nobody has that job at VALK.

I do not always announce small design system changes. The developer does not always check the Figma library after every update. So they drift. An extra state I added that was never coded. A spacing adjustment I made when refining the grid. A new color semantic I introduced. Each seems minor. Together over two years they create real gap between the design system and the actual product.

I have seen solutions to this, design tokens that feed directly into code, tools that try to sync Figma variables with CSS variables, processes where every component change triggers development task. These solutions require organizational buy-in and time investment from developers. In small startup moving fast, that investment is hard to justify. The product keeps moving and the system maintenance falls behind.

Naming conventions that made sense to me

I named things the way designer thinks about them. Colors like color-primary-action, color-feedback-success, color-text-secondary. Spacing tokens like space-component-padding-m, space-layout-section. These names describe the purpose, not the value, which is the correct approach according to everything I read about design tokens.

But when the developer looks at this and then looks at what actually exists in the codebase, which predates some of these naming decisions, the mapping is not always clear. The coded variables have different names because they were named earlier, before I standardized my system. Now there are two naming conventions existing in parallel. The design says one thing, the code says something different, they refer to same value but you have to already know this.

I should have involved the frontend engineer in creating the naming conventions from the beginning. He is the one who has to live inside the code. If the names feel foreign to him, he will name things his own way; which is exactly what happened.

The political reality of design systems

I avoided thinking about this for a long time, but the real problem with our design system is not technical. It is political.

A design system is a set of rules. Rules only have power if there is some enforcement mechanism. In design team of eight people at larger company, enforcement comes from peer review, from design leadership, from cultural expectation that you use the system. When you deviate, someone notices.

In startup with one designer and one frontend engineer, there is no enforcement mechanism except my own attention. And my attention is spread across product design, pitch decks, social media graphics, investor materials, and many other things that have nothing to do with maintaining component consistency.

So when the developer needs to ship feature quickly and the right component does not quite cover the case, he improvises. And I am often not looking carefully enough to catch it. The improvisation becomes the precedent. Other similar features get built the same way because now that is what exists in the code.

The system erodes not through anyone's failure, just through natural pressure of shipping product at startup pace with very small team.

What I would do differently

If I could start over, the first thing I would do is sit down with the developer before writing single component.

Not to show him design system and explain it. To ask him how he builds things. What naming makes sense to him. What patterns he reaches for naturally. What the existing codebase already has that I should preserve rather than replace. Then I would build the system around those answers.

Designers build design systems for designers. The artifacts are Figma files, component pages, usage guidelines. But the actual users of the system, the people whose work is most directly constrained by whether they follow it, are the developers. They are the ones translating it into real product.

Building design system without deeply understanding how your developers work is like designing product without understanding how your users work. You make reasonable assumptions and then you are surprised when behavior does not match expectations.

I also think I built too much too fast. Smaller, more stable system would have been better than comprehensive one that overreached. When the system covers everything, it is harder to maintain everything. Some of our components are used constantly and are very solid. Others were built speculatively for cases that barely exist in the product. Those are the ones most out of sync.

What is actually working

The core components, button variants, form system, data table, modal pattern, color palette, are stable and mostly consistent in production. When I look at main flows of the product, they feel coherent. Users navigating the core journeys have consistent experience.

The system succeeded where I invested most consistently and where the developer and I had most direct conversations about implementation. The problems are at the edges, new features, edge cases, rarely-used components.

That tells me the mechanism for working design system is not documentation. It is conversation. Ongoing, regular conversation between designer and developer about specific components and how they translate to code. Not one-time handoff. Not Figma library and hope that developer finds the right components.

Where things stand now

I think the system needs partial reset. Not full rebuild, that would be wasteful. But an audit where I identify components that are actually in use and well-implemented, and let go of the parts that exist in Figma but nowhere else.

I also want to try exporting design tokens in format the developer can actually use directly, something we agree on together rather than something I designed and handed over. Few hours of coordination, but it might close some of that drift.

The deeper lesson I am sitting with here in the mountains is that design systems are not deliverables. You do not finish them and move on. They are infrastructure, and infrastructure requires ongoing maintenance and people who are responsible for that maintenance. In small company with one designer, that responsibility cannot be distributed, which means it will always be underpowered compared to what the system actually needs.

I am not sure there is perfect solution to this when you are solo. But understanding the actual problem, it is organizational, not technical, at least helps you stop looking in the wrong places for the fix.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Designing DeFi for people who hate DeFi

Sun, 22 Aug 2021 00:00:00 GMT

There is a specific moment I keep thinking about. I was on a call with one of our institutional clients, a portfolio manager at a mid-sized hedge fund, and he was sharing his screen to show me how he tracked his DeFi positions. He had a spreadsheet. Rows of wallet addresses, transaction hashes he copied manually from Etherscan, prices pulled from CoinGecko every morning. This man managed hundreds of millions in traditional assets using Bloomberg Terminal. But for his growing DeFi allocation, he was doing data entry by hand.

That conversation stayed with me for weeks. It became the clearest brief I could have had for Merlin.

What Merlin was supposed to solve

When VALK decided to build Merlin as separate product in late 2021, the idea was simple on paper: a portfolio tracker and analytics dashboard for DeFi positions, targeted at institutional users. Aggregate data from protocols like Aave, Compound, and Maker, show performance in format that makes sense to finance professionals, help them understand what their on-chain capital is actually doing.

Simple on paper. Not simple in practice.

The deeper I went into research, the more I understood that the problem wasn't just missing software. It was a trust and literacy gap between two worlds that have very different assumptions about what "good interface" looks like. DeFi dashboards are mostly built by crypto natives, for crypto natives. They assume you know what a liquidity pool is, that you are comfortable seeing your balance in ETH, that protocol names like Compound or Maker need no explanation. The interfaces reflect that, colorful, jargon-heavy, sometimes deliberately obscure in way that feels like badge of insider knowledge.

Traditional finance professionals, the people Merlin was aimed at, are not intimidated by complexity. They work with complex data every day. But they have completely different vocabulary, different trust signals, and much lower tolerance for ambiguity in tool that touches their capital.

The trust problem is a design problem

This took me a while to articulate clearly: institutional users do not trust interfaces that look "too crypto."

I don't mean they dislike the aesthetic in superficial way. The visual language of most DeFi products carries real signal for these users. Gradients, animated numbers, tokens displayed as colorful icons, purple everything, these are not neutral choices. For someone who has spent career looking at Bloomberg Terminal, Reuters Eikon, or even a well-built internal risk dashboard, these visual patterns communicate "retail," "speculative," "not serious."

And in finance, if the tool doesn't look serious, you don't trust the numbers. If you don't trust the numbers, you don't use the tool.

So one of the earliest decisions I made for Merlin was to completely reject the aesthetic vocabulary of DeFi. Not to be boring, but to deliberately speak the visual language that institutional users already associate with reliability. Dense tables. Muted color palette. Data-first layout. Typography that feels closer to financial reporting than to web3 landing pages.

I kept thinking about Bloomberg Terminal as reference, not because I wanted to copy it, but because it represents something important: a tool designed so purely around the professional user's needs that aesthetics became secondary. The people who use Bloomberg don't care if it looks modern. They care if the data is right, if it loads fast, if they can find what they need without thinking.

Merlin was never going to be Bloomberg. We are startup, not forty-year institution. But that philosophy shaped every decision.

Denominating the world in USD, not ETH

This sounds small. It is not small.

When traditional finance professional looks at portfolio performance, they think in their base currency. For most of our institutional users, that is USD. They don't want to know their yield is 0.003 ETH. They want to know it is $8.40, or $12.50, whatever the converted value is at current price.

Most DeFi dashboards show values in native tokens by default, sometimes with small USD equivalent in gray text underneath. That hierarchy made sense for crypto natives. It makes no sense for someone whose entire performance reporting framework is in fiat.

So in Merlin, USD was the primary display. Always. Native token amounts were secondary, available but not dominant. P&L was calculated and shown in USD. Yield was shown in USD. Every position across every protocol was normalized to one currency.

The implementation was harder than it sounds. We needed reliable price feeds, we needed to handle latency between on-chain data and price data, we needed to decide what to do at midnight UTC when daily P&L resets. All of this required very close work with the dev team, Anton and Alex in particular were deeply involved in making sure the data pipeline was solid before I could design any of the presentation layer.

This brings up something I thought about a lot during Merlin: in most products, if number is slightly wrong, the user is confused. In finance, if number is slightly wrong, someone calls their lawyer. The pressure on data accuracy was different from anything I had designed before, and it changed how I approached decisions. I became very conservative about showing anything I wasn't sure the backend could reliably support.

Explaining impermanent loss without using that phrase

Impermanent loss is one of the most important concepts in DeFi for liquidity providers. It is also one of the worst-named concepts in any financial domain I have ever encountered.

For someone coming from traditional finance, "impermanent loss" sounds like contradiction. Losses are permanent. If you lose money, you lost money. The "impermanent" qualifier sounds like hand-waving, like someone invented word to make a risk sound less scary.

The reality is more nuanced, it describes the opportunity cost of providing liquidity versus simply holding the assets, but the naming creates immediate communication barrier. Institutional users I spoke to during research would visibly disengage when I used the phrase, like they detected a marketing trick.

So I stopped using it in the interface entirely.

Instead, Merlin showed "liquidity position P&L vs. holding equivalent assets." Longer phrase, but one that lands correctly for finance professional. They understand P&L. They understand comparing a strategy against a benchmark. What you earned from providing liquidity versus what you would have earned just holding those same tokens, that framing is immediately legible in traditional finance terms.

The underlying math is the same. The communication is completely different.

This was one of the cases where learning the domain deeply paid off. I had spent weeks reading about how liquidity pools actually work, how AMM mechanics create this phenomenon, why it matters differently at different price ratios. I had to understand it myself before I could figure out how to explain it to someone else without reaching for industry jargon.

Aggregating three protocols into one view

When institutional user has positions across Aave, Compound, and Maker, they don't want to check three dashboards. They don't want to cross-reference their own spreadsheet. They want one view that tells them: this is your total deployed capital, this is your current yield across all positions, this is how it compares to last week.

The aggregation work was the core of Merlin's value, and also the most technically difficult thing we did. Each protocol has different data structures, different event schemas, different ways of calculating interest accrual. Normalizing this into coherent single view required the dev team to do significant work before I even touched design.

From my side, the challenge was creating hierarchy that made sense across different protocol types. Aave and Compound are lending protocols, the mental model is: I deposited assets, I am earning yield, I may have borrowed against my collateral. Maker is more complex, a collateralized debt position with different risk parameters.

I created what I called internally a "protocol-agnostic position card." Every position, regardless of where it lived, showed the same structure: asset, current value in USD, yield earned since entry, current APY, and a health metric if there was any liquidation risk involved. Protocol-specific details were available on expansion, but the top level was consistent.

This sounds obvious. But there were many debates about it. The argument against was that we were hiding protocol-specific nuance that sophisticated users needed. My argument was that sophisticated users can expand the detail, the default view should answer the most common question first, which is "how is my portfolio doing overall?"

Eventually we found the right balance. The collapsed view was clean and comparative, the expanded view was dense with data that analysts actually needed.

What I was designing with, and against

I spent a lot of time looking at competitive products during Merlin's design phase. Zapper, DeBank, Zerion, the main DeFi portfolio trackers, and honestly well-designed for their audience. Zapper in particular has very good UX for the crypto-native user who wants to quickly see what's happening with their positions.

But all of them were built around assumptions that don't transfer to institutional users. The color palettes were saturated. The hierarchy put token balances ahead of USD values. Wallet addresses were displayed prominently rather than abstracted. The overall feel was consumer, not professional.

Looking at these made me more confident about going in the opposite direction.

The closest reference I found in traditional finance wasn't a DeFi product at all, it was how some prime brokerage portals display multi-asset portfolio views. That was more useful to me than anything in web3.

Learning while designing

Something I want to be honest about: when Merlin started, I was learning DeFi myself.

I understood the conceptual layer, VALK's tokenization work meant I had absorbed a lot about blockchain, smart contracts, asset representation. But the specific mechanics of DeFi protocols, liquidity pools, yield farming, the actual market dynamics, I was figuring this out in real time.

This created an interesting dynamic. I was designing product for traditional finance professionals who were also learning DeFi. In strange way, my position as intermediate learner, someone who understood finance logic but was still mapping it to DeFi mechanics, was actually useful. I could feel exactly where the communication broke down, where terminology stopped making sense, where you needed analogy to a traditional concept to make the on-chain version land.

I had to read. A lot. Protocol documentation, DeFi research posts, old finance textbooks that VALK's CEO recommended. I kept a document where I translated DeFi concepts into traditional finance equivalents, which became kind of internal guide for copy and labeling decisions in Merlin.

There is something genuinely exciting about designing a product where the category itself is new enough that most conventions have not been established yet. At Spacecode, designing the fiftieth banking app, you were mostly making decisions within well-worn space. With Merlin, there was no established pattern for "DeFi portfolio tracker for institutional users." We were making the patterns.

That pressure is uncomfortable. It is also the best kind of design work.

Where we landed

The version of Merlin we launched leaned conservative in almost every visual decision. Dark data tables, palette that avoided anything reading as "crypto colorful," clear USD-first denomination, position cards with consistent structure regardless of protocol.

The response from institutional users was better than I expected. The piece of feedback I remember most clearly came from user who said it was "the first DeFi tool that doesn't feel like I'm using something built by someone who wants me to feel confused." I wrote that down and kept it.

We still had a lot to improve. Protocol coverage needed to expand. The reporting layer needed more depth for audit trail purposes. Some of the yield attribution calculations were simplifications of what we wanted to do eventually.

But the fundamental design decision, that the right approach was to design from the traditional finance user's mental model inward, rather than from crypto conventions outward, I still think that was correct.

Most of the DeFi space designs for the believers. Merlin was trying to design for the skeptics, and it turned out the skeptics had a lot of capital they needed somewhere to put it.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Data tables are the hardest UI problem nobody talks about

Mon, 10 May 2021 00:00:00 GMT

There is a moment every product designer has, when they open a competitor's interface and think "this looks terrible." Then they look at their own work and realize, no, actually, the competitor is just honest about what financial software is. It is a spreadsheet. Maybe a very expensive, very slow spreadsheet. But a spreadsheet.

I had this moment maybe six months into working at VALK. We were building portfolio management interfaces for institutional investors, fund managers, compliance officers, asset managers at banks. People who have Bloomberg terminals on one monitor and our product on the other. I kept trying to make things look like a modern SaaS dashboard. Clean cards. Big numbers. Charts. The users kept asking: "Where is the table?"

This was 2020 going into 2021. I was still learning how finance actually works, and the main lesson was this: financial professionals live in tables. Not because tables are better than charts. Because tables are honest. You cannot argue with a table. You can argue with a chart forever.

Why dashboards are mostly for demos

When you are presenting a product to investor or to potential client, dashboards look incredible. Cards with big green numbers, a nice chart showing growth over time, some summary statistics. It photographs well. It works for demos.

Then actual user sits down. They need to find which investor in their fund is overweight in a specific asset class. Or they need to check which deals closed in Q3 and compare fees across them. Or they need to export something for a compliance report.

You cannot do any of this from a dashboard.

You need to filter. Sort. See raw numbers next to each other. You need a table.

I started understanding this at VALK when I watched how people actually used early versions of the platform versus what I assumed they would do. Nobody clicked the chart. Nobody hovered over the portfolio donut to see allocation breakdown. They went straight to the data table, tried to sort by a column, found that the sort did not work, and opened Excel instead.

That was the moment I stopped designing dashboards first and started designing tables first.

The density problem is real and designers are usually wrong about it

Every design school, every design article, every system like Material Design teaches you: reduce cognitive load. Show less. Use whitespace. Do not overwhelm users.

This advice is correct for consumer products. It is wrong for enterprise finance.

Institutional investors want MORE data visible at once. They want to see 12 columns without scrolling horizontally. They have large monitors, two of them. They are trained to read dense tables. When I made the table "cleaner" by hiding some columns and adding more padding, users told me it felt "lightweight", and they did not mean it as compliment.

I spent real time fighting this instinct to make things sparse. The compromise I eventually landed on: high information density as default, but not visual noise. The difference is subtle. You can have small row height with 8px vertical padding and still have very clear typographic hierarchy. You can show 15 columns if you choose the right column widths and do not add decoration that competes with the content.

The mistake I kept making early on was using cell backgrounds, borders everywhere, lots of color. A table with heavy grid lines and alternating row colors actually makes it harder to scan horizontally than a cleaner table with just a light separator between rows. I eventually removed most borders, kept only a light bottom border on each row, and users started finding information faster in tests.

The 20-column portfolio table

Concrete example. We had a portfolio overview table for one product area at VALK. Asset managers needed to see their entire portfolio in one view. The data model included: asset name, asset type, ISIN or token ID, current value, acquisition price, current price, unrealized P&L, P&L percentage, yield, maturity date, liquidity rating, custodian, jurisdiction, currency, allocation weight, last transaction date, compliance status, and a few internal fields.

That is 18-20 columns depending on the product variant.

My first instinct was to hide most of this. Show six core columns by default, let users add more. This is how Notion, Linear, Airtable handle it. It works well for products where users have different needs and nobody agrees on what is important.

For institutional investors, there was surprisingly high consensus on what they needed to see. Almost every user wanted the same 10-12 columns. The variation was in the remaining 8. So I reversed the approach: show 12 columns by default, let users hide the less common ones. Much better reception. Users felt like the product understood their workflow instead of asking them to configure it before they could work.

The custom column visibility still existed. But the default state was opinionated and correct for the majority of users.

Sorting, filtering, and why they are harder than they look

Sorting is easy to build badly. Single-column sort with a small arrow icon, every developer builds this in an afternoon. But financial tables need multi-column sort. You want to sort by asset type first, then by P&L descending within each type. This interaction is not obvious to design.

I tried several patterns. A sort priority panel, a small drawer that shows sort order visually, worked best. Users could see "sorted by: Asset Type (A-Z) → P&L (high to low)" as chips, drag to reorder priority, click X to remove a sort layer. Felt close to how Excel handles it, which was intentional. These users know Excel deeply. Borrowing patterns from Excel is not a failure of design creativity, it is respecting user's existing mental model.

Filtering was more complex. We needed to support text search within a column, numeric ranges, date ranges, multi-select from predefined values (e. g., jurisdiction: UK, Germany, Netherlands), and presence/absence filters. Each column type needed different filter control.

Static mockups completely failed to communicate this. I would show the filter panel design and developers would say "yes, looks good" and then build something completely different because they did not understand which filter type applied to which column type, or how filter state should persist between sessions.

Prototyping table interactions in Principle

This is where static design tools reach their limits. Figma is great for showing what a table looks like. Figma is useless for showing how a table behaves.

I prototyped almost every key table interaction in Principle. Column reordering, the drag behavior, where the column ghost appears, how other columns shift. Sort state, where clicking a column header cycles through ascending, descending, no sort. Filter panel opening and how the table reacts when filters are applied. Horizontal scrolling with fixed first columns.

Principle forced me to think about states I would have missed in static mockups. What does the empty state look like when filter returns zero results? What happens when sort column gets hidden? What does hover state on a row look like when row has an inline action button? These are not details you naturally think about when designing screens. But in a prototype you hit them immediately.

I do not think every table component needs Principle prototyping. But any interaction that happens in time, drag and drop, scroll behavior, multi-step filter flow, needs to be animated. Static frames of "before" and "after" are not enough for developers to understand intent, and they are not enough for me to understand if the interaction actually makes sense.

Fixed headers, sticky columns, and horizontal scroll

This is a technical problem that designers often hand off to developers without thinking through. But the choices made here directly affect usability.

For our 20-column table: headers should be fixed on vertical scroll. First one or two columns (usually asset name, sometimes asset ID) should be sticky on horizontal scroll. Everything else can scroll horizontally.

The sticky column implementation looked straightforward until you hit the shadow. When content scrolls behind a sticky column, you need a visual separator, usually a box shadow on the right edge of the sticky column. Simple idea. But the shadow needs to appear only when content is actually scrolled beneath it, not always. Always-visible shadow makes the table feel broken when you are at leftmost position.

Small detail. Matters a lot for perceived quality. I specified it explicitly in handoff, with a note explaining the conditional logic, because I only noticed it after prototyping the scroll behavior and watching it carefully. Without that note it would have been built wrong.

Color coding financial data

Green and red. P&L positive is green, negative is red. This is so universal in finance that it feels like law.

Problem: about 8% of men have some form of red-green color blindness. In a product used by dozens of investment banks and hundreds of users, that is not a small edge case. At some point we had a user complain they could not reliably distinguish our P&L indicators.

I updated the color system to not rely on color alone. Positive values: green text with a small up arrow prefix. Negative values: red text, a minus sign, a small down arrow. Slightly more visually noisy but fully accessible. Users who see color get the same experience, users who do not can rely on the symbols.

I also added a high contrast mode toggle later, which changed the green to a brighter blue-green and red to a more orange-tinted red, both distinguishable for most types of color vision deficiency. This was not in the original design. It came from that one user complaint and then actual thinking about the problem.

Keyboard navigation and screen readers

Financial professionals often use keyboard shortcuts. Bloomberg terminal has trained entire generation of finance people to navigate without mouse. Expecting keyboard navigation is reasonable for this audience.

I specified full keyboard nav for our table: tab through interactive elements, arrow keys to move focus between cells in the active row, enter to open row details, space to select row for bulk action. This required working with developers closely because focus management in a table is actually complex. Which element receives focus when you open a filter panel? Where does focus return when you close it?

I did not have deep background in accessibility when I started at VALK. I learned a lot of this by reading WCAG guidelines and by testing with keyboard only, forcing myself to complete tasks without touching mouse. It revealed problems I could not have found any other way.

Screen reader support for tables requires proper semantic HTML, real <table>, <th>, <caption> elements with appropriate ARIA attributes, not divs styled to look like table. I marked this explicitly in my design specs, though making sure it was actually implemented was ongoing conversation with developers who sometimes preferred div-based approaches for styling flexibility.

Why Material Design table guidelines did not help

I tried applying Material Design's data table guidelines early on. They are well-thought-out for certain use cases, list of users, list of orders, simple CRUD tables. Financial data tables are fundamentally different.

Material table guidelines suggest 56px row height for standard density. Our users needed 36px or even 32px rows to see enough data on screen. Material suggests limiting columns to what fits without horizontal scroll. We needed 20 columns. Multi-column sort, complex filter panels, column customization, none of this is really addressed.

I am not criticizing Material Design. It is excellent for what it is designed for. But using consumer design system guidelines for institutional finance software is like using a residential building code to design a hospital. Same general domain, completely different requirements.

Our table component ended up being custom in almost every meaningful way. The component library we built referenced some general principles, contrast ratios, spacing scale, but the table itself was designed from scratch based on how our actual users worked.

Every table eventually becomes a spreadsheet

The honest conclusion I reached after a year and a half of designing financial interfaces: users will always want to make it more like a spreadsheet. Not because they hate our product. Because spreadsheets are genuinely powerful for financial analysis in ways that most table components are not.

The right response is not to compete with Excel. It is to be better at the things Excel is bad at, real-time data, compliance-aware workflows, audit trail, multi-user collaboration. Let Excel be Excel. Let our product be the source of truth that feeds into Excel when users need raw flexibility.

I added a clean CSV export to every table we built. One click. Respects current filter state and column order. This single feature reduced friction more than almost any design improvement I made to the tables themselves. Sometimes best UX is giving users a way out.

Building data tables for people who stare at data for eight hours a day taught me more about designing for actual human behavior than any dashboard project ever did. It is detail work, specification work, edge case work. Nobody posts it on Dribbble. But it is where real product value lives.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Scaling a design system to 70+ institutions

Mon, 15 Feb 2021 00:00:00 GMT

There is a moment when you realize the system you built is no longer serving you, you are serving it. For me that moment came somewhere around client number forty.

I remember opening Figma one morning in January and counting how many pages were in our main design file. Thirty-one. Some of them were named things like "Client 7 - Tables FINAL" and "Client 12 - Dashboard v3 (their version)". The file had become archaeology. I had to dig through layers of decisions made six months ago to understand why a button was that particular shade of blue.

We had just crossed 70 institutional clients. Investment banks, hedge funds, asset managers across fifteen countries. VALK was growing fast, $4 billion in deals managed on a platform I designed. And the design system that worked perfectly for seven clients was quietly falling apart under the weight of seventy.

This is what that experience taught me.

The white-label problem is actually a philosophy problem

VALK is a white-label platform. This sounds simple until you live inside it. Every financial institution that comes onboard wants the product to feel like their product. Not a vendor tool. Not "powered by VALK." Their platform, their brand, their color palette on the buttons.

When we had seven clients, I handled this manually. Client comes in, I adjust the colors, tweak the typography, export new assets, coordinate with the dev team. Two days of work, done. Fine.

At fifteen clients this approach started to feel uncomfortable. At thirty it was breaking. At seventy it was completely unsustainable; and we were already inside the problem by the time I fully understood it.

The mistake I made early was thinking of white-label as a visual problem. Change colors, change logo, done. But institutional clients do not just want different colors. They want the product to match their visual identity at a level where their compliance officers, their traders, their investors, none of them feel like they are using a third-party tool. That is a much deeper requirement. It touches typography scale, border radius on cards, density of data tables, even the language used in empty states.

White-label customization is not a skin. It is a dimension of the entire product.

Design tokens were not optional

I had worked with design tokens before VALK, but in a casual way. Mostly color variables with names like primary-blue and background-dark. Useful, but not load-bearing.

At VALK I had to rebuild how I thought about tokens completely.

The system I created had three levels. Global tokens were the raw values, #1A2B4C, 16px, font-weight-600. Semantic tokens mapped those to meaning: color-brand-primary, spacing-component-padding, text-heading-size. Component tokens then referenced the semantic layer, table-header-background, button-primary-text.

This structure meant that when a new client needed their brand color applied throughout the platform, I changed one global token and the semantic layer propagated it everywhere. In theory. In practice, this required the dev team to implement tokens in code the same way I defined them in Figma, which meant extensive documentation and several conversations I was not expecting to have about why this mattered.

Anton and Alex on the frontend side were genuinely good to work with. But developers have different mental models for this. Getting them to honor the token hierarchy, not to just hardcode hex values when they were in a hurry, that was an ongoing effort that lasted well into the year.

What happens to components at scale

When I designed the first version of our data table component, I think I had four variants. Compact, default, with actions column, without actions column. That covered everything we needed.

By February 2021 I was looking at a table component with something close to fifteen different configurations. I am being precise: I counted.

Row density. Header styles, sticky or not. Action columns ranging from none to full dropdown. Pagination modes. Selection states. Expandable rows. Status columns.

Each axis multiplies with the others. Not all combinations exist in the product, but enough of them do that the component had to be built to handle the matrix, not just the cases I had currently imagined.

This is what "component variants explosion" actually feels like. It is not a one-time decision. It is slow accumulation, each request sounds completely reasonable in isolation. "Can we add a row selection mode for this client's workflow?" Of course. Reasonable. But it added another dimension to the component, and that dimension then had to exist and be documented and tested in every other context where the table appeared.

I started maintaining a decision log for major components. Not formal documentation, just a private Figma page where I wrote short notes about why certain variants existed and what client use case drove them. This saved me probably hours of confused re-investigation later.

The "one small customization" pattern

Every enterprise client has one. Mentioned almost apologetically on the second call after they sign. "We know you have a standard platform, and we love it, but we just need one small thing..."

Sometimes it actually is small. A logo placement change, a different default currency display. Fine.

But there is a pattern in enterprise software where "one small customization" is a signal for something larger. The client has an internal stakeholder, a head of UX, a CTO, sometimes just a very opinionated senior trader, who has already decided the product does not quite fit, and they are testing how flexible you are before making their real requests.

I started tracking these differently after month three of rapid growth. Instead of evaluating each request on its own, I started asking: does this need to be solved in the component system, or is this a client-specific override? If it was a systemic gap, I would fix the component and all clients benefited. If it was a preference unique to that institution, I had to be honest that we could not build the entire product around it.

This required saying no sometimes. That was new for me. At a small agency you often say yes to everything because each client is a large percentage of revenue. At VALK with seventy clients, saying yes to every preference request would have destroyed the coherence of the product within months.

How the Figma file structure had to change

The "one big file" approach did not survive scale. I know this sounds obvious in hindsight. It was not obvious when I was inside it.

What replaced it was a library architecture. One master component library, all the base components, variants, tokens defined. This file no real person opened to work in. It was the source of truth. Connected to it were brand-specific theme files, essentially overrides of the token layer for each major client group. Then separate working files for active product design work.

The team that needed to understand this was small, mostly just me and whoever was reviewing my work. But the file structure had to be clear enough that if I was sick for a week, someone could navigate it without me.

Figma's component library system in 2021 was already capable enough for this. The harder part was discipline. Keeping the master library clean, not letting quick fixes sneak in as local components in working files, making sure that when I updated a component it actually propagated correctly through the themed variants.

I failed at this discipline many times. There are still, I am certain, components somewhere in our older files that diverged from the master library and nobody knows when or why. That is the real cost of moving fast.

Documentation became half the job

I want to be honest about this because I did not expect it and it bothered me for a while.

When I joined VALK I thought of myself as someone who designs things. Interfaces, flows, components, systems. Documentation felt like the afterthought, the thing you write after the real work is done.

By early 2021 I was spending something like forty percent of my time writing. Annotating. Creating specification pages in Figma that explained not just what something looked like, but why it looked that way, what the edge cases were, how it should behave on mobile versus desktop, what happened in empty and error and loading states.

With seventy institutional clients and a dev team moving as fast as ours, underdocumented components created bugs. Subtle ones. A table that rendered correctly in the default state but broke in the expanded row state because the developer had seen the design for the default state and assumed. A form that handled the happy path perfectly but had no visual design for the error state so the developer made something up.

Every one of these bugs was ultimately my fault. Not because I designed it wrong, but because I did not communicate the design completely.

I stopped resenting documentation time once I reframed it this way. An undocumented component is an incomplete component. The spec page is not the chore you do after the work, it is the last part of the work.

I wish someone had told me this three years earlier.

The pressure of real money

There is a difference between designing for a startup where a few hundred users will see your work and designing for a platform where $4 billion in deals has been managed on the platform. The stakes are different in a way that is hard to explain but very easy to feel.

This did not create constant anxiety. But it created a different level of attention to certain decisions. What does a user see when a transaction fails to process? What does a first-time investor see when their portfolio has no assets yet? Is this number formatted to two decimal places consistently everywhere, because these are financial figures, and inconsistency in a financial context reads as an error.

Investment banks are extremely sensitive to interface quality. They are used to Bloomberg terminals, to expensive internal tools, to interfaces that convey professionalism through density and precision. A misaligned column, an inconsistent border, a tooltip that appears in the wrong position, in a consumer app these might go unnoticed for weeks. In a platform used by institutional traders they are noticed immediately and they erode trust.

This pushed me toward much more rigorous visual QA. I started treating the staging environment like a design artifact, reviewing it the same way I reviewed Figma files. Finding small inconsistencies. Logging them. Following up.

Not everything got fixed, there was always something more urgent. But the habit of looking carefully at the built product, not just the design file, was worth forming.

What I underestimated completely

Time. Specifically, how long documentation takes.

I knew it would take time. I planned for it. I underestimated by a factor of probably two and a half.

Writing clear specifications for a complex component, something like a multi-state data table with six interaction modes, takes far longer than designing the component itself. You design in visual thinking. You document in linear language, and translation between those modes is slow.

Documentation also becomes outdated faster than you expect. You document version one of a component. Three months later the component changes significantly. Now you have documentation that is wrong, which is in some ways worse than no documentation because it actively misleads.

Keeping it current meant building documentation into my process for every component change, not just new component creation. That habit took time to form.

If I were starting over, I would allocate documentation time separately from design time from the very beginning. Design the component. Stop. Document the component. Ship. In that order, every time.

Where this leaves me

We are two years into VALK and the design system is in genuinely better shape than it was six months ago. It is not finished, design systems are never finished, I think that is definitional, but it is navigable. A new engineer joining the team can find the component they need, understand its variants, read the documentation, and build something that looks correct.

That was not true in the middle of last year.

The difference is not beautiful Figma files. It is mostly disciplined, unglamorous work: documenting, organizing, having conversations with developers about why the token hierarchy matters, saying no to customization requests that would fragment the system.

Scale reveals every assumption you made when things were small. The comfortable shortcuts become visible as technical debt. The things you meant to organize become urgent to organize. The documentation you were going to write eventually becomes documentation you have to write now.

I do not regret the chaos of the growth period. Growing from seven clients to seventy in a year is not something you can plan perfectly for. But I understand now that the design system is infrastructure, not something you build once and maintain. Something you build continuously, and the investment compounds over time.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

What seed funding does to design priorities

Mon, 28 Dec 2020 00:00:00 GMT

The email arrived at strange time. I was sitting in my apartment in Alanya, looking at the Mediterranean. Late evening, maybe 10pm, when the message came through from our CEO saying the round was closed. Metavallon VC, F10/SIX Group, SICTIC. Seed round, confirmed. I remember I put the laptop down and looked at the sea for few minutes, not really knowing what to feel.

Then I opened Figma and went back to the component I was working on.

That was December 2020. About week ago from when I writing this. I have been thinking since then about what funding actually means for designer, specifically for designer who is only designer at company.

Before the round: the quiet period

I joined VALK in November 2019. At that time the product was not nothing, but it was also not finished. We had clear idea of what we building: platform for tokenizing private assets, institutional-grade, built on R3 Corda. The users are investment banks, hedge funds, asset managers. Not consumer people who need friendly onboarding. Professionals who need information density and trust signals.

For first year, pace was manageable. Small team, clear priorities, I knew what I had to design each week. I was designing data rooms, deal management interfaces, investor dashboards, complex stuff, but focused. I had time to do it properly. Time to think about information hierarchy, about how a fund manager at institution in Switzerland would actually use this screen.

We had calls, we iterated. I was remote in Russia or Turkey when others were in London, which made some things slow, but mostly it worked. I would push frames to Figma, write my reasoning in the comments, and we would discuss on the call.

The product was getting better slowly but clearly. That is good feeling; when you can see the progress in the file, when the components become more consistent, when edge cases stop breaking things.

Then the round closed and everything changed in way that I did not fully anticipate.

The overnight shift in expectations

Nothing in the product broke. The platform still worked. The design system was still valid. But suddenly, certain things that were "fine" became "not impressive enough."

This is specific phenomenon that I think every designer at early startup eventually experiences. When company is raising, there is presentation layer that matters separate from the actual product. Investors see demos, not real usage. They see specific screens, specific flows. And if those screens do not communicate "this is enterprise-grade, this is serious, this is worth money", the conversation becomes harder.

I understand this rationally. But it creates strange pressure. You find yourself redesigning a dashboard not because users struggled with it, but because it needs to look more impressive in deck screenshot.

We had one flow, deal discovery, the screen where institutional investors browse available deals, that was functional and tested. Users understood it. But it looked, maybe, like a nice web application. Not like institutional software. After the round closed, there was conversation about making it look more "premium."

I was uncomfortable in that conversation. We had real feedback from real users that the current design was clear and easy to navigate. Where is the problem exactly?

But I also understood the strategic reality. We now had investors. Investors talk to other investors. We would be showing the product in more formal contexts. The presentation layer is not separate from the product, it is part of how the company is perceived, and perception affects partnership deals, next round, everything.

So I did the work. Redesigned certain screens. Made them more visually substantial. Better data visualization on the dashboards, more considered typography in the deal pages. Honestly, some of those changes were genuine improvements. Some were changes made for the wrong reason that happened to be improvements anyway.

The annoying part was not the work itself. It was that I had been proposing some of these visual improvements for months and the answer was always "let's focus on functionality first." After the round closed, same proposals became urgent priority. Funding changed the timeline in ways that had nothing to do with users.

The deck problem

Here is something I did not fully expect when I took this role: how many pitch decks I would design.

As only designer at company, the scope of my work is much larger than "design the product." I also design everything else, marketing materials, social media graphics, conference materials. And decks. Many, many decks.

Before the seed round, decks were maybe 20 percent of my time. During fundraising period and immediately after, it became closer to 40 or 50 percent. Maybe more.

This is strange position to be in. I spent years developing skills for product design, information architecture, user research, interaction design, component systems. And there I was, spending most of my week in Figma making slides look good. Making sure the logo on slide 7 is positioned correctly. Adjusting the gradient on the "our vision" page.

I do not want to say this work is unimportant. Investors read these decks and they make decisions. I understand that.

But it is disconnect. I signed up to design the platform that institutional investors in 15 countries would use. Instead I was spending days on investor presentation materials that would be used maybe 30 times total.

I mentioned this tension once in a call, carefully, not as complaint but as question about priorities. The response was reasonable: right now, getting the round closed is the most important thing, and every tool helps. After the round, it will change. This was true. The deck work has come down somewhat. But it has not disappeared, and I think it will never fully disappear when you are the only designer.

If I were younger designer considering a role like this, I would think about this carefully. The job description says "product designer" but the actual job is "all visual communication for the company." Know that going in.

The irony of investor-facing design

Part of the reason VALK was able to raise was the product. The platform looked credible and functional. Investors could see that the technical execution was serious. Our CEO mentioned in the announcement that the product demonstrated real traction and institutional quality.

That product was designed by me. The same me who was then immediately redirected to make decks.

I am not saying this to be bitter, I am genuinely proud that the product work contributed to something real. But it creates interesting circular logic: the design quality helped raise the money, and raising the money immediately added design work that was not about product design.

The thing that got us here is now slightly lower priority than the things needed for next step.

What funding actually enables

I want to be balanced here, because I am aware that I am describing tensions without describing the genuine positives.

Funding means we can build things I have been wanting to build for months. Better reporting dashboards. More sophisticated investor management interface. Improved document handling in the data rooms. Notification systems that actually made sense. These were not small wishlist items; they were genuine product improvements that users had asked for.

Without funding, "later" can mean very long time. With funding, the engineering team grows, the roadmap becomes real. For me personally, this is exciting. I have design specs sitting in Figma for features that have been waiting months for development capacity. Now those features can actually be built. I can work on something and know it will ship.

There is also different kind of creative energy when company has resources. When everything is extremely constrained, every design decision carries weight that can feel exhausting, if we build this wrong, we cannot afford to rebuild it. When there is more runway, there is slightly more room to iterate, to try things, to improve rather than only survive.

Being remote during the celebration

Small observation. When the round closed, our team in London had celebration. I saw the photos in Slack. They went out somewhere, they had drinks, they were together.

I was in Alanya looking at the sea.

I have worked remotely since I was 14 years old, so this is not new feeling. But it is present. The company had real moment and I experienced it through Slack messages and emoji reactions.

I do not think this is tragedy. I chose this arrangement and I appreciate what it gives me. But when the company celebrates, the remote person celebrates alone. Or in my case, quietly, by going back to Figma.

There is also practical dimension. When the team is physically together after big news, conversations happen organically. Priorities get discussed over drinks. Decisions get made in informal ways. When you are remote, you get the official communications but you miss the texture of how people are actually thinking. I have learned to ask more explicit questions in async messages, to surface things that might otherwise just be assumed.

What I am watching now

We are at the beginning of something that will be different from first year. The company has more structure now, more formal expectations, more visibility, more pressure to demonstrate progress.

For me, this means design roadmap that is more connected to business milestones. Feature X needs to be ready before this conference. Dashboard Y needs to look polished for this investor meeting. The product design is still about users, but it is also now about VALK's position in the market, about what the product communicates to the world about what we are.

I have been at this company for about one year. The next year will look different. More users, more countries, more scrutiny.

What I want to hold onto is the thing that made the product good before the round, the attention to how real users actually work, the willingness to make boring screens functional rather than impressive. Those values do not have to conflict with also making things that look serious and enterprise-grade. The best version is both.

But it requires some resistance to pressure. Someone has to say "this works for users, we should not change it just because it looks less interesting in screenshot." That is part of designer's job that nobody tells you about when you are learning design.

You are also the person who defends the design from the design's own success.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Designing finance when you know nothing about finance

Sun, 20 Sep 2020 00:00:00 GMT

Eight months ago I did not know what IRR meant.

I am not exaggerating. When I joined VALK in November 2019, my entire professional experience was consumer apps, security software interfaces, and e-commerce flows at Spacecode agency in Moscow. The most "financial" thing I had ever designed was a payment confirmation screen. And now I was Lead Product Designer at company building infrastructure for institutional private capital markets. Asset tokenization. Deal origination pipelines. Cap table management. Data rooms.

I did not understand single word of this.

The first weeks were uncomfortable

I remember sitting in my apartment in Saint Petersburg, first week at VALK, reading the product brief and opening maybe fifteen browser tabs to understand what I was reading. IRR, internal rate of return. Cap table, capitalization table, document that shows equity ownership. Data room, secure virtual space for sensitive documents during due diligence. Deal origination, the process of sourcing investment deals.

Every term connected to five more terms I did not know.

At Spacecode I worked on Kaspersky Enterprise products. That was also technical, also B2B, but at least I understood what antivirus does. I understood the concept of threat, of protection, of alert. I could sit with users and have real conversation about their problems. With VALK, I was starting from zero. Complete zero.

The CEO, I will not use his name here, but he is patient man, answered many questions from me in those early weeks. Some of these questions were probably embarrassing. "What exactly happens after investor signs term sheet?" "Why does asset manager need separate view from fund administrator?" "What is difference between debt and equity from user perspective?" Basic questions. The kind any financial professional would consider obvious.

But he answered all of them. And this, I realize now, was important for the product.

The disadvantage is real

I want to be honest: not knowing the domain made my first months slower and more difficult.

When I was designing dashboard for asset performance, I did not know which metrics are most important to fund manager. I did not know natural hierarchy of information in financial report. I had to learn this the same time I was trying to design it, which is not good situation. You cannot make confident decisions about information architecture when you are still learning what the information means.

There were moments when I would present something to the team and they would tell me I had misunderstood completely what the screen needed to do. Not the visual design, the logic. The user flow. Because I had wrong mental model of the process.

At Spacecode, even when I worked on new project, I usually had enough domain knowledge to start designing quickly. Banking app? I use banking app. Security dashboard? I understand security. The VALK work required different approach, a design process that was slower, more research-heavy, more dependent on conversations with people who actually understood what was happening.

For company that needed to move fast, this was not ideal.

But the disadvantage also works in reverse

Here is the thing I did not expect.

Enterprise financial software has very strong conventions. People who work in finance for many years have very specific expectations about how things should look, expectations that come from Bloomberg terminals, from Excel, from legacy software that has not changed its interface in fifteen years. The "standard" for financial data display is often terrible by modern UX standards. Dense tables, small type, no visual hierarchy, no clear primary actions.

And the users defend this. They are comfortable with it. It is familiar.

When I first saw the existing approach to asset overview screens, common in this space, my reaction was: this is too much information, user cannot see what is important, there is no clear entry point. But experienced financial software designer might look at same screen and think: yes, this is how financial dashboard looks.

I did not have this conditioning. So I questioned everything.

I kept asking "why does this need to be here?" and "what is user trying to decide when they look at this?" Sometimes the answer was: it is there because Bloomberg shows it like this. Which is not good reason for design decision.

Sometimes I was wrong. The convention existed for real reason, financial users genuinely need high data density, they genuinely scan information differently from consumer app users, they genuinely need specific metrics visible at all times because their workflow depends on it. I learned which conventions I should respect.

But sometimes the convention was just habit. Inherited from older software. And because I did not know I was supposed to follow it, I did not follow it.

The asset overview problem

Let me give specific example.

One of the core screens in VALK platform is the asset overview, where investor or asset manager sees performance of specific investment. When I first designed this screen, I tried to understand: what decision does user make when they look at this?

After many conversations, the answer was: they are checking if asset is performing as expected, and if not, where the problem is. This is monitoring task, not analysis task. They are not doing deep research here, they are checking status and deciding if they need to investigate further.

So I designed the screen around that task. Clear status at top, is asset performing above, at, or below target? Then the key metrics that answer "why": current value, IRR versus target IRR, distribution history, recent activity. Not everything. Only the information relevant to that specific decision.

This felt obvious to me as UX designer. Of course you design around the task.

When we showed it to early users, several of them asked where the additional data was. They were used to screens that showed everything all the time, because the software they came from did not make hierarchy decisions for them. They were used to finding information themselves in dense table.

We had conversation about this. What we found was interesting: users who had less experience with legacy financial software preferred our approach immediately. Users who came from traditional institutional background needed more time to trust that the data they needed was accessible, just not all visible at same time. Both groups eventually worked well with the design. But the resistance came from people whose expectations were shaped by old conventions. And I had designed something better, partly because I did not know about those conventions.

Learning to read financial reports

After few months, I realized I needed to actually understand finance better if I was going to keep designing for it.

Not to become financial expert. But to have enough knowledge to make faster decisions and ask better questions.

I started reading financial reports, actual reports, the kind that asset managers produce. Not reading them as expert, but reading them as designer: what information is here? How is it organized? What does reader need to find quickly? What is buried that should not be buried?

This was actually very useful exercise. Financial reports have some good organizational logic in them, evolved over many years of users needing specific information. But they also have enormous amount of information that is legally required but not practically useful in daily workflow. Understanding which was which helped me design dashboards that pulled out the actionable information.

I also started to understand the rhythm of financial work. Fund administrators check certain things at end of month. Asset managers have different focus during fundraising period versus asset management period. Investors have different questions at different stages of investment lifecycle. Design that does not understand these rhythms will feel wrong even if it looks right.

This knowledge came slowly. I am still learning. But now, eight months in, I can have real conversations about product decisions without needing to translate everything first.

What living here has to do with it

I am writing this from my apartment in Alanya, Turkey. I moved here in August after spending several months in Russia. Alanya is small coastal city, not the kind of place most software workers would choose for remote work, but it has good internet, very low cost of living, and it is quiet.

The cost of living part matters more than it sounds. When you are not stressed about money, you can afford to take time to learn things properly. I spent time in these eight months reading about finance, asking questions, going slowly on things I did not understand; because I was not in situation where I needed to rush past the difficulty to pay my bills. I think this gave me better foundation for the work than if I had forced myself to design fast from day one without understanding what I was designing.

There is something to be said for having space to learn your domain.

The question I keep asking

One habit I developed from being outsider to finance is that I ask this question constantly: what is the actual decision the user is making right now?

Not what information they have. Not what they are looking at. What decision are they making, and what do they need to make it well?

This sounds simple but it cuts through a lot of complexity in enterprise product design. Financial software is full of screens that show information without being organized around decisions. The information is there, all of it, but the user has to do mental work to connect it to their task.

When you know the domain deeply, you sometimes stop noticing this problem. You adapt. You learn to find what you need in the dense interface. When you do not know the domain, the friction stays visible longer, you cannot ignore it by adapting, because you do not know enough to adapt. So you have to fix it.

I do not think domain ignorance is asset that stays valuable forever. At some point, not knowing things just means you make bad decisions and have to go back. The window of useful ignorance is probably the first year, long enough to design genuinely, short enough that you are still learning fast.

I am trying to use this window well. Ask the questions that will sound stupid in a year. Design without knowing what I am "supposed" to design. And meanwhile, keep reading those financial reports.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Building a design system from zero at a fintech startup

Mon, 15 Jun 2020 00:00:00 GMT

Six months ago I opened Figma file for first time at VALK and felt something I did not expect. Not excitement. Just confusion.

The file had no structure. Components were scattered without any naming logic. Colors were hardcoded everywhere, not variables, just hex values copied and pasted into each element. Some screens were designed in Sketch and then exported as images and placed directly into Figma. Someone had clearly tried to make interface look more professional at some point, but result was patchwork of decisions that did not talk to each other.

This was the MVP. Functional, technically. From design perspective, it was starting point for everything.

I had been at Spacecode agency for two years before VALK. At agency, design system was already there when I joined. Somebody else made all difficult decisions, naming conventions, grid structure, component hierarchy. I worked inside established system. I complained sometimes that system was limiting, but I did not appreciate what it meant to have one until I arrived somewhere that did not.

What I inherited

The product at this point was deal management platform for institutional investors. Complex tables, data rooms, investor documents, financial reporting. Not simple consumer application with five screens. Dozens of flows, many edge cases, and user base that does not forgive mistakes, investment managers, compliance officers, people who care very much about precision.

The engineer-built interface worked. Buttons clicked, data loaded, forms submitted. But it was interface built by people whose mental model was the code, not the user. Information hierarchy made sense from database perspective. It did not make sense from human perspective.

Typography was inconsistent. In some places body text was 14px, in other places 13px, in other places 15px. No reason for any of these choices. Spacing between elements followed no grid. Some cards had 16px padding, some had 20px, some had 24px, all on same page.

For developer, these details do not matter much. Code is code. For designer who needs to create coherent system from this, every inconsistency is either problem to solve or problem to accept.

First instinct was wrong

My first instinct was to stop everything and build proper design system before touching any screens. Define tokens. Name colors. Create spacing scale. Build component library. Then design.

This is wrong approach. I know this now.

I spent almost six weeks trying to create complete foundation before designing actual product. I made beautiful token documentation in Figma. I wrote naming conventions. I created color palette with semantic names, color-primary, color-danger, color-surface. I built button component with all variants.

And then I had design system for product I did not understand yet.

The problem with building system first is that you do not know what system you need. Every decision you make is abstract. You name color "primary" but you do not yet know all contexts where primary color will be used. You build button component but you have not yet seen all the edge cases that will force you to add fifth variant you did not plan for.

After six weeks I threw away most of this work. Some decisions survived, but most of the early system was built on assumptions about product that turned out to be wrong.

What actually worked: pages first

After failed system-first approach, I changed method. I started designing individual pages with obsessive attention to detail, not thinking about reusability yet. Just making each screen as good as it could be.

I spent probably three days on single table component. Financial data tables in enterprise product have many states, empty, loading, sorted, filtered, paginated, error. Row with action. Row without action. Expandable row. And within each state, many combinations.

I documented all of these. Every variant, every edge case. For each page I did same thing.

Slowly, after two months, patterns started to appear. I noticed I was making same table component over and over with small differences. Button styles were same across all pages. Spacing decisions I made on page one were becoming unconscious standard for pages that came after.

Design system emerged from this. It was not planned, it was discovered.

This approach has name. I learned later it is called "extract, not prescribe." You design real things, then extract the patterns into system. You do not prescribe patterns before you have evidence for them. For someone coming from agency where system already existed, this was uncomfortable. It felt wrong to copy component from one page to another without having proper component library. But it was correct approach for where we were.

Figma organization for one person

When you are solo designer in startup, Figma organization matters more than people think. Not because you need to share files with other designers, there are no other designers. But because you will return to files you made six months ago and need to understand them immediately.

My Figma structure at VALK went through three iterations.

First iteration: one big file for everything. This is terrible. Do not do this. Second iteration was separate file per product area, which was better, but component sharing became problem. If I updated button component in one file, I had to manually update it in others.

Third iteration, which I am still using now: two files. One "master" file that contains all components, tokens, and shared styles. One file per product page or flow that uses instances from master. Updates in master propagate everywhere.

For component naming, I adopted convention that I now defend very strongly. Every component has name in this pattern: Category/Subcategory/Variant/State. So button is not called "button"; it is called Action/Button/Primary/Default or Action/Button/Primary/Hover. Table row is Data/Table/Row/Expandable.

This feels excessive at first. But when you have fifty components and need to find specific one at 11pm before deadline, you appreciate the structure.

Color styles follow different convention. Every color token has two names, technical name and semantic name. I use semantic name in all actual designs: Color/Surface/Background, Color/Text/Secondary, Color/Status/Error. Technical names exist only in master token documentation.

Getting the dev team to actually follow specifications

This was, honestly, harder problem than building the system.

At Spacecode, handoff process was established. Developers knew to look at Figma, knew what redlines meant. They had been doing it for years before I arrived. At VALK, developers did not have strong culture of checking design specifications in beginning. They were building quickly, product was moving fast. Sometimes they would look at design, sometimes they would make their own decisions about spacing or color or behavior.

I do not blame them for this. It is natural in early startup where design is often treated as last step before shipping, not first step in planning.

What changed it was not confrontation. I do not like confrontation and I also did not think it would work. What changed it was making specifications impossible to ignore, making design so detailed that following it was easier than making own decisions.

I started writing very specific Figma notes on every component. Exact CSS values, interaction behavior, hover state timing, disabled state rules. I made Figma prototype in Principle for complex interactions so developer could see exactly what animation should look like. And I started joining technical discussions earlier, when frontend engineer was about to build new feature, I would bring Figma file to that conversation before any code was written. When design is shown before coding starts, developer thinks about implementation while looking at design. When design is shown after coding starts, developer is defending work already done.

Our frontend engineer Alex told me at some point that specific Figma annotations saved him maybe one hour per week because he did not have to guess or send questions. Small thing, but it built trust.

What I got wrong about scale

When I was building component library, I made mistake of trying to create every possible variant immediately. Better to have everything ready, I thought, so I do not have to go back and update component later.

Result was button component with eleven variants, most of which we never used.

Unused components are not neutral. They take time to maintain. When you update design language, you update every variant. When someone new looks at your system, they wonder why there are eleven button types and which one to use. Complexity creates confusion even when it is hidden in component library.

Better approach: build what you need, when you need it. Do not preemptively build.

I read something from designer at large company around this time that stayed with me: "A design system is not a dictionary where you put in all possible words. It is grammar, rules that let you make new words correctly when you need them."

I think this is right.

Six months in, honest assessment

I am writing this from my apartment in Russia. I came back here after Bali in March when COVID made continuing remote travel complicated. Less movement, more deep work, it has actually been good for focus.

The design system at VALK is now functional. Not perfect, but functional. Consistent typography, spacing grid, color system with proper semantic naming. Component library covers probably 70% of UI elements we use regularly.

More important than the system itself: the product looks like product now. There is visual logic. Investor who opens deal page sees same design language as one who is looking at portfolio dashboard. This sounds obvious but it is not obvious when you are building feature by feature in startup.

What I would tell myself six months ago: do not start with system. Start with pages. Let system find you through repetition. Documentation is not bureaucracy, it is communication with future version of yourself and with developers who need to implement your work. Perfect component library that ships in four months is worse than good-enough component library that ships in four weeks.

And the most uncomfortable truth: when you are sole designer at startup, you will spend significant time on things that are not product design. Pitch decks. Marketing materials. Social media graphics. This will feel wrong if you care deeply about product. But resisting it wastes energy better spent elsewhere.

The component library is not finished. Probably it is never finished. But it is solid enough to build on, and that is what matters at this stage.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.

Starting New Design Job During Global Pandemic

Sat, 28 Mar 2020 00:00:00 GMT

I joined VALK in November last year. Small fintech company from UK, building platform for institutional investors to tokenize and manage private assets. When I say small I mean it, I am the only designer.

Before this I was lead designer at agency in Moscow. Spacecode. We had team of five designers and we shipped maybe 50 apps in two years. Banking apps, loyalty programs, event platforms. Fast work, different client every few weeks. I loved speed of it but I was tired of never seeing my designs actually live for more than launch day.

So when VALK offered me remote position to build their product from ground up, I said yes. I packed my bag and went to Thailand with my partner. Then Vietnam. Then back to Thailand. I was designing fintech platform from beach in Phuket and it felt like I figured out life.

Then COVID happened.

Stuck in Bali with Figma

March 2020. We were in Bali when everything started closing. Flights cancelled. Borders closed. My partner and I got stuck in small apartment in Canggu and suddenly "remote work from paradise" became "quarantine in place you cannot leave."

The strange thing is, my work did not change at all. I was already fully remote. My team was in London, I was wherever I happened to be. We used Slack for communication, Figma for design, Asana for tasks. The CEO would send me brief or we discuss on call, I design, I post in Slack, dev team implements. Simple.

But everything around work changed. The anxiety of not knowing when I can go home. Reading news every morning instead of designing. My partner stressed. Friends back in Russia confused. And somehow I still need to design clean, professional interfaces for people who manage millions of dollars.

The MVP Was Ugly

I need to be honest about what I walked into. When I joined, VALK had existing product but it was... not good visually. Functional, yes. Engineers built it and it worked. But the interface was what you get when backend developers make design decisions. Grey boxes, inconsistent spacing, buttons that look different on every page.

My first month I just studied. Opened every screen, every flow, every edge case. Tried to understand what this product actually does. Asset tokenization is not simple concept, especially when your previous work was designing food delivery app for Russian bank.

I made mistake of trying to redesign everything at once. Created beautiful mockups, new design language, modern components. Showed to CEO on our weekly call. He liked it but said we cannot rebuild everything, we have clients using current version. Real clients. Investment banks.

That was first lesson. Agency design and product design is completely different thing. At agency you start from zero, make it beautiful, ship it, move on. At product company you inherit mess and you fix it piece by piece while people are still using it.

Learning Finance by Designing Finance

Nobody teaches you about cap tables in design school. Or what "deal origination" means. Or why investor needs to see IRR calculation in specific format that looks ugly to you but is actually industry standard.

First two months I was searching everything. Reading about private equity. Watching YouTube videos about how tokenization works. Asking our CEO basic questions that probably made me look stupid. "What is data room?" "Why do investors need to sign this document before they can see the deal?"

But here is the thing, not understanding domain is actually advantage for designer sometimes. I would look at screen full of financial data and ask "does user really need all of this at once?" And answer was usually no. The engineers built it to show everything because they could. My job was to figure out what matters right now for this specific user in this specific moment.

I redesigned the deal presentation page first. Original was wall of text with legal documents listed in table. I turned it into something that looks more like product page, key metrics visible immediately, documents organized by type, progress indicator showing where deal is in lifecycle. Nothing revolutionary. Just basic information hierarchy that nobody applied before because nobody with design background touched it.

Remote Process That Actually Works

People keep asking me how I manage design process remotely, especially now with COVID when everyone suddenly working from home. So here is what works for me.

I do not do long meetings. I have one call per week with CEO where we discuss priorities. Everything else is async. I design in Figma, I leave detailed comments explaining my decisions, I post screenshots in Slack with context. If dev team has question they message me. If I have question I message them.

The key thing, and I think many designers miss this, is that your Figma file IS your communication. Every frame should be self-explanatory. I name layers properly. I add notes. I create flow diagrams next to screens so developer can see how user gets from point A to point B without asking me.

At Spacecode we had meetings every day. Stand-ups, reviews, presentations. I spent maybe 30% of my time in meetings. Now I spend zero time in meetings except that one weekly call. And I ship more work than I did before.

Is it lonely? Sometimes. I miss having other designers to bounce ideas off. When I worked at agency I could walk to next desk and say "does this interaction make sense?" Now I am alone with my decisions. I started using Principle to prototype interactions and record them as video to send to team, because showing is better than explaining, especially when your English is not perfect.

What I Learned So Far

It has been only five months but I already see how different this is from agency work. At agency, design is the product. Client pays for design. At startup, design is tool to make product work. Nobody cares if your spacing is perfect if the feature does not solve user problem.

I also learned that financial products have much stricter requirements than consumer apps. You cannot just move button because it looks better. Compliance team needs to approve changes. Audit trail matters. Some things look ugly because regulation requires them to be that way.

Writing this from Bali, or what is left of normal life in Bali right now. Beaches are empty, restaurants closed. But Figma works same everywhere and I have good wifi. Tomorrow I will keep working on the portfolio management redesign while world figures out what is happening.

Maybe when this is over I will write more about specific design challenges in fintech. For now I am just grateful I have interesting work to do during very strange time.

Originally published on kargaev.me. Imported to blog.deeflect.com archive.