Forem: Alex Rezvov

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

You Pressured a Contractor on Price: Consequences

Alex Rezvov — Fri, 10 Apr 2026 06:08:38 +0000

During the negotiation process for your software development project, you managed to halve the proposed cost. Great news! Or is it?

Imagine this scenario: you are the person responsible for overseeing a development project in your company. Your task is to guide the project from the requirements stage all the way to deployment in production. You’ve prepared a technical specification, identified several potential contractors in the market, analyzed their proposals, and are now deciding which one to partner with for the project.

Most likely, the contractor’s proposed cost will rank second or third among your decision-making criteria.

It’s very likely that you’ll see a wide variation in the cost estimates provided by contractors—sometimes differing by an order of magnitude.

Now, let’s say you’ve chosen a company, clarified the scope through discussions, and in the final meeting, successfully negotiated a significant price reduction. Let’s explore the potential reasons they agreed to your terms and the possible consequences of such a deal.

Reserved Margin for Negotiation

Experienced salespeople know that price negotiations are inevitable after the initial estimate is presented. They expect to concede something—but not too much. You manage to negotiate a 10–15% discount from the initial price, which they reluctantly grant because you’re an excellent negotiator who knows how to hold your ground. Most likely, you’ve only bargained away the margin they had specifically added for such concessions. If no negotiation happens, it’s great news for the seller, who will likely earn a much larger commission for the deal.

This is a common dynamic, especially when dealing with large companies.

Moreover, experienced salespeople have a few tricks up their sleeves when presenting initial estimates to clients. If the contractor finds the project financially attractive, they will usually discuss pricing verbally during an in-person meeting while closely observing your reactions. The cost can change within seconds, depending on your response. Tactics might include phrases like:

“The price includes/excludes VAT, of course.”
“Naturally, this includes/excludes a year of support, which can be added/removed.”
“This is the estimate for the first phase/the entire project,” depending on your reaction.

If you’re dealing with a contractor of this type, the money you’ve managed to negotiate is indeed saved for your company. You won’t be able to force them into a loss-making position that could endanger the project, which we’ll discuss in other scenarios. Well done! Although it’s possible you didn’t negotiate the full margin that was reserved for concessions—without insider information, you’ll likely never know.

Contractor Resources Are Idle

Sometimes a contractor has unused resources freed up after completing a project, and these resources are sitting idle “on the bench.” These are usually expensive IT specialists whose salaries still need to be paid, even though they’re not generating revenue. Contractors may temporarily assign them to internal projects but will seize any opportunity to sell their time.

In such cases, the contractor’s salesperson may approach negotiations with a goal of covering at least the resource costs. Discounts of 30–50% may be on the table, depending on the company.

A skilled salesperson will, of course, try their best to ensure their company still profits from the project and will only offer significant price reductions under very unfavorable circumstances combined with effective negotiation tactics by the client. To achieve this, you need to not only demonstrate a willingness to walk away from the deal but actually reject it, citing the high cost, so the contractor “chases you to the door.” Without insider information, you won’t easily detect this situation, and guessing it blind would be either extraordinary luck or a genuine disagreement over cost.

If you’ve landed in this scenario, the project should ideally be short-term with potential for expansion into a larger project where the contractor can earn more. If the contractor is willing to provide resources at cost for an entire year, this should raise some red flags.

Furthermore, when prices are halved, a reasonable contractor will always provide an explanation for the reduction. In cases of idle resources, there’s no reason to hide this once the discount is offered, and they will likely tell you directly.

Is it good news for you that you managed to pressure the contractor into such a significant price cut? From a business perspective, it is—while the project may be ballast for the contractor, they will still aim to complete it since they’ll have funds to sustain the resources allocated to your project. However, the likelihood of getting their best specialists or exceeding your expectations decreases.

Contractor Manipulates Project Estimates

Previously, we examined cases where contractors act in good faith. However, this is not always the case.

As mentioned earlier, it’s common during competitive bidding for a client to receive cost estimates that vary by tens—or even hundreds—of times. For an inexperienced client, this can be disorienting, but in the development market, it’s a typical occurrence.

In fact, many clients would gain valuable insights into the nuances of their project if they had access to the internal evaluation materials of an experienced contractor.

This price variation can be attributed to several factors, ranked by their level of influence:

