DEV Community: Alex Rezvov

One Idea, Three Hundred Pages

Alex Rezvov — Fri, 15 May 2026 15:04:40 +0000

"99% were 1 idea stretched across 300 pages. They should have been blog posts."

— Nicolas Cole, after reading more than 500 business books

I have read a lot of business books, and most of them work in the same way. The author takes one simple idea and then turns it over from every side, on a long series of examples. Peter Sims' Little Bets is a clear example of the type. The whole book is really one idea: when something is cheaper to test than to plan and assess the risks, you should test it instead of planning. I had that on the first page, the first example made it concrete, and then the rest of the book was the same idea about thirty more times.

I liked Little Bets, I still use its idea regularly, and I recommend it to other people. That part never changed. What bothered me was the form. From the first read I was sure the book was artificially inflated, that the real content would fit in a few pages, and that everything else was there to turn it into something thick enough to sell.

For a long time my model of how an idea should be presented was the opposite of this. It was Martin Fowler's UML Distilled, a deliberately thin book about a very large subject. Fowler treats the slimness as the whole point rather than a limitation:

"My proudest thing about this book is that it's under half an inch thick — which was very unusual for OO modeling books at that time."

— Martin Fowler, UML Distilled

So my verdict on books like Little Bets was simple, and for years it did not move. They are padded. There is one paragraph of real content, and the rest exists to make the object heavy enough to sell. I was right about part of that, and wrong about the rest, and this is what changed my mind.

The economics: the padding is real

Let me start with the part I had right, because it is true and worth saying plainly.

A nonfiction book has a minimum practical size. Most of them land somewhere between 50,000 and 90,000 words, and the reason is physical rather than intellectual. A book too thin to have a visible spine does not survive on a shelf, and you cannot really sell a fifteen-page argument as a 25-dollar hardcover. The format needs a certain length, the idea itself rarely supplies it, and so the examples are what end up filling the gap.

The economics make this even clearer. Most business books sell fewer than 5,000 copies, at one or two dollars of royalty each, so the book itself is not actually the product. It works much more like a business card. The real income comes from talks and consulting, where a single paid workshop can bring in more than a thousand sold copies would. Seen from that side, "one idea stretched across 300 pages" is not a failure of the book at all. It is the book doing exactly the job it was written to do.

There is even a market that sells the short version directly. Blinkist, Headway and Shortform together form a several-hundred-million-dollar industry whose entire product is these same books with the repetition taken out, and Headway alone reports more than 50 million downloads. People are paying, specifically, to get the one sentence without the other 299 pages.

So the cynical view holds up well enough. The trouble is that it only explains why the books are built this way. It does not explain why some of them actually work on the reader.

What I saw when I explained things to people

The other half of the answer did not come from books at all. It came from years of explaining things to people.

The pattern is always the same. You explain a task, the person agrees and tells you it is clear, and a week later it turns out it was not clear at all. What took me far too long to accept is that they were not pretending. They were genuinely sure they had understood it. Either they did not ask the question that would have exposed the gap, or they could not see the gap themselves. At first I thought this was about particular people. Then I started seeing it in almost everyone I worked with, and eventually I saw it in myself.

This turns out to be well studied, and the experiments are more direct than you would expect.

In 2002, Rozenblit and Keil asked people how well they understood ordinary objects, such as a zipper, a flush toilet, or a helicopter. Then they asked them to explain, step by step, how each one actually works. The moment people tried to produce the explanation they were certain they already had, their own rating of their understanding dropped by almost a full point on a seven-point scale. The effect is strongest for how-and-why knowledge, which is exactly the kind of knowledge a nonfiction book is made of. The name for this is the illusion of explanatory depth.

Roediger and Karpicke ran a study like this in 2006. They split people into two groups. One group simply reread the material. The other group put the text away and practiced recalling it from memory instead of reading it again. The rereading group was the more confident that it would remember. A week later it actually remembered less, scoring 40 percent against 61 percent for the group that had practiced recalling. The group that felt more sure of itself was the group that did worse. Rereading feels easy the second time through, and it is that easy feeling that the mind mistakes for actually knowing the material.

So when someone says they understood something and they actually did not, it is not because they were careless, and it is not because they are not capable. It is a known and repeatable mistake in the way people judge their own understanding, and I make it just as easily as anyone else does.

The same mistake on my side

There is a matching error on my side of the table, and it is harder to catch because I cannot feel it from the inside either. It is called the curse of knowledge. In one well-known study, people tapped out the rhythm of a famous song and predicted that listeners would recognize it about half the time. The listeners recognized 3 out of 120, which is a little over two percent. Once the tune is already playing in your head, you simply cannot model the person who does not have it there.

When an idea is obvious to me after a single sentence, I am the person tapping out the tune, and I cannot honestly judge how many passes the other person needs. So "it is padding" and "they said they understood but they did not" turn out to be the same error seen from two ends. The reader believes more arrived than really did, and the writer believes one pass was enough. Both mistakes push in the same direction, and the repetition in a book is what corrects for both of them at the same time.

Where the science stops agreeing with me

Here I have to be careful, because the convenient version of this argument is actually wrong.

The science does not support "say it a hundred times." Rereading the same text is in fact one of the weakest ways to learn anything. In Dunlosky's 2013 review of study techniques, plain rereading and highlighting came out near the bottom, while self-testing and spaced practice came out on top. A book that repeats the same sentence thirty times in a row really is bad padding, and on that specific case the cynical view is entirely correct.

What actually works is not repetition but re-encounter: meeting the same idea again after some time has passed, in a different form, and ideally while you reconstruct it yourself rather than just reading quickly past it. A book that comes back to its central point through a different chapter, a different case and a different angle is doing exactly what the evidence supports. A book that comes back to it word for word is not. That, in the end, is the difference between a book that changes how you work and a book you only finish out of stubbornness. The thing that mattered was never the number of repetitions, it was their variety.

Why different examples, not more repetition

The clearest result in this whole area is the one about examples specifically.

Gick and Holyoak gave people a puzzle that almost no one could solve on their own. First they gave some of them one story that had nothing to do with the puzzle on the surface but was solved in the same way, and about 30 percent of those people then solved the puzzle. Then they gave another group two such stories, different on the surface but solved by the same trick, and about 52 percent of that group solved it. Seeing the same trick in two different disguises is what let people notice the trick itself, apart from the story it was wrapped in. Rohrer and Taylor found the same thing in ordinary math practice: students who practiced several problem types mixed together did far better on a later test, 63 percent, than students who practiced one type at a time in blocks, who scored 20 percent.

With a single example, you tend to remember only that example, tied to its own story. With several different examples, what stays with you is the general idea itself, and you can apply it to your own case, one the author never described. So "one idea, ten different stories" is not the author padding the book out. It is the only reliable way to make the idea usable in a situation other than the one on the page. The examples that felt repetitive were the part that was actually teaching you. They felt repetitive only because you cannot feel the learning happening while you read.

What I take from this

So my old verdict was only half right. Here is what I am actually taking from it.

