The post has been translated automatically. Original language: Russian
Every couple of years, any growing company asks the same question: to stay on cloud CRM or to raise an open-source solution on its server. Usually, the dispute quickly slides down to the subscription price — and this is the worst possible criterion. A subscription is almost never a major expense item.
Below is an analysis of the results of the implementation of self—hosted CRM in companies from the financial sector: what you really get, what you really lose, and by what signs you understand that you don't need it.
Why are they even looking towards their server?
Three honest reasons that I've heard and tested for myself.
Data. If you work with financial information of clients, personal data or documents of counterparties, the question "where is the base physically located" ceases to be theoretical. The requirements for storing data on the territory of the country are not the paranoia of security guards, but a line in the contract with a corporate client or in the requirements of the regulator.
A non-standard process. Cloud CRM works great as long as your process is similar to a sales funnel: lead, qualification, transaction, payment. If you have scoring, counterparty verification, a package of documents for signature and parallel approval with a third party in the middle, you start bending the system for yourself. And at some point you hit the ceiling of customization, behind which there is only the API and external crutches.
The cost is on the horizon. It is necessary to consider not "how much a subscription costs now", but "how much it will cost when there are three times more users, and at what tariff the functions we need will be available." Often, the necessary little things — like shared access to integration credentials — are on a tariff several times more expensive than the current one.
What do you get
Full control over the data model: your own objects, your fields, your relationships, without restrictions on the number of custom entities.
Direct access to the database. Any report, any upload, any integration — without API quotas.
The absence of a vendor lock. Your base is your base.
Cost predictability. The cost of the server is growing slowly and understandably.
What do you have to lose, and it's more expensive than it looks
Ready-made local integrations. This is the main surprise. Cloud-based CRMs, which are popular in the region, come with ready-made connectors to local services: messenger providers, telephony, bank statements, EDI, cash registers. There is none of this in an open-source product developed overseas, and there never will be. You write each such integration yourself — usually through an orchestrator like n8n or Make, but you write it yourself.
The usual modules are out of the box. Mail, calls, tasks, built-in messenger, document templates. Users come from amo or Bitrix and the first thing they ask is, "Where's the mail inside the deal?" The answer "we'll finish it" costs you the trust of the team in the first few weeks.
Updates. Updates in the cloud are someone else's concern. Each version update potentially breaks your improvements, and you need to test them before rolling out.
A person with access to the server. Even if you set up the system, some of the tasks always rest on the level of the container, backups and certificates. If this person is not you, the speed of all changes is equal to the speed of his free time. Plan your architecture so that ninety percent of routine changes are done through the interface, not through the server.
How to count honestly
Replace the question "how much does the subscription cost" with the other four.
How many hours will it take to integrate, which is not out of the box? List by name: messengers, telephony, website, documents, accounting. Multiply by the cost of the hour of the person who will do it.
Who will support this in a year? If the answer is "the same one person", you are building a system with a single point of failure in the form of a live employee.
How much is your process really non-standard? If the honest answer is "the usual sales funnel," you're buying yourself a job with no benefit.
What happens to the data if the project stalls? The cloud has an export. Your server should have a backup schedule, not the intention to set them up someday.
The hybrid that everything usually comes to
In practice, the working configuration looks like this: a self-hosted CRM as a core with data and an interface for the team, plus a separate orchestrator for all integration logic. All communications with the outside world — website, messengers, mail, notifications — live in the orchestrator, not inside the CRM.
This provides two important things. Firstly, updating CRM does not break integrations because they are outside. Secondly, if after a year you decide that self-hosted was a mistake, you change the core, rather than rewrite the entire automation.
A simple criterion
Self-hosted is justified if at least one condition is met.
You have strict data storage requirements that the cloud does not cover.
Your business process does not fit into the funnel and has already reached the customization ceiling.
There is a person in the team for whom supporting this system is part of the main job, not a weekend feat.
If none of them are fulfilled, take the cloud and spend the remaining weeks on the product. Infrastructure is rarely a competitive advantage of a startup.
It is interesting to hear the experience of other participants: who moved from cloud CRM to their solution and, most importantly, who returned back? The second scenario is discussed much less frequently, although it usually has more conclusions.
Раз в пару лет любая растущая компания задаёт один и тот же вопрос: остаться на облачной CRM или поднять open-source решение на своём сервере. Обычно спор быстро скатывается к цене подписки — и это худший из возможных критериев. Подписка почти никогда не бывает главной статьёй расходов.
Ниже — разбор по итогам внедрения self-hosted CRM в компании из финансового сектора: что реально получаешь, что реально теряешь и по каким признакам понять, что вам это не нужно.
Почему вообще смотрят в сторону своего сервера
Три честные причины, которые я слышал и проверил на себе.
Данные. Если вы работаете с финансовой информацией клиентов, персональными данными или документами контрагентов, вопрос «где физически лежит база» перестаёт быть теоретическим. Требования к хранению данных на территории страны — это не паранойя безопасников, а строка в договоре с корпоративным клиентом или в требованиях регулятора.
Нестандартный процесс. Облачные CRM отлично работают, пока ваш процесс похож на воронку продаж: лид, квалификация, сделка, оплата. Если у вас в середине сидит скоринг, проверка контрагента, пакет документов на подпись и параллельное согласование с третьей стороной — вы начинаете гнуть систему под себя. И в какой-то момент упираетесь в потолок кастомизации, за которым только API и внешние костыли.
Стоимость на горизонте. Считать надо не «сколько стоит подписка сейчас», а «сколько она будет стоить, когда пользователей станет втрое больше, и на каком тарифе окажутся нужные нам функции». Часто нужная мелочь — вроде общего доступа к учётным данным интеграции — лежит на тарифе в несколько раз дороже текущего.
Что вы получаете
Полный контроль над моделью данных: свои объекты, свои поля, свои связи, без ограничений по количеству кастомных сущностей.
Прямой доступ к базе. Любой отчёт, любая выгрузка, любая интеграция — без квот на API.
Отсутствие вендор-лока. Ваша база — это ваша база.
Предсказуемость расходов. Стоимость сервера растёт медленно и понятно.
Что вы теряете, и это дороже, чем кажется
Готовые локальные интеграции. Это главный сюрприз. Облачные CRM, популярные в регионе, приходят с готовыми коннекторами к местным сервисам: мессенджер-провайдеры, телефония, банковские выписки, ЭДО, кассы. В open-source продукте, разработанном за океаном, ничего этого нет и не будет. Каждую такую интеграцию вы пишете сами — обычно через оркестратор вроде n8n или Make, но пишете сами.
Привычные модули из коробки. Почта, звонки, задачи, встроенный мессенджер, шаблоны документов. Пользователи приходят из амо или Битрикса и первым делом спрашивают: «а где почта внутри сделки?». Ответ «мы это допилим» стоит вам доверия команды в первые же недели.
Обновления. В облаке апдейты — чужая забота. У себя каждое обновление версии потенциально ломает ваши доработки, и нужно тестировать перед накатом.
Человек с доступом к серверу. Даже если систему настраиваете вы, часть задач всегда упирается в уровень контейнера, бэкапов и сертификатов. Если этот человек не вы, скорость всех изменений равна скорости его свободного времени. Планируйте архитектуру так, чтобы девяносто процентов рутинных изменений делалось через интерфейс, а не через сервер.
Как считать по-честному
Замените вопрос «сколько стоит подписка» на четыре других.
Сколько часов уйдёт на интеграции, которых нет из коробки? Перечислите поимённо: мессенджеры, телефония, сайт, документы, бухгалтерия. Умножьте на стоимость часа человека, который это сделает.
Кто будет поддерживать это через год? Если ответ «тот же один человек» — вы строите систему с единой точкой отказа в виде живого сотрудника.
Насколько ваш процесс действительно нестандартный? Если честный ответ «обычная воронка продаж» — вы покупаете себе работу без выгоды.
Что произойдёт с данными, если проект заглохнет? У облака есть экспорт. У вашего сервера должен быть регламент бэкапов, а не намерение их когда-нибудь настроить.
Гибрид, к которому обычно всё приходит
На практике рабочая конфигурация выглядит так: self-hosted CRM как ядро с данными и интерфейсом для команды, плюс отдельный оркестратор для всей интеграционной логики. Все связи с внешним миром — сайт, мессенджеры, почта, уведомления — живут в оркестраторе, а не внутри CRM.
Это даёт две важные вещи. Во-первых, обновление CRM не ломает интеграции, потому что они снаружи. Во-вторых, если через год вы решите, что self-hosted был ошибкой, вы меняете ядро, а не переписываете всю автоматизацию заново.
Простой критерий
Self-hosted оправдан, если выполняется хотя бы одно условие.
У вас есть жёсткие требования к хранению данных, которые облако не закрывает.
Ваш бизнес-процесс не укладывается в воронку и уже упёрся в потолок кастомизации.
В команде есть человек, для которого поддержка этой системы — часть основной работы, а не подвиг по выходным.
Если ни одно не выполняется — берите облако и потратьте освободившиеся недели на продукт. Инфраструктура редко бывает конкурентным преимуществом стартапа.
Интересно услышать опыт других участников: кто переезжал с облачной CRM на своё решение и, главное, кто возвращался обратно? Второй сценарий обсуждают гораздо реже, хотя выводов в нём обычно больше.
Share