Competence of the Contractor in the Task at Hand This is the most critical factor. Often, the more competent the specialist, team, or company, the more pessimistic their estimate. Understanding a contractor’s competence is a broad topic that I may cover in another article. In short, people tend to oversimplify tasks they’re unfamiliar with. For example, renting out an apartment on a daily basis might seem as easy as posting an ad and collecting payments. Similarly, setting up a mining operation might seem as simple as assembling a shed full of computers. However, as you delve into the details, you’ll find that they change everything. A similar effect occurs when incompetent specialists evaluate projects: tasks appear much simpler than they actually are.
Technological Solutions and Work Methodology This is what clients typically aim to assess by comparing different proposals. In an ideal world, project costs would vary only based on the chosen technology stack and methodology. However, in the real world, there are numerous ways to build a system to meet the same requirements. These approaches cannot always be linearly compared. Each technology stack has its strengths, such as development speed, system reliability, availability of specialists, maintenance costs, and more. The same applies to process organization within a contractor’s team, although there are fewer options. These can range from:
- Highly bureaucratic approaches: Characterized by slow development speeds and high costs but less dependence on human factors.
- Chaotic or self-organized methods: In which no one is explicitly accountable, and task prioritization may be unclear. However, these teams can deliver remarkably fast results at lower costs and acceptable quality. Such organizations are fragile, and the departure of even one specialist can jeopardize the project.
Current Project Load of the Contractor It’s one thing when a contractor’s resources are fully booked for a year, and another when employees are sitting idle. As previously discussed, idle resources may lead to more competitive pricing. At the other extreme, a contractor uninterested in your project may quote a “take it or leave it” price. They might also provide such a quote if they have significant doubts about the client’s adequacy, solvency, or legal standing.
Negotiation Tactics Experienced contractors are well aware of the wide variation in estimates for the same project. They understand that most clients will start by considering the cheapest offers while dismissing outliers. This leads to strategic pricing games: quoting a realistic estimate may mean not being considered at all, while quoting a much lower price to engage the client often results in significantly higher costs later during contract negotiations. This chapter focuses on this manipulative scenario.

When Contractors Manipulate Costs to Win the Project

This scenario occurs when a competent contractor provides a realistic estimate but drastically undercuts it to initiate contact with the client. They know that, one way or another, they will eventually recover the initially calculated cost—or more.

The goal of such a contractor is to establish contact, demonstrate their competence, and eventually negotiate a contract at the originally calculated price. Less scrupulous contractors may sign a contract with the intention of extracting “their” money during the project’s execution. Development contracts often leave room for interpretation, and many aspects are difficult to formalize, as clients often don’t fully know what they want at the evaluation stage. Unscrupulous contractors exploit these vulnerabilities.

Warning Signs of Manipulative Contractors:

Agreeing to any of your terms without hesitation.
Adjusting the price during discussions to match any figure you want to hear.
Minimal pretense of carefully considering conditions.

Their plan is to recover their costs during the project’s implementation.

How to Respond to Manipulative Contractors

If You Haven’t Signed a Contract Yet The best course of action is to disengage immediately. Manipulative pricing is not just a red flag for the cost but also a warning about how the contractor will treat the client throughout the partnership. This behavior indicates a lack of respect and trustworthiness. You don’t need to explain your true reasons; a standard response like “we’ve chosen a more experienced contractor for our needs” will suffice. Save your energy and move on to another proposal.
If You’ve Already Signed a Contract Unfortunately, the situation becomes much more complicated. You’ll likely learn of the bad news when it’s too late to back out, switch contractors, or cancel the project. Worse, as the person responsible for the project in your company, you’ll bear the blame for any failure. After all, you were the one who selected or recommended the contractor. This places you in a hostage situation. Here are your options:
- Accept the contractor’s terms: This is, unfortunately, a common choice. The project then proceeds in a way that serves the contractor’s interests rather than those of your company. The contractor may unilaterally change project goals, requirements, approaches, timelines, and costs—staying just within reasonable limits to avoid legal repercussions. Alarmingly, project leads often fail to recognize that they are working against their company’s interests. This explains why so many large-scale development projects ultimately fail.
- Seek help from leadership and advisors: The ethical option is to explain the situation to your leadership and work together to minimize losses. This often involves bringing in lawyers, consultants, or other specialists to manage the fallout. The primary risk is that the project may be deemed unsuccessful, and the blame will fall on you. Whether this results in further consequences depends on your company’s internal climate, management style, and the specific circumstances.

A Word to Manipulative Contractors

To contractors who deliberately mislead clients: be aware that there are organizations that won’t hesitate to hold you accountable, even outside legal frameworks. This accountability might not target your organization as a whole but rather you personally, along with your leadership, for failing to meet your stated terms. You may think you’re exploiting inexperienced startup teams, but those “naive” clients may have backers for whom such deception is intolerable. The consequences will be unpleasant—primarily for you.

The Contractor Failed to Protect Their Interests

After reviewing various proposals, you select the most appealing one. The price seems reasonable, but as a conscientious employee advocating for your company’s interests, you decide to attempt negotiating a lower cost. After all, you’re aware that contractors often include a margin for negotiation in their initial quotes.