The repetition in these books is doing real work, and I need to learn to do the same thing on purpose. If I want an idea to stay in a reader's head, saying it once is not enough. It has to come back, in different forms, until it is wired in and not just heard once.
This looks a lot like training a model. To fix a fact in a neural network you show it again and again, in different forms, until it settles into the weights. A book does the same thing, except the network being trained is the one in the reader's head. Different hardware, same need for repetition, and the neurons still have to do the work.
And this openly contradicts DRY and the principle of parsimony, which I have argued for for years, including in less documentation and more signal. Say a thing once, never repeat it: that is right for code and for reference docs. It is wrong for getting an idea to stay in a person. So the question I am left with is not "fewer words or more words." The information itself should still be stored parsimoniously: written once, tight, nothing repeated. The repetition belongs in how it is delivered, not in the source. You take that one tight version, give it to the person again in different forms, and check what actually stuck by making them recall it instead of rereading it. An LLM could sit right there, turning one parsimonious source into the varied repetition and the recall checks, different for each person. There is something worth thinking about here.

And this article will probably need to be repeated in other forms too. Right?

Originally published: One Idea, Three Hundred Pages — Alex Rezvov's Blog

The Future of User Interfaces and the Role of AI

Alex Rezvov — Tue, 12 May 2026 14:05:04 +0000

The Scene

"Find me marathon shoes for the next race. Neutral stride, sixty kilometers a week, budget around two-fifty."

A minute later three options come back, each with reasons. I say "give me the second one, size 43." Another minute later: payment confirmation, delivery date, no five-step forms. I never went near a website. I never tapped a button in someone else's UI. I don't even have an account at this store.

This isn't science fiction. It's 2026. OpenAI and Stripe shipped the Agentic Commerce Protocol. Google and Shopify shipped the Universal Commerce Protocol. Visa, Mastercard, Amazon, Walmart, Etsy are on board. AI-driven traffic to Shopify is up 8x year over year, orders out of AI-powered search up 15x. There's an LLM between me and the store.

For the skeptics. What I described above already runs at maybe seventy or eighty percent. Inside ChatGPT you can buy from Etsy and onboarded Shopify merchants through Instant Checkout, which launched in February 2026. In March, OpenAI walked some of it back; for many Shopify merchants the actual checkout now happens on the merchant's storefront, inside an in-app browser. The agent also doesn't pull a personal fitness profile by itself yet. The rest closes over the next year or two.

This piece is about how the user interface is changing and where the LLM sits in that change.

Today's UI Is a Barrier

The "user interface" today is a pile of separate sites and apps. Online stores, dating apps, social networks, banks, insurance portals, hospital portals, government portals. Each one with its own menus, its own vocabulary, its own funnels. Every user has to figure each one out from scratch.

And most of what those products can do never reaches the user.

Microsoft's team found this when they were planning the 2007 Office redesign:

"A study had shown that about 90% of the feature requests for Microsoft Office were for features already in the product. One of the major design goals for Microsoft Office 2007 was making features easier to discover. People just didn't know what was already there." — John D. Cook, "Did the MS Office ribbon work?" (2009)

Users were asking for things that already existed. They just couldn't find them.

Twenty years on, the same problem is systemic enough that Gartner tracks a whole category around solving it: Digital Adoption Platforms. These are overlays that sit on top of business software and whisper hints to the user about what the software actually does. According to Gartner's Market Guide for DAP (September 2025), the DAP market grew around 28% year over year to $1.04 billion in 2024, with projected growth of 15 to 20% in 2025. An entire industry exists to tear down the UI barrier on software people have already paid for.

What I take from this data. People keep asking for capabilities that already exist in the product. The features aren't broken. The interface is a barrier, and you have to fight it to find what you need. A whole class of enterprise software exists just to take that barrier down.

What's Already Happening: Delegation to Agents

People no longer have to navigate every interface themselves. First came research delegation: ChatGPT, Perplexity, Claude doing the searching, comparing, reviewing on the user's behalf. Then autonomous browsing: Anthropic Computer Use, OpenAI Operator, Google Project Mariner. Agents driving browsers for you. In 2025 and 2026, e-commerce got direct agent APIs: two competing standards, ACP (OpenAI + Stripe) and UCP (Google + Shopify, with Amazon, Mastercard, Visa, Meta, Microsoft, and Walmart behind it).

Other verticals (dating, social, banking, healthcare, government) are still at "open API for partners," without dedicated agent protocols. E-commerce ran first; the rest will follow the same pattern.

The technology is in place. The infrastructure is being built right now. There's going to be an LLM intermediary between the user and the business. The traditional UI stops being necessary for everyday operations. It survives as an engineering debug tool, and in a handful of specific cases.

Two Surfaces of the Future

The intermediary has two forms of interaction with a business:

Agent-mediated. The user has a personal agent. The agent talks to the business through a programmatic API (REST, MCP, agent-to-agent protocols), negotiates, buys, signs, tracks. The user never sees the business's website, forms, or menus. From the user, the agent needs a goal and delegation rights. From the business, it needs an API and its documentation.

Personally, I don't see a reason to replace REST with something new for this. I'll write that up separately one day.

Single-window text-or-voice. When the user doesn't have a personal agent (an older person who never set one up; a public terminal at the airport or hospital), they end up in one window, shared across all their interactions. No sites, no apps, no navigation. They just say what they want, in plain language.

The fundamental difference between these two surfaces is who owns the conversation's context.

In the first case, the user's agent prepares and stores the context. The business just gives a clean API. What the user's goal is, what the next steps are, what parts of the history matter: all of that lives with the agent.

In the second case, the business prepares and stores the context. It has to remember who this user is, where they are in the dialogue, what facts have been collected, what prompt and what model fit this moment, when to move to the next state.

Which raises the question: what does "has to remember and switch" actually mean?

Why a Smart LLM Alone Won't Cover It

The natural answer is: feed everything into a long prompt, give the model the whole history, let it figure things out. Each new model release figures things out a little better. So why do you need a structural layer at all?

Five structural reasons why "just a smart LLM" doesn't get you there. None of them go away with a better model.

Auditability. Regulators (SOC 2, HIPAA, PSD2 SCA, GDPR Article 22) expect a deterministic, replayable path through the sensitive parts of a conversation. "The strong model made the right call" isn't the kind of justification an auditor accepts without serious follow-up questions. A state graph gives an explicit path, tied to policies, facts, and transitions. It cuts the cost of an audit a lot.

Editability without a developer. A compliance officer should be able to change one state without involving engineering. In a megaprompt, that kind of edit is a risk of regressing everything else. In an FSM it's a local change with an explicit blast radius.

Personalization without leaks. In the LLM-only approach, all per-user facts usually sit right in the system prompt or in the context window. The model sees everything about every active user and gets to decide what to use. One slip (a jailbreak, a prompt injection, a routine hallucination) and facts from one session show up in another. A state machine inverts that: facts live in a fact store outside the prompt, each state declares which facts it needs, and only those facts go into the prompt for the current turn. The model physically doesn't have the data the current state isn't entitled to. PII leakage is its own category on the OWASP LLM Top 10 (LLM02:2025), which jumped to #2 in the 2025 revision (it was #6 in 2023).

Cost and latency. A long prompt that "knows everything" doesn't scale. Every turn pays for re-loading the whole history. Per-state assembly gives each step the minimum it needs. That's parsimony as an architectural requirement, not as an optimization.

Operator-managed evolution. When the business process changes, the FSM changes: one state, one transition, one prompt. Without the structural layer, any change to the business process means a developer-grade release of the megaprompt, then re-validating and re-testing the whole thing.

A structural layer is needed regardless of how smart the model gets.

Under the Hood: A State Machine for a Marathon Shoe Store

Let's take the scene from the top of the article and walk a customer through the full life cycle, from first visit to a product exchange. I'm picking states at the level of life-cycle phases, not micro-steps. That's where an LLM without an FSM actually starts losing context and dropping policies.

Sign-up and authentication. What this looks like in the LLM-intermediary world is genuinely an open question. Maybe identity gets confirmed through the user's agent provider, and a separate account at every shop is no longer required. Maybe guest checkout with email survives. Maybe a unified identity layer shows up. Whatever form wins, the FSM still needs a state here: this is where the shop decides who's on the other end and which policies apply from here on.

Shopping and cart. "Find me marathon shoes, about sixty kilometers a week, budget around two-fifty." State shopping. The LLM runs the conversation: asks what matters (cushion, pronation, current shoe), filters the catalog, presents options with reasoning. Policies specific to commerce live on this state. For example: don't recommend a model with a drop under 4 mm if the customer's history shows a stress fracture. That policy isn't smeared across a giant prompt; it's bound to shopping and active only here. When the user says "give me the second one, size 43," the choice goes into the fact store, and the FSM checks the exit conditions on shopping (stock, shipping, price agreement) before transitioning to checkout.

Checkout. State checkout. Payment method, shipping address, final price, explicit confirmation. Transition into payment_processing with the external provider, then state payment_confirmation waits on a webhook. For high-value orders, step-up authentication kicks in automatically. Every transition is written to the audit trail. Only after a successful charge is recorded does the state move to order_placed.

Post-purchase follow-up (proactive). Two weeks after delivery, the FSM starts the conversation itself: "how are the shoes treating you?" State post_purchase_followup collects feedback and classifies the answer. All good → case closed. Neutral → feedback goes to analytics. A problem → the FSM moves to support_request.

Support request (reactive). "They're rubbing me on the heel." State support_request. The LLM gathers more facts (for how long, photos if needed, wearing patterns), the FSM classifies the case: warranty defect, wrong model, wrong size, simple break-in. Based on the classification, it transitions to one of the terminal states: dismiss_with_advice, refund, or exchange.

Exchange with a human in the loop. State exchange. The FSM doesn't try to settle this on its own. It calls a tool: request_back_office_review(case_id, reason, photos, customer_history). The case goes into the shop's back-office queue, the FSM moves to awaiting_human_review, and the conversation with the user pauses ("we've got this, we'll be back to you within the day"). A real person on the shop's side (warehouse, customer service) looks at the case, approves it, asks for photos, or declines, and their decision comes back through a webhook. The FSM picks up the conversation with the user from there: "exchange approved, the courier picks up the old pair on Thursday." That last bit is unique to a state-machine-class system: automation → tool call → human → callback → automation, all inside one uninterrupted conversation with the user.

If a regulator asks "why didn't this user get the mandatory disclosure at checkout?", the shop can show the trace: this state, this validator, this fact, this result. The same shop on the same LLM would work without the state graph, but the auditing and debugging would have to happen by hand, reading through long prompts and message logs.

A CMS for the Post-Website World

The analogy I carry: what CMS was for the web, an FSM engine is for post-web dialogues.

CMS defined page types, content models, navigation, permissions, publishing workflows. The website was the product; the CMS was the invisible backbone.

An FSM engine defines states, fact schemas, transitions, policies, escalations. The dialogue is the product; the FSM is the backbone.

The main thing they share: both layers define structure statically, ahead of time. A page in a CMS exists until someone edits it. A state in an FSM and the instructions inside it are fixed. That's exactly what gives you determinism and auditability: the operator knows what instructions the model will receive when the user lands in state X. Not "the model will figure it out," but "these are the exact instructions for this state."

There's dynamic stuff too: which state the user is in right now, which facts get injected, which slice of history matters this turn. But the skeleton inside which that dynamism happens is fixed. That's the guarantee, not a limitation.

What This Means for People Who Build Products

The unit of design is no longer a screen. It's a state. The UX designer becomes a conversation architect: they design the state graph, write per-state prompts, define transition validators, sketch fact schemas. It's parallel to how UX moved from page-by-page design to component systems in the 2010s. Now the components are conversational states.

I know what I'm writing about because I'm building exactly this kind of system: ExoChat, an engine for managed LLM dialogues.

One more thing I noticed while writing this piece: the same argument runs recursively. The agents themselves (ChatGPT, Perplexity, Claude, Operator) could use an FSM skeleton on the inside. I'll write that one up separately too.

One disclaimer before we wrap: not all UIs disappear. Creative tools (Figma, Premiere, Logic Pro), code editors (IDEs), and games stay canvas-based. The LLM intermediary still shows up alongside them: AI agents inside Figma, Copilot, Claude Code, and Cursor in IDEs, generative pipelines and LLM-driven NPCs in gamedev. The canvas as a way to work isn't going anywhere; voice and text won't replace it. This article isn't about those domains. It's about the interaction between a user and a business in pursuit of a product, a service, or information.

What I'm Taking Away

REST APIs as the default agent surface. That's already the standard in everything we build. The article just confirms the direction.
Pilot ExoChat against a real online store. It's both a real test of the single-window surface and a strong demo.
And you? What does this change for the product you're building?

Originally published: The Future of User Interfaces and the Role of AI — Alex Rezvov's Blog

The Parable of the Three Physician Brothers

Alex Rezvov — Fri, 08 May 2026 05:39:42 +0000

A remarkable parable from ancient China tells the story of three physician brothers: the youngest, most renowned, treated visible illnesses; the middle brother addressed issues in their early stages; and the eldest, unknown to society, focused on prevention to keep people healthy in the first place. The essence of this parable resonates in our daily lives, including the world of business.

The Parable of the Three Physician Brothers

It's common to hear praise for a leader who is skilled and dedicated, someone who tackles challenges head-on. Such a leader might spend every day fighting fires, holding the entire department together, and making every critical decision. This leader represents the youngest brother in the story—always in the spotlight, knowledgeable, and indispensable.

The leader who mirrors the middle brother is less celebrated. They address problems early, preventing them from escalating into significant crises. Their work often goes unnoticed because the issues never reach a dramatic scale.

The eldest brother, however, is almost invisible. In their department, everything runs smoothly. They foresee potential issues and resolve them before they arise. To the untrained observer, it may appear that their job is easy, that they have a fortunate team, or that they simply enjoy good luck.