During discussions, you present compelling arguments for why the price is too high—for example, citing competing offers, referencing strict budget constraints, or other reasons. Preparing for resistance, you propose a significantly lower price, perhaps half of the original estimate, but instead of negotiating, the contractor simply agrees. An experienced negotiator will likely recognize this scenario as a sign of inexperienced counterparts. A lack of negotiation skills often indicates broader inexperience in the contractor’s operations.

So, what could go wrong when you successfully push an inexperienced contractor into accepting half of their original price?

When Inexperience Leads to Unrealistic Estimates

As mentioned earlier, inexperienced specialists often underestimate the complexity of tasks, believing them to be simpler than they are. Most likely, the contractor’s initial estimate was already underpriced, which may have been what attracted your attention in the first place. By drastically reducing this already low estimate, you guarantee that the contractor will be unable to complete the project within the agreed budget. The contractor may not even consider this possibility, relying instead on overly optimistic, almost fantastical scenarios. Unfortunately, this is common among novices.

Let’s explore what might happen when the money runs out midway through the project, even if the contractor initially appears to be progressing well. Imagine a scenario where the project is halfway done, and things seem “almost complete,” but the funds are exhausted.

Possible Outcomes When the Budget Runs Out

The Contractor Covers the Deficit The contractor might attempt to fund the remaining work themselves. This approach is sometimes seen when a development team operates within a larger organization with an unrelated core business. In such cases, the parent company may step in to preserve its reputation, even if it incurs a loss. However, these companies typically have experienced negotiators who wouldn’t have allowed such a significant concession in the first place. When this happens, it’s often due to an initially flawed estimate rather than unexpected negotiation outcomes.
The Team Works at a Loss If the contractor is a closely-knit team of developers with complementary skills, they might work at a significant loss to complete the project. Such cases are rare but do happen, and they often lead to the formation of exceptionally strong and reliable teams. However, these teams usually avoid similar situations in the future.
The Contractor Requests Additional Funds The contractor may look for reasons to justify additional payments. Technical specifications often allow for broad interpretations, and clients rarely have a clear vision of their exact requirements. This creates opportunities for renegotiation. If you manage to allocate additional funds, this can be a viable solution. However, in many large organizations, accessing extra funding requires navigating multiple committees over several months. By that time, a small contractor may no longer be operational.
The Contractor Avoids Their Obligations A common scenario involves the contractor’s leadership and team disappearing entirely—phone calls go unanswered, emails are ignored, and communication ceases. While you can initiate formal legal proceedings based on contractual obligations, the project is effectively abandoned. Relationships with the current contractor are likely irreparably damaged, and transitioning the project to another team midway is nearly impossible, especially since the original team was inexperienced. Remember, it was you who selected this contractor.

What to Do in This Situation?

You can’t simply tell the contractor that they shouldn’t have agreed to such a steep price cut and ask them to reconsider. Here’s how to navigate this situation:

Acknowledge That You’re Working with an Inexperienced Team This isn’t necessarily a bad thing—it can sometimes even be beneficial—but you must understand the associated risks. We’ll discuss these risks in more detail another time.
Ensure the Contractor Understands the Project Costs Verify that the contractor has a realistic understanding of the project’s cost and only agreed to your terms under pressure. You can do this by digging into the cost structure and asking detailed questions. Don’t hesitate to ask “obvious” questions to piece together the entire process—from the moment the team starts drafting requirements to delivering a system ready for support. Who will design the interface? Who will program the server, design the database, test the system, support users at launch, write documentation, and oversee progress? Demand a cost breakdown not only by specialization but also by system requirements—for example, the time required to develop an authentication module, integrate with SAP PI, or implement compliance with data protection regulations. Assessing whether the contractor has considered these details doesn’t require special qualifications—just time and effort on your part.By asking these questions, you can prompt the contractor to reevaluate their estimate, increasing their chances of avoiding financial losses.
Give the Contractor a Chance to Protect Their Interests If the contractor understands the project’s cost, conceded under pressure, and you still plan to work with them, allow them to restore the project’s original price. Once the contractor realizes the situation, they will likely attempt to return the price to its initial level. At this point, the power dynamics shift in your favor. If they don’t take the initiative, you can explicitly address discrepancies in the cost calculation and final price, signaling that you’re aware of the situation but are willing to ensure the contractor’s interests are met for the project’s success. In this scenario, you gain moral leverage to request detailed cost structures, including the contractor’s profit margin. Extending such goodwill can lay the foundation for a strong partnership.