I’ve often seen the youngest brothers from this parable praised and promoted, while the eldest brothers are overlooked—even though they achieve far greater results.

Have you encountered this kind of unfair treatment?

The Text of the Parable

Once, in ancient China, there were three brothers, all of whom were physicians. People considered the youngest to be the most skilled, and his reputation spread across neighboring provinces. The middle brother had fewer patients, but he was well-known in their hometown. The eldest brother, however, was barely recognized as a doctor and had very few patients.

One day, a young man asked the youngest brother, "Why do you have so many patients? Is it because you're the best doctor?"

The youngest brother replied: "I treat illnesses when they have already manifested, alleviating symptoms and restoring health to the sick. That’s why so many people come to me."

Curious, the young man turned to the middle brother with the same question.

The middle brother answered: "I treat illnesses in their early stages, before they become severe, and prevent them from worsening. That’s why I have fewer patients than my younger brother."

Still intrigued, the young man visited the eldest brother. "What about you?" he asked. "Why are you almost unknown, with so few patients?"

The eldest brother smiled and said: "I teach people to maintain their health, balance their mind and body, and prevent illnesses before they even begin. I speak with spirits and harmonize energies. Those who follow my guidance rarely fall ill, and they don’t need treatment."

Originally published: The Parable of the Three Physician Brothers — Alex Rezvov's Blog

How Ecodomen.ru Helps Save on Domains

Alex Rezvov — Mon, 04 May 2026 10:45:07 +0000

Ecodomen.ru is a volunteer-driven project with open-source code. Its mission is to create a platform that helps users save money on domain registration and renewal.

The recommended usage: to find the most cost-effective domain registrar in the .ru zone for the long term, visit https://ecodomen.ru, enable sorting by ascending renewal cost, and choose the option that suits you best—likely the first result.

In this article, I will cover:

What problems Ecodomen.ru solves for users
Our future plans
Who we’re inviting to join our team

About the Product

If you’re planning to create your own website, you’ll need to choose and register a domain name—a unique address for your site on the internet, such as mydomain.ru. This requires contacting a domain registrar, a company that specializes in registering such addresses. To avoid naming names, here’s a link to Wikipedia that provides examples of registrars.

Interestingly, while all registrars essentially offer the same service—domain registration—their prices can vary significantly. For example, the cost of renewing a domain for the next year can range from 149 to 19,999 RUB, depending on the registrar. On average, renewal prices hover around 1,000-2,000 RUB per year based on observations of clients and developers.

Ecodomen.ru is a service that helps users find and compare prices for different registrars’ services. With this tool, you can easily choose the best offer, especially if you need to register or renew multiple domains. By using Ecodomen.ru, you can significantly reduce domain management costs.

Project History