While this approach is rare, examples do exist. This article was inspired by a desire to convey this specific point. I often see clients who sincerely believe they’re acting in the project’s best interest by finding one of the cheapest proposals and negotiating it even lower, often from a position of strength. However, in most cases, this approach leads directly to failure. If a contractor accepts such steep discounts, something is amiss. Identify the underlying issue before celebrating your negotiation success.

Other Scenarios

Occasionally, estimates are drastically revised due to genuine mistakes, which are explained to the client with apologies and a restoration of the original proposal.

I also frequently encounter cases where contractors with near-ready systems that closely match client requirements significantly inflate initial estimates. These contractors have a buffer for substantial price reductions but often choose not to use it. Why give up the opportunity to earn more when they’re clearly more competent, and their development costs are still lower than competitors who must build from scratch? Even if the client opts for inexperienced contractors, they often return, better prepared and more receptive to realistic terms if their interest persists.

There’s a good chance I’ve overlooked some obvious scenarios, and a smaller chance I haven’t encountered others. I’d appreciate it if you’d share your experiences.

Originally published: You Pressured a Contractor on Price: Consequences — Alex Rezvov's Blog

Founder Mode — A New Name for Micromanagement?

Alex Rezvov — Thu, 09 Apr 2026 08:08:53 +0000

Founder mode is a trendy term that describes an approach where the founder remains deeply involved in the company’s management at every stage, even as it scales. The concept gained traction after a popular article by Paul Graham:
https://paulgraham.com/foundermode.html

At first glance, founder mode appears to be a way to maintain strategic control. But could it actually be an updated name for an old practice—micromanagement?

Is Founder Mode Just Micromanagement Rebranded?

On the surface, founder mode looks like a new approach to process control. The founder stays “in the game,” retaining authority over key decisions as the company grows. But does this approach essentially legalize micromanagement under a trendier name?

Why It’s Not Micromanagement

Proponents argue that founder mode isn’t about controlling every step. Instead, it focuses on strategic adjustments and safeguarding the company’s vision. The founder intervenes only when decisions are critical to the company’s direction, allowing the team to handle the rest.

Why It Could Be Micromanagement in Disguise

In practice, founder mode can become a convenient excuse for those unwilling to delegate or relinquish control. Under the guise of “strategic vision,” founders might micromanage processes, creating the same pitfalls as traditional micromanagement—just dressed up with a new label.

FounderMode #Micromanagement #Startup #TeamManagement #StartupCulture

Originally published: Founder Mode — A New Name for Micromanagement? — Alex Rezvov's Blog

Resolving Architectural Conflicts in Development Teams

Alex Rezvov — Wed, 08 Apr 2026 07:55:19 +0000

Not every conflict is inherently bad. If architectural viewpoints clash without causing negative business consequences, it can even be beneficial. Diverse opinions and healthy competition encourage developers and architects to engage more deeply and consider various aspects of the architecture.

When to Take Action?

Action is necessary if a conflict starts affecting the business. For example:

Development is stalled due to a lack of agreed architecture.
Inconsistent architectural decisions appear in different parts of the system because specialists failed to reach an agreement.
A personal conflict arises between team members due to disagreements over architecture.
Other similar situations that hinder progress.

If the Conflict Stays Professional

In professional disputes, it's important to clearly define the roles and responsibilities of each participant. Often, a discussion highlighting that the chosen solution involves full accountability for its effectiveness helps participants approach the problem more comprehensively and objectively.

Architectural disputes cannot rely on democratic voting — someone must take the final decision and bear responsibility for it. This role could be:

An informal leader;
A designated architect;
A team lead, tech lead, or CTO.

The key is that this person must listen to other specialists' opinions. Leaders should foster an environment where all ideas and arguments can be discussed openly.

Architectural Committee: A Solution for Larger Teams

If resources allow, creating an architectural committee is an excellent idea. This body:

Regularly discusses architectural challenges;
Consists of specialists with the highest expertise in various aspects of the product;
Can include external consultants for an unbiased perspective.

This practice has proven to be effective: employees appreciate the opportunity to discuss complex topics with professionals, and the resulting decisions are of high quality.

If the Conflict Turns Personal

If the conflict escalates into a personal issue, it must be addressed first. Potential steps include:

Facilitate a direct conversation. If both parties are willing to engage in an open dialogue, this is often the best way to resolve the issue.
If dialogue isn't possible, analyze the situation further:
- Motivate the participants to resolve their differences, if the project's circumstances allow for it.
- If motivation fails, separate the individuals: assign them to different tasks, teams, or projects.
- In extreme cases — part ways with one of the individuals.

From my 18 years of experience, deep personal conflicts rarely resolve on their own. They tend to escalate over time, having a destructive impact on the team and ultimately harming the company as a whole.

Originally published: Resolving Architectural Conflicts in Development Teams — Alex Rezvov's Blog