The project began as a playground for one developer, Maria (https://github.com/orgs/ecodomen/people/mrezvova), as a so-called pet project. It quickly became clear that the workload was too much for one person, so we started looking for developers who also wanted to practice their skills.

Our first attempt to attract new contributors was in Maria’s programming club at her high school. However, when students who had just learned to print “Hello World” in the console saw a project with a “serious” tech stack, it was clear they weren’t ready to participate due to their skill levels.

We turned to the job market, and the initial team of developers was assembled through an unpaid internship. This team consisted of trainees who needed experience working on a large—“almost commercial”—project and developing teamwork skills. Together, we completed most of the work on the first version of the product.

As the project grew, the team expanded to include a project manager, designer, tester, and frontend developers. This allowed us to improve the site’s functionality and appearance, better organize our work, and ensure higher quality in the final product.

However, after a few months, many developers transitioned to other, paid projects, while others left for personal reasons. We once again recruited new developers.

Today, the project’s chat has over 20 participants, each contributing to the project with varying degrees of activity. To emphasize, the project is organized on a volunteer basis, meaning all participants work without compensation.

For more details about the team and the project’s history, watch this video:

Current State and Future Plans

The product is currently in its MVP (Minimum Viable Product) stage. We have implemented price parsers for all registrar websites where it was feasible. For the remaining 3% of registrars, prices were entered manually.

The parsers periodically (ideally daily) update price data from registrar websites. The collected data is presented on a webpage, where users can sort and filter by the most useful parameters: name, website, and prices for registration, renewal, and transfer of .ru domains.

It’s important to explain why we collect these three specific prices:

Registration cost: The price of leasing a domain for the first year. This is usually the most visible price for users and often the first thing they notice. Registrars often set this price very low but increase it significantly in subsequent years.
Renewal cost: The price of leasing a domain for the second and subsequent years. This is the cost users should pay the most attention to, as it determines the long-term expenses of owning a domain. However, this price is often less prominently displayed on registrar websites.
Transfer cost: This is useful to know if you decide to move your domains from one registrar to another. The registrar receiving your domains will charge this fee.

With these functionalities, we aim to confirm the product’s value for users and continue developing its features based on their feedback.

In addition, we have ambitious technical plans:

Splitting the backend (using Django REST Framework or FastAPI) and frontend (using React.js or Vue.js).
Developing a microservices-based backend with FastAPI for experimentation.
Migrating the database from PostgreSQL to YDB as a technical experiment. This involves creating YDB adapters for Django ORM and SQLAlchemy.
Writing unit tests, API tests, E2E tests, and setting up load testing.

We would greatly appreciate your feedback on the product: https://forms.gle/SKXX2XffoAYZbGxW9.

Join the Team

We are currently looking for specialists in product management and promotion: product managers, marketers (including SMM), analysts, and technical writers. We welcome both beginners who need experience or a portfolio project and professionals who like the idea and can provide advice or review the work of junior specialists.

Additionally, we have many technical roles open.

Fill out the application form to join the project, and we’ll invite you to the team: https://forms.gle/xxuYPCR7AvLj2z7J7.

Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle?

Alex Rezvov — Thu, 30 Apr 2026 05:24:03 +0000

On my ASUS ExpertBook B3404CVA running Kubuntu 24.04 (KDE Plasma 5.27.11, X11, Kernel 6.8.0-52-generic), I set the usual keyboard layout switcher via:

/etc/default/keyboard:
XKBLAYOUT="us,ru"
XKBOPTIONS="grp:menu_toggle"

Normally I set up layout switching through the standard graphical interface in Kubuntu — never had to think twice. But on this machine, it simply didn’t work. I had to fall back on this method. And even then, it works only intermittently:

sometimes with the Fn key,
sometimes without,
and there's no clear logic when or why.

🚨 Symptoms

Layout switching works... sometimes
Sometimes requires holding Fn to work
Sometimes doesn’t work at all
After suspend/resume — it starts working again
After reboot — might stop again
In short: totally inconsistent

And here's the kicker:

If I reboot, I can switch layout with a single press of the Right Ctrl/Menu key.
If the system was suspended and resumed, now I can only switch layouts by holding Fn + that same key.

Thanks, engineer from Masus.

🔍 My Investigation

Dug through xev, evtest, setxkbmap, xmodmap, libinput debug-events
Discovered that this key:
- Without Fn: emits Super_L
- With Fn: emits ISO_Next_Group
- Sometimes: emits nothing
Checked BIOS: no useful Fn key control (just Fn Lock Option, irrelevant)
Disabled fcitx5, tried .xprofile, systemd hooks, layout toggles
Tested grp:menu_toggle, grp:rctrl_toggle, grp:win_toggle
Sometimes it worked, then stopped, then resumed after suspend
Eventually wrote a systemd sleep hook that reapplies layout settings post-suspend

⏳ Time Spent

~10 hours over 4 days. I’m a developer. I know what I'm doing. If I struggled this much — imagine a non-tech-savvy user.

🙏 A Message to ASUS Engineers

Dear ASUS engineers,

Thanks for the light laptop, good build quality, and battery life. But please explain:

Why did you replace Right Ctrl with Super_L?
Why does the key's behavior depend on Fn state?
Why is there no BIOS/UEFI or EC override?

You spent your time, budget, and engineering effort to remove a standard key and made it inconsistent, undocumented, and non-overridable.

Please, just let users decide what the key does — especially when it's part of years of muscle memory.

📊 TL;DR

I hacked around it. I use a setxkbmap call from a systemd hook after suspend. It sort of works.

But it’s not stable. It still changes behavior after suspend. Fn sometimes required, sometimes not.

I didn’t fix it — I just learned to live with it. For now. I’ll be back to dig deeper into this absurd situation, but at the moment I simply ran out of time. The story isn’t over yet.

Originally published: Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle? — Alex Rezvov's Blog

Exporting Data from a Serbian Residence Permit Card to PDF on Linux

Alex Rezvov — Wed, 29 Apr 2026 05:01:13 +0000

Recently, I received a Serbian residence permit smart card and wanted to explore its contents. With a card reader at hand and running Kubuntu 24.04, I discovered the utility Baš Čelik, developed by Nikola Ubavić.
The program is available on GitHub:
https://github.com/ubavic/bas-celik.

Installation

To install, I downloaded the executable from the releases section:

curl -L -o bas-celik-cli.linux.amd64 https://github.com/ubavic/bas-celik/releases/download/v2.1.3/bas-celik-cli.linux.amd64

Then, I made the file executable:

chmod +x bas-celik-cli.linux.amd64

Usage

To read the data from the card and save it as a PDF file, I used the following command:

./bas-celik-cli.linux.amd64 -pdf ~/Documents/arezvov-srb-id.pdf

The program successfully read the data and saved it to the specified PDF file on the first try.

Acknowledgment

Many thanks to Nikola Ubavić for developing Baš Čelik. Details about the creation of the utility can be found in his blog: https://blog.ubavic.rs/7/.

Originally published: Exporting Data from a Serbian Residence Permit Card to PDF on Linux — Alex Rezvov's Blog

Kutuzov's Management Method

Alex Rezvov — Tue, 28 Apr 2026 07:47:12 +0000

"He will not bring in any plan of his own. He will not devise or undertake anything, but he will hear everything, remember everything, and put everything in its place. He will not hinder anything useful nor allow anything harmful."

— Prince Andrew Bolkónski's reflections on Kutúzov. Leo Tolstoy, War and Peace, Book 10, Ch. XVI. Translation by Louise and Aylmer Maude.

What Tolstoy showed in Kutuzov

In War and Peace, Kutuzov works like this: the commander in chief stays out of most operational questions, but on a few, he suddenly gives full attention. He can sit through a critical report on the army's position as if it were a chanted prayer service, and then make the only instruction of the whole report about looting among the troops.

You can see this type of leader in modern practice too: someone who rarely speaks up on specifics but sometimes puts full attention on one particular matter, with such force that the rest of the team has no idea why. Tolstoy's Kutuzov is one of the earliest and most detailed portraits of this type. Let's break it down.

Why a leader rarely steps in

Most questions coming to such a leader during a working week — from team members, contractors, or neighboring teams — will get handled in one of several workable ways. And most of the time that's fine: many paths work, and picking between them is up to the person doing the work.

"The color of the button on the landing page doesn't matter to me. Both options work. Let the designer decide."

Sometimes they're wrong, and the leader can see it. But arguing isn't worth it: the effort to convince them is more than the fix is worth.

"The developer wants to rewrite the module from scratch when patching the existing one would do. It'll take longer this way. But convincing him will take even longer, and the difference in outcome is small. Let him go his own way."

Sometimes it's useful to let the person stumble on his own, and not step in. A mistake in a safe situation lowers the chance he'll make it again where the cost is higher. Damage is limited, and it's cheaper to let him trip than to argue.

"A project manager wants to add steps to the task tracker flow — not because of any real need, but because the process 'looks more organized.' I warn him: if the team doesn't see a practical benefit, they won't actually engage with the extra steps. He's confident he's right. I let him try. One sprint in, the team is quietly bypassing the new steps, and he rolls the change back himself. Next time he leads with the practical question first: does this make the team's life easier?"

Sometimes it's already clear the consequences will hurt, but convincing him is more costly than the consequences themselves.

"A neighboring team is about to ship a release without load testing. It'll fall over in the first 24 hours, and support will get buried. But getting them to stop means a political fight with their manager — and that costs more, over time, than cleaning up the mess when it lands."

The 5% where stepping in is essential

What's left are cases you can't skip. One of a leader's key skills is catching these in time — knowing when to step in, and how far.

Tolstoy's sharpest example is the council at Fili. Most of the generals — Bennigsen, Ermólov, Dokhtúrov, Raévski — want to give battle for Moscow. Kutuzov hears them all out, then rises:

"Well, gentlemen, I see that it is I who will have to pay for the broken crockery. Gentlemen, I have heard your views. Some of you will not agree with me. But I, by the authority entrusted to me by my Sovereign and country, order a retreat."

— War and Peace, Book 11, Ch. IV, trans. Maude.

Alone that night, he sits at the table and keeps asking himself: "When, when did the abandonment of Moscow become inevitable? When was that done which settled the matter? And who was to blame for it?" Near the end of the novel, Tolstoy sums it up in one line: "He alone said that the loss of Moscow is not the loss of Russia."

That's what 5%-intervention looks like up close: one person against the majority, against the political cost, against the weight of the decision itself. But here you can't back off — what's at stake is not the leader's standing but the success of the whole effort.

"On the project we agreed at the start: business logic lives on the backend. The team occasionally tries to slip a piece of logic into the frontend. Miss one precedent, and in a month the same logic is in three more places; in three months you can't roll it back. Here you have to put in enough force to keep the project from getting infected: I block the first case and do a review with the whole team."

And there's an unavoidable side effect. For people who don't see the full picture, this focused attention often looks strange, in two different ways. Sometimes the question seems minor to them, and they don't get why the leader is putting so much attention on it. Sometimes the answer seems obvious to them, and they don't get why the leader is going against the majority.

The other side — keeping the team in context

That strangeness is where my own addition starts — something that isn't in Tolstoy's Kutuzov. Kutuzov in the novel doesn't worry about keeping the team informed: secrecy, different goals, and the sheer size and variety of the army make that impossible. For a modern manager, this piece usually turns out to be useful.

When a leader's move looks strange or too detailed to the team, that's not their problem — it's a signal. They don't understand what's being done and why. They don't know the project's goals, the ways of reaching them, their own role in the tasks.

So each time I catch my actions looking strange to the team, I check something like this: do they know the goal of this piece of work? Do they see the link between their tasks and that goal? Do they understand why this specific chunk matters right now rather than another one?

If the answer to any of those is no, the move looks arbitrary, even when the leader is right. What needs fixing is not the action but how well the team holds the overall picture.

There are also Kutuzov-like situations — when keeping the team fully in context just isn't possible. In those moments the leader's actions will look inconsistent and strange whether he likes it or not. All that's left is to honestly understand how those actions look from outside.

And there's a mirror effect. When you see strange, unexplainable actions from your own leadership or from a neighboring team whose decisions are outside your control, remember: you're in the same spot sometimes with your own team. They probably have their own 5% that you aren't seeing.

What is Kutuzov's management method

Boiled down, Kutuzov's method in Tolstoy is a discipline of selective attention:

By default, don't step in. In most operational questions, the people doing the work will handle them their own way. This isn't laziness or checking out — it's a deliberate choice. Your attention is a limited resource; spend it on 95% of the stream and there's nothing left when you really need it.
Catch the 5% of cases where stepping in is critical, and commit fully. No balancing, no half-measures. Put all your attention on those. These are the cases a leader exists for.
A modern addition that isn't in Tolstoy's Kutuzov: keep the team in context. Without the bigger picture, selective attention looks arbitrary from outside. The method doesn't stop working — but you need to understand the costs.

P.S.

Off topic from the article's argument, but worth saying: what I personally like about Kutuzov in the novel is that even in the harshest circumstances — retreat from Moscow, the burning capital, the winter pursuit of a starving enemy — he stays humane.

After Krasnoye, with thousands of ragged French prisoners along the road, Kutuzov speaks to his troops:

"It is hard for you, but still you are at home while they — you see what they have come to. Worse off than our poorest beggars. While they were strong we didn't spare ourselves, but now we may even pity them. They are human beings too. Isn't it so, lads?"

— War and Peace, Book 15, Ch. VI, trans. Maude.

Originally published: Kutuzov's Management Method — Alex Rezvov's Blog

Alex Rezvov Blog Now in Telegram! Tour for New Readers

Alex Rezvov — Wed, 22 Apr 2026 08:56:09 +0000

I added a fourth platform to the blog's publishing pipeline today. A post now goes to blog.rezvov.com, Dev.to, Hashnode, and the Telegram channel @arezvov_race_mode_on. Same git push, four places.

This post is two things. A short note on how the Telegram piece works. And a tour of the blog by topic for anyone who just arrived.

How the Telegram piece works

The infra took an evening. The existing crosspost system already had a PlatformConfig interface for Dev.to and Hashnode — so adding Telegram was about 150 lines of TypeScript. Format the message with HTML, call sendMessage, store the message_id in a YAML plan file for later edits.

What took longer was deciding what to post.

Dropping a 5000-word article into Telegram is absurd. Telegram needs the short version. I'd been writing those manually for LinkedIn — every post got a 1000-char teaser that lived only in my LinkedIn feed. So I formalized a promo field in each post's frontmatter: plain text, 800–1500 chars, written in the same voice as the post.

---
title: "..."
slug: "..."
promo: |
  Hook sentence.

  Two or three paragraphs that carry the post's actual argument,
  with concrete numbers and examples. Not a summary. A pitch that
  makes someone stop scrolling.

  Closing insight that stands on its own.
---

The crosspost script adds the title, canonical URL, and hashtags around it. Two problems solved at once — automated Telegram posting, and LinkedIn promos no longer live only in LinkedIn. They're in the blog repo. Versioned, reviewable in PRs.

A linter rule enforces the constraints: 200–3000 chars, no URLs, no hashtags, no markdown. The script adds the URL and hashtags at send time.

Backfill was the interesting part. Eight posts had existing LinkedIn promos I'd written myself — Claude for Chrome scraped them from my LinkedIn activity feed into JSON, I cleaned URLs and hashtags, pasted into frontmatter. For the other 33 posts I never got around to promoting on LinkedIn, five Opus agents drafted promos in parallel using a style guide I built from the eight real examples. I reviewed, tweaked, applied. Each Claude-drafted promo ends with *extracted by Claude so I can track provenance.

The canonical @arezvov_race_mode_on channel is also my running log. So between blog posts, you'll see the occasional run report. If that's not what you're there for, the hashtags are split — #article for blog posts, different tags for training.

A tour of the blog

If you came here from Telegram and want a sense of what I actually write about, here's a topic-by-topic map.

Context engineering and parsimony

Over the last six months this has become the topic I think about most. Claude and other LLMs have a context budget, and how you spend it determines whether the agent is useful or just confidently wrong.

Principle of Parsimony in Context Engineering — a design rule: every element in the context exists because it contributes to unambiguous task interpretation, enforceable constraints, or result quality. If it doesn't, cut it.
When Prompt Engineering Stops Being Enough — where prompt engineering breaks at scale, and what replaces it.
Less Documentation, More Signal — I trimmed a 500-line instruction file to 40 lines. Humans navigated faster too. Volume stopped meaning quality.
Context Engineering with ExoChat: Parsimony in Action — how this works on a real production system.

AI-driven development in practice

Five Levels of AI-Agent Adoption in Software Development Teams — a taxonomy based on 100+ engineers across 12 projects. L1 (agent babysitting) through L5 (autonomous). You can't skip levels.
Specification-Driven Development: The Four Pillars — how we organize agent-driven teams at ForEach Partners.
Build vs. Buy for Agent Harnesses — when to roll your own, when to adopt.
What CTOs Actually Said About Rust and LLMs — survey result that surprised me.

Deploying and debugging AI tools

Deploying OpenClaw: 16 Incidents, One Day, $1.50 — a narrative of a full-day deployment. Infinite retry loops, thinking-block traps, what broke and why.
OpenClaw Troubleshooting: "No Reply from Agent," WORKFLOW_AUTO.md, and Silent Delivery Failures — the diagnostic companion.
LLMs Changed the Rules: Git for Everyone, SQL for Everyone, Rust for Almost Everyone — how the syntax barrier dropped and who walked through.
Rust and LLMs: The Compiler Does What Code Review Shouldn't Have To — strict types as a discipline for AI-generated code.

Engineering management

Founder Mode — A New Name for Micromanagement? — the viral term and what it actually describes.
The Role of a Team Lead — four responsibilities and the hyper-responsibility trap.
Resolving Architectural Conflicts in Development Teams — when senior engineers disagree on structure.
Doubt Means Growth — why engineers who stop questioning themselves plateau.

The blog itself (meta)

Migrating from Ghost to Next.js: A Journey with Claude and Cursor — the stack rebuild.
Making Your Blog LLM-Friendly: Implementing llms.txt — exposing posts as raw Markdown for AI crawlers.
Five Weeks with a Next.js Blog: What Got Built — what accumulated in the first month and a half.

Where to follow

Blog: blog.rezvov.com — canonical, with RSS at /rss.xml
Telegram: @arezvov_race_mode_on — short versions, plus running log
Dev.to: dev.to/arezvov — same articles, different audience
Hashnode: arezvov.hashnode.dev — same
LinkedIn: linkedin.com/in/arezvov — I post the same promo text there manually

If you have a preferred channel, pick one. The canonical version with comments, search, and code highlighting is always on the blog.

Originally published: Alex Rezvov Blog Now in Telegram! Tour for New Readers — Alex Rezvov's Blog

Doubt Means Growth

Alex Rezvov — Tue, 21 Apr 2026 07:21:52 +0000

Recently, there was a discussion about how to deal with imposter syndrome. Personally, I believe imposter syndrome is a great thing that drives you to grow—so why fight it?

From the very beginning of my career, I lived with this feeling, even before I knew it had a name. Imposter syndrome keeps me from stagnating in my development. It encourages me to critically assess my work and analyze how things could be done better. It’s what motivated me to read professional literature, attend conferences, and seek advice from more experienced colleagues.

I sometimes notice imposter syndrome in others as well. To me, that’s a good sign. It means this person, like me, is being pushed forward, driven to develop, and inspired to keep growing.

PersonalGrowth #SelfDevelopment

Originally published: Doubt Means Growth — Alex Rezvov's Blog

How to Overcome Internal Doubts After Making Decisions

Alex Rezvov — Thu, 16 Apr 2026 07:24:20 +0000

Recently, there was a discussion about how to act when doubts arise after making a decision. I’d like to share my thoughts.

The Scenario

Imagine you are leading a department or an organization and need to make a difficult decision. You’ve carefully weighed the pros and cons, thought everything through, and made your choice. However, during implementation, doubts start creeping in. These doubts may lead to hesitation or even subtle self-sabotage.

And yet, no new circumstances have arisen. All external factors remain the same as when the decision was made.

How to Counter Doubts?

In my view, this situation mirrors how a subordinate might resist a decision they don’t fully accept. Such resistance can manifest in formal compliance but with minimal effort, delays, or even subtle sabotage.

The usual solution? Discussions before the decision. If open dialogue is encouraged in your organization, all opinions should be heard during the decision-making process. Once the decision is finalized, however, it must be accepted as a collective commitment. Without this clarity, unresolved doubts can disrupt implementation and potentially spread uncertainty within the team.

Why This Matters

When you doubt your own decisions, the dynamic is similar. You become both the leader and the hesitant subordinate. Just as an uncommitted team member can spread doubt among colleagues, your own internal hesitation can undermine your confidence and, ultimately, the team's morale.

Your task as a leader is to convince yourself first. Commit fully to the decision you’ve made, as the time for discussion and doubt is over. Once you believe in the decision, your confidence will naturally guide and inspire others.

The Role of Internal Confidence

A leader’s internal confidence is a cornerstone for motivating the team and aligning their efforts. Hesitation from you can easily ripple through the group, undermining their motivation and direction. To keep your team moving forward effectively:

Strengthen your belief in the decision.
Stay consistent in your actions.
Communicate clearly to ensure alignment.

Only when you convince yourself can you inspire the same trust and commitment in others.

PeopleManagement #LeadershipConfidence #DecisionMaking #OvercomingDoubt #TeamMotivation #EffectiveLeadership #SelfTrust

Originally published: How to Overcome Internal Doubts After Making Decisions — Alex Rezvov's Blog

LinkedIn Sales Navigator: The Tool We Need, Not the One We Have

Alex Rezvov — Wed, 15 Apr 2026 05:34:13 +0000

When I explore a specialized tool in a field where I am new, I expect it to be designed by experts with a deeper understanding than I could ever have. After all, I am an amateur, while experienced professionals must have thought carefully about solving the problem in the best way. These were exactly my expectations for LinkedIn Sales Navigator: I thought that the obvious features I needed were already implemented and of the highest quality.

How wrong I was.

First Task: Finding Explicit Needs

The first and most obvious task is to find those companies or individuals who explicitly state their need for a product or service.

In my case, I provide development services of above-average quality on the global market, with prices lower than 75% of companies worldwide.

Although I’ll use my example, the task remains the same regardless of the product: to find those who need it.

What signals can help identify those who need high-quality development at a relatively low cost? The most obvious way is to find those who directly post about it on LinkedIn. Imagine my disappointment when I discovered that LinkedIn Sales Navigator doesn’t allow users to subscribe to notifications for such posts! Dear LinkedIn team, we have LLMs and countless other tools that can practically identify intents flawlessly in any text.

This is the first feature that LinkedIn Sales Navigator should have implemented, and I believe it's the feature I and most other users would immediately subscribe to upon purchasing the tool.

Example of what a real development service request looks like

Second Task: Analyzing User Behavior

Let’s move forward. Let’s assume we are already subscribed to explicit product or service requests.

What if we tried to find those who have realized their need for development and exhibit it in their behavior—for example, by visiting development team pages, messaging developers privately, etc.? We already have amazing tools like data analytics, LLMs, and others, don’t we, LinkedIn engineers?

So, the second feature I’d subscribe to is the ability to identify those who have realized their need for development services but haven’t yet published an explicit request on LinkedIn.

Third Task: Predicting Unconscious Needs

An even more advanced feature would be identifying users who need development services but haven’t yet realized it. For example, they read and comment on articles about managing developers or implementing Agile methods in their teams. Such users might actively explore automation, discuss hiring challenges, or share issues related to digital transformation.

I understand that implementing such a feature would require more effort than a few students from Computer Science courses could handle, unlike the previous tasks. But we’re talking about the mighty LinkedIn, aren’t we?

Such tools would transform LinkedIn Sales Navigator into a modern and fully-fledged sales tool rather than leaving it as a basic directory of companies and leads with primitive filters, as it is today.

This kind of tool would allow providers of goods and services to deliver their proposals directly to the users who need them at the right time—or even slightly earlier. This would reduce spam in personal messages, expand the options for buyers, and make the world a little better.

Conclusion

In conclusion, the lack of such a tool opens up opportunities for its creation. Of course, LinkedIn has far more data than we mere mortals do, but even with publicly available data, many of these tools can be implemented. The specialists at ForEach Partners are capable of tackling such a task.

If you want to launch such a product, contact us at sales@foreachpartners.com—let’s discuss the terms of cooperation.

Originally published: LinkedIn Sales Navigator: The Tool We Need, Not the One We Have — Alex Rezvov's Blog

How We Helped a Client Regain Control of Their Business

Alex Rezvov — Tue, 14 Apr 2026 05:02:19 +0000

In the world of development, there are times when professional collaboration crosses unacceptable boundaries. Our team at ForEach Partners faced one such situation while working on a complex project for a client. What happens when a contractor turns a business-critical website into a tool for blackmail? Threats to shut down the website, which supports key business processes, become a means of coercion. The contractor retained exclusive control over the source code, database, and hosting, leaving the client without access to these critical assets.

This is the story of how we not only helped a client escape such a dire situation but also built a robust system that became a reliable foundation for their business.

How It All Began

The client approached us, sensing an impending crisis. Their previous developers retained control over the source code and database of their portal, dictating terms, deadlines, and costs. Sometimes, they even halted the site’s operation if the client insisted on their own terms. For a business involved in international logistics, such disruptions were catastrophic.

We advised immediate action to create a contingency plan for the portal, even if it required engaging another team. Our goal was to protect the client’s interests and help them navigate out of this crisis. Our experience told us that delaying such decisions only worsens the situation.

The client left to consider their options but returned a few months later. "You were right," they said. "The situation has worsened. Action should have been taken yesterday."

"In every project, the client’s interests must come first. That’s the only way to achieve success."

The Development Phase

Creating a Transitional Solution

We utilized everything available from the existing site—HTML, CSS, and JavaScript—to quickly launch a new version of the portal. These resources were used as-is to minimize time and expedite implementation. Where possible, pages remained static in the same form as retrieved from the old site.

Dynamic functionality, such as allowing users to place new orders, required new server-side logic. Transferring the existing logic was impossible, as the server’s source code was inaccessible. We chose Django as the platform, given its ready-to-use tools for most common tasks. This enabled us to quickly build an interactive and flexible system that met the site’s requirements. Additionally, Django includes a built-in administrative panel, which, while not the most user-friendly, served as a sufficient temporary solution for the current needs.

This approach allowed us to launch the system quickly while preserving its functionality.

How We Gathered Data

To migrate data from the old portal, we developed parsers using Scrapy. The primary challenge was to collect the data discreetly to avoid suspicion from the contractors. The parsers operated from the client’s workstation, making low-frequency requests to stay under the radar.

Together with the client, we identified all necessary data to ensure a seamless launch of the portal within their own infrastructure. The data was collected carefully and discreetly, avoiding any unnecessary risks.

Securing the Website

Simultaneously, we addressed security concerns. We implemented CloudFlare to filter external traffic and conducted a security audit with an experienced specialist from ForEach Partners. Addressing the identified vulnerabilities minimized the risk of sabotage by the contractors and ensured robust system protection.

Fast Launch

Within a month, we completed all tasks: data collection, security setup, and the development of a transitional site based on Django. Static pages remained unchanged where possible, while dynamic elements were handled by Django. As a result, the site launched quickly, maintaining functionality. Thanks to our swift actions, the client avoided sabotage from the contractors and resumed operations on the new platform.

Transition to the New Version of the Site

After the successful launch of the prototype, the client fully transitioned to using the new version of the site. This version allowed them to perform all previous tasks through the administrative panel, though some were not implemented in the most convenient way. For users, practically nothing changed. The only request we made was for them to change their passwords upon first login. Passwords were the only data we couldn’t transfer from the old portal. For users, this appeared as a standard security update and a precautionary password reset. They never realized the massive overhaul behind the scenes!

At this point, the client breathed a sigh of relief and parted ways with the old contractors. We continued working together on improving the system, creating an updated and more powerful version of the site tailored to the business’s evolving needs.

Phase Two: Building a Complete System

Technology and Features

We transitioned to the second phase—developing a flexible and modern system. Using Django Rest Framework (DRF) for the backend and Vue.js with Nuxt.js for the frontend, we achieved:

Independence between user and admin interfaces.
APIs for integration with mobile applications and bots.
Scalability for future changes and enhancements.

Advantages of the New System

Modernity: A completely revamped design improved the user experience.
Flexibility: The architecture easily adapts to new tasks.

Additionally, we ensured that the client had full access to all keys, source codes, and backups at every stage. For us, this is standard practice with all clients.

Lessons We Learned

This project reminded us that success begins with genuine partnership and protecting the client’s interests. Only this approach builds trust and leads to sustainable results. When working toward the client’s goals, relationships become partnerships, and projects become successful.

We are proud to have helped our client regain control and grow their business without fear of unscrupulous contractors.

What conclusions can we draw to share with other developers?

No matter how you try to bind a client to you through force, there will always be someone to help them break free. Trust can only be earned through conscientious pursuit of the client’s goals.

Originally published: How We Helped a Client Regain Control of Their Business — Alex Rezvov's Blog

DEV Community: Alex Rezvov

One Idea, Three Hundred Pages

The economics: the padding is real

What I saw when I explained things to people

The same mistake on my side

Where the science stops agreeing with me

Why different examples, not more repetition

What I take from this

The Future of User Interfaces and the Role of AI

The Scene

Today's UI Is a Barrier

What's Already Happening: Delegation to Agents

Two Surfaces of the Future

Why a Smart LLM Alone Won't Cover It

Under the Hood: A State Machine for a Marathon Shoe Store

A CMS for the Post-Website World

What This Means for People Who Build Products

What I'm Taking Away

The Parable of the Three Physician Brothers

The Parable of the Three Physician Brothers

The Text of the Parable

How Ecodomen.ru Helps Save on Domains

About the Product

Project History

Current State and Future Plans

Join the Team

Links

Dear ASUS: Why Did You Turn My Right Ctrl into a Puzzle?

🚨 Symptoms

🔍 My Investigation

⏳ Time Spent

🙏 A Message to ASUS Engineers

📊 TL;DR

Exporting Data from a Serbian Residence Permit Card to PDF on Linux

Installation

Usage

Acknowledgment

Kutuzov's Management Method

What Tolstoy showed in Kutuzov

Why a leader rarely steps in

The 5% where stepping in is essential

The other side — keeping the team in context

What is Kutuzov's management method

P.S.

Alex Rezvov Blog Now in Telegram! Tour for New Readers

How the Telegram piece works

A tour of the blog

Context engineering and parsimony

AI-driven development in practice

Deploying and debugging AI tools

Engineering management

The blog itself (meta)

Where to follow

Doubt Means Growth

PersonalGrowth #SelfDevelopment

How to Overcome Internal Doubts After Making Decisions

PeopleManagement #LeadershipConfidence #DecisionMaking #OvercomingDoubt #TeamMotivation #EffectiveLeadership #SelfTrust

LinkedIn Sales Navigator: The Tool We Need, Not the One We Have

First Task: Finding Explicit Needs

Second Task: Analyzing User Behavior

Third Task: Predicting Unconscious Needs

Conclusion

How We Helped a Client Regain Control of Their Business

How It All Began

The Development Phase

Creating a Transitional Solution

How We Gathered Data

Securing the Website

Fast Launch

Transition to the New Version of the Site

Phase Two: Building a Complete System

Technology and Features

Advantages of the New System

Lessons We Learned