SaaS или своё для офиса 50 РМ: фреймворк ITfresh и три кейса

За последний год к нам в ITfresh обратились сразу трое клиентов с одним и тем же, казалось бы, вопросом: «Что лучше — писать своё приложение или всё-таки подписаться на SaaS?» Это были Медклиника 25 РМ из ЦАО, юрфирма 38 РМ из Сокольников и торговая компания 28 РМ из Подольска. Сначала задача казалась одинаковой, но копнув глубже, мы поняли, что ответы для них будут совершенно разные. В этой статье я поделюсь нашим рабочим фреймворком для выбора, расскажу о 5 факторах оценки, покажу расчёты ROI на 3 года по каждому из этих кейсов с конкретными цифрами. А ещё вас ждёт история клиента, который пошёл против нашего фреймворка, выбрал custom — и в итоге потерял целых два года развития.

Почему «писать своё» — это самый дорогой соблазн для МСБ

Знаете, я вижу эту картину снова и снова, каждые 3-4 месяца. Приходит ко мне владелец малого бизнеса, только что с конференции. Там какой-то спикер вдохновенно рассказывал, как он «написал своё приложение и стал зарабатывать в 10 раз больше». На следующей же неделе этот владелец зовёт нас и с горящими глазами говорит: «Давайте и нам сделаем своё приложение, вот прямо для нашего бизнеса!» Обычно, после 5-6 встреч, выясняется одна простая вещь: то, что он так хочет, уже давно существует в виде готового SaaS-продукта, который стоит всего 30 тысяч ₽ в месяц и запускается за неделю. А вот custom-разработка, если бы мы за неё взялись, обошлась бы в 4-7 миллионов ₽ и заняла бы 9-14 месяцев.

По моему личному опыту работы с малым бизнесом в Москве, создавать что-то custom имеет смысл всего в четырёх случаях. Первый — это когда у вас действительно уникальный бизнес-процесс, которого реально нет ни в одном готовом продукте. Скажу честно, это большая редкость. Второй — если есть жёсткие регуляторные требования, под которые ни один SaaS просто не сертифицирован. Третий — нужна интеграция между уже существующими системами, и без своего связующего ПО тут никак. И четвёртый, иногда, — это когда масштаб компании настолько велик (от 200 РМ), что лицензии на SaaS начинают превышать стоимость собственной разработки. Во всех остальных ситуациях, поверьте, SaaS будет и дешевле, и быстрее.

Но хочу сразу сказать: я не какой-то ярый идеолог SaaS. В моей практике встречаются кейсы, когда custom — это единственное правильное решение, и порой это даже «удивительно». Один из таких примеров — это юрфирма 38 РМ, для которой мы разрабатывали свою DMS, хотя, казалось бы, можно было купить готовую. Ниже я обязательно расскажу, почему мы так сделали.

5 факторов фреймворка: на что мы смотрим перед выбором

Фактор 1: объём данных

Первое, что я всегда стараюсь прикинуть, это сколько данных будет храниться в системе через 3 года. Я смотрю не на текущий объём, а на то, каким он станет через 3 года с учётом темпов роста клиента. SaaS-продукты, как правило, тарифицируются по объёму — это может быть количество записей, ГБ хранилища или число транзакций. И если объёмы становятся большими, их цена резко летит вверх. С custom-системами, наоборот: чем больше данных, тем, по сути, те же эксплуатационные расходы (только серверная мощность).

Точки перелома, которые я наблюдал:

• До 100 000 записей в основных сущностях — SaaS всегда выгоднее.
• 100 000-1 000 000 — зона серого, считаем отдельно.
• Больше 1 миллиона — обычно custom начинает выигрывать.

Фактор 2: гибкость процесса

А как часто меняется бизнес-процесс, который вы хотите автоматизировать? Если это происходит раз в полгода или ещё реже, то SaaS подходит просто отлично, ведь он развивается в стандартизированном направлении. Но если изменения нужны каждые 1-3 месяца, то SaaS либо вообще не позволит внести часть этих изменений, либо потребует дорогостоящих и медленных доработок через консультанта вендора.

Custom даёт гибкость, но есть одно НО. Он выигрывает в этом только при одном условии: у клиента должен быть постоянный, надёжный канал доступа к разработчику. Если ваш разработчик ушёл в отпуск или, что хуже, сменил работу, то вся эта гибкость моментально превращается в тыкву.

Фактор 3: регуляторные требования

Для МСБ это, как правило, три основных закона: 152-ФЗ (это про персональные данные), 187-ФЗ (про КИИ для определённых отраслей) и 323-ФЗ (для медицины). Если ваш процесс подпадает под действие одного из них, обязательно нужно проверить, есть ли у выбранного SaaS-продукта сертификат соответствия. Если да, то SaaS продолжает быть в игре. Если нет — тогда мы, к сожалению, вынуждены рассматривать custom или локально развёрнутый продукт.

У нашей медклиники 25 РМ ключевым моментом был 152-ФЗ, причём для медицинских данных, а это, между прочим, специальная категория. Из всех готовых МИС только три продукта имели необходимую сертификацию для работы в SaaS-режиме: это МИС МедЭлемент, qMS и Renovatio Mednet. Вот это сразу сузило выбор!

Фактор 4: штатная разработка

Следующий вопрос, который мы задаём: есть ли у клиента свои программисты в штате, или придётся нанимать внешних? Если есть штатные специалисты, то custom в долгую оказывается на 30-50% дешевле (ведь нет наценки агентства). А если нет, то внешняя разработка, конечно, добавляет и стоимости, и рисков.

У компаний из МСБ с 25-50 РМ штатных программистов, как правило, почти никогда не бывает. Это значит, что любая custom-разработка будет делаться через подрядчиков, а это, увы, дорого. Мы обычно говорим клиенту прямо: «У вас нет своей штатной разработки, поэтому всё custom вам придётся покупать с премией в 1.5-2 раза по сравнению с тем, если бы у вас были свои разработчики».

Фактор 5: exit cost

А сколько будет стоить уйти с платформы или, скажем, сменить разработчика? Знаете, это самый недооценённый фактор, я считаю. SaaS обычно позволяет выгрузить ваши данные в стандартных форматах (CSV/JSON/Excel), так что exit cost там небольшой. А вот custom-разработка может обернуться настоящим монстром: никто, кроме изначальной команды, не понимает код, и тогда exit cost равен… переписыванию всего с нуля. А это, на минуточку, 70-100% от изначальной стоимости!

В нашей практике я видел настоящий кошмар: один клиент заказал custom-разработку у фрилансера за 2.5 миллиона ₽. Через год фрилансер куда-то пропал, документации не было вообще, а код — это был один-единственный файл на 14 тысяч строк, без единого комментария! Передачу такого «наследства» другой команде оценили в 1.8 миллиона ₽. В итоге клиент просто решил написать всё с нуля у нас — и это обошлось в 3.2 миллиона ₽. Представляете? Всего 7.5 миллиона на одну функцию, которая спокойно существовала в SaaS за 25 тысяч ₽/мес.

Кейс №1: медклиника 25 РМ — SaaS МИС vs custom

В сентябре 2025 года к нам обратилась многопрофильная медклиника из ЦАО Москвы, у них 25 рабочих мест (это врачи, медсёстры, регистратура, админы). Их старый МИС был написан 12 лет назад бывшим IT-сотрудником, который ушёл и не оставил никакой документации. Они стояли перед выбором: либо полностью переписывать систему, либо купить готовый SaaS.

Что мы посчитали

Мы предложили вариант SaaS: МИС МедЭлемент Pro, тариф «Клиника» для 25 пользователей. Стоимость: 89 тысяч ₽/мес. А вот внедрение под ключ, куда входили миграция данных, обучение персонала, кастомизация справочников, обошлось бы в 540 тысяч ₽ единоразово.

Что касается варианта custom, мы предложили построить свою МИС на базе фреймворка. Подрядчиком выступала бы наша команда инженеров плюс привлечённый медицинский консультант. Стоимость такого решения: 3.2 млн ₽ единоразово, плюс ежемесячная поддержка в 95 тысяч ₽ (это зарплата двух инженеров с 30% занятости каждого).

Расчёт на 3 года:

# Кейс №1 — медклиника 25 РМ, расчёт ROI на 36 месяцев

# Вариант SaaS МедЭлемент:
#   Внедрение:        540 000 ₽
#   Лицензии:    89 000 × 36 = 3 204 000 ₽
#   Обновления:       включены
#   Серверная мощность: 0 (облако)
#   Итого 3 года:   3 744 000 ₽

# Вариант custom (наша разработка):
#   Разработка:    3 200 000 ₽
#   Поддержка:   95 000 × 36 = 3 420 000 ₽
#   Серверная мощность: 18 000 × 36 = 648 000 ₽
#   Доработки в год (15% от разработки): 480 000 × 3 = 1 440 000 ₽
#   Итого 3 года:   8 708 000 ₽

# РАЗНИЦА: custom дороже на 4 964 000 ₽
# По фактору 3 (регуляторика): МедЭлемент сертифицирован на 152-ФЗ
# По фактору 4 (своя разработка): у клиента нет штатных программистов
# По фактору 5 (exit cost): из МедЭлемента можно выгрузить пациентов в HL7

# РЕШЕНИЕ: SaaS

Клиника выбрала SaaS. Через 9 месяцев после внедрения они увеличились до 32 РМ — стоимость лицензий подросла, но не критично. На текущий момент они работают полтора года без серьёзных инцидентов, наша поддержка занимает 3-5 часов в месяц на интеграционные вопросы (синхронизация с лабораторией Гемотест, отправка СМС-напоминаний).

Кейс №2: юрфирма 38 РМ — SaaS DMS vs custom

В декабре 2025 года к нам пришла международная юрфирма из Сокольников, у них 38 РМ. Их специфика заключалась в следующем: каждое дело — это огромный пакет, от 40 до 200 документов самой разной природы. Там и контракты, и переписка, и экспертизы, и судебные акты, и корреспонденция с другими юрфирмами. И всё это нужно было привязывать по версиям, статусам подписания, тегам конфиденциальности, а также распределять доступы по группам сотрудников.

Почему здесь custom оказался выгоднее

На рынке SaaS DMS (Document Management System) есть очень достойные продукты, например, M-Files, DocuWare или российский Directum RX. Все они отлично справляются с общим документооборотом, но у нашей юрфирмы, как я уже говорил, были свои, очень специфичные требования:

• Глубокая интеграция с их собственным реестром дел (написан 8 лет назад, переписать невозможно).
• Доступы по «китайским стенам» — конфликты интересов между делами, юрист, ведущий дело А, не должен видеть документы дела Б, если стороны связаны.
• Поиск по содержимому документов на 5 языках с учётом юридической терминологии.
• Шифрование документов при хранении ключами, которые держатся у клиента.
• Аудит-лог в формате, совместимом с их требованиями к комплаенсу.

Мы, конечно, попытались собрать решение из готовых компонентов. В итоге, чтобы закрыть все их потребности, получилось 3 разных SaaS плюс довольно сложный интеграционный слой. Вот сравнение на 3 года:

# Кейс №2 — юрфирма 38 РМ, расчёт ROI на 36 месяцев

# Вариант SaaS-комбо (M-Files Cloud + Elasticsearch SaaS + Vault):
#   Внедрение и интеграция:       950 000 ₽
#   M-Files на 38 юзеров:    156 000 × 36 = 5 616 000 ₽
#   Elasticsearch (Elastic Cloud Standard): 38 000 × 36 = 1 368 000 ₽
#   Кастомные доработки (год):      280 000 × 3 = 840 000 ₽
#   Итого 3 года:            8 774 000 ₽

# Вариант custom (наша разработка на Symfony + Postgres + OnlyOffice):
#   Разработка с нуля:        2 800 000 ₽
#   Поддержка:           45 000 × 36 = 1 620 000 ₽
#   Серверная инфраструктура:    22 000 × 36 = 792 000 ₽
#   Доработки в год (10% от разработки): 280 000 × 3 = 840 000 ₽
#   Итого 3 года:            6 052 000 ₽

# РАЗНИЦА: custom дешевле на 2 722 000 ₽
# По фактору 2 (гибкость): требования меняются по каждому делу, нужна гибкость
# По фактору 3 (регуляторика): «китайские стены» — это правовое требование,
#   которое ни один готовый продукт не закрывает без серьёзной доработки
# По фактору 5 (exit cost): код наш, документация по архитектуре,
#   возможность передать в другую команду через 24-36 месяцев

# РЕШЕНИЕ: custom

Юрфирма выбрала custom. Мы запустили проект в январе 2026-го, MVP на 4 месяца, полный релиз — к концу августа. Сейчас стадия активной разработки, два senior-разработчика и я в роли архитектора, плюс юрист клиента как product owner. По плану — окупаемость на 28-м месяце.

Кейс №3: торговля 28 РМ — SaaS WMS vs custom

В январе 2026 года к нам обратилась торговая компания из Подольска, у них 28 РМ. Они занимаются оптовой и розничной продажей электротехники, у них склад площадью 580 м², ассортимент из 4200 SKU, и на складе работают два человека. Текущий учёт они ведут в 1С Управление торговлей 11.5, но есть проблема: 1С УТ, к сожалению, не очень хорошо подходит для складских операций. Например, там нет поддержки терминалов сбора данных, нет адресного хранения, и планировать инвентаризации тоже проблематично.

Почему SaaS WMS выиграл

На российском рынке есть несколько хороших SaaS-WMS: это Cleverence, MyWarehouse, Yandex WMS, 1С-WMS. Мы внимательно присмотрелись к Cleverence — он прекрасно интегрируется с их 1С УТ через типовые обмены, поддерживает терминалы Honeywell EDA51 (а у клиента как раз два таких!), и что важно, позволяет организовать адресное хранение.

В этом случае custom-разработка, честно говоря, просто бессмысленна. Рынок стандартных WMS уже давно зрелый, обновления безопасности приходят регулярно, а поддержка терминалов разных производителей изначально включена в продукт.

# Кейс №3 — торговля 28 РМ, расчёт ROI на 36 месяцев

# Вариант SaaS Cleverence Магазин 15:
#   Внедрение и настройка:        320 000 ₽
#   Лицензии (5 терминалов):  45 000 × 36 = 1 620 000 ₽
#   Поддержка ITfresh:        12 000 × 36 = 432 000 ₽
#   Терминалы Honeywell EDA51 (доп.3 шт): 285 000 ₽
#   Доработки интеграции:         85 000 × 3 = 255 000 ₽
#   Итого 3 года:              2 912 000 ₽

# Вариант custom (мобильное приложение + бэкенд):
#   Разработка с нуля:         2 800 000 ₽
#   Поддержка:           38 000 × 36 = 1 368 000 ₽
#   Серверная инфраструктура:    14 000 × 36 = 504 000 ₽
#   Доработки/расширения:       180 000 × 3 = 540 000 ₽
#   Терминалы (свои + базовый софт): 285 000 ₽
#   Итого 3 года:               5 497 000 ₽

# РАЗНИЦА: SaaS дешевле на 2 585 000 ₽
# По фактору 1 (объём): 4200 SKU — рынок стандартных WMS отлично закрывает
# По фактору 3 (регуляторика): нет специфики
# По фактору 4 (своя разработка): нет штатных программистов
# По фактору 5 (exit cost): из Cleverence стандартный экспорт остатков в Excel

# РЕШЕНИЕ: SaaS

Торговля выбрала Cleverence. Запустили за 5 недель, прошлый месяц закрыли с инвентаризационными расхождениями менее 0.4% (у них исторически было 2-3%).

Наша матрица принятия решения

Опираясь на эти 5 факторов, мы у себя в ITfresh разработали специальную матрицу. Когда к нам приходит новый клиент с вопросом «своё или SaaS», мы за 30-60 минут прогоняем его задачу через эту матрицу. И в большинстве случаев, представляете, ответ получаем прямо во время первого разговора.

Если на 2+ факторах есть «зелёный» в сторону SaaS

То есть, если у вас данных до 100К записей, процессы стабильны, все регуляторные требования закрываются готовыми сертификациями, нет своей штатной разработки, и exit cost довольно низкий — в этом случае мы однозначно рекомендуем SaaS. И, конечно, готовим клиенту подробную сравнительную смету с конкретными продуктами, доступными на рынке.

Если на 2+ факторах есть «красный» от SaaS

То есть: уникальный процесс, не покрытый готовыми продуктами; регуляторика, под которую нет сертифицированного SaaS; собственная команда программистов; необходимость нестандартной интеграции. В этом случае мы предлагаем custom и составляем технико-экономическое обоснование на 3 года.

Если факторы перемешаны

А вот это, пожалуй, самый интересный случай! В таких ситуациях мы предлагаем гибридное решение: основной функционал — на SaaS, а специфические доработки делаем как микросервисы на собственном коде. Конечно, такое решение требует участия опытного архитектора, который всё это грамотно соберёт. Зато в долгую оно даёт лучший ROI и максимальную гибкость.

Один кейс провала: клиент выбрал custom вопреки фреймворку

В 2024 году к нам обратился клиент — это торговля стройматериалами, 41 РМ из Подмосковья. Мы прогнали их запрос через наш фреймворк и получили чёткий ответ: «Однозначно SaaS — 1С УТ + Cleverence + AmoCRM». Мы подготовили смету на 3 года: 2.7 миллиона ₽ за SaaS против 6.8 миллиона за custom. Клиент, конечно, послушал нас, ушёл подумать. А через 3 недели вернулся и огорошил: «Мы решили писать своё приложение через нашего знакомого программиста за 4.5 миллиона».

Мы, конечно, предупредили: один программист, отсутствие команды, отсутствие документации — это серьёзные риски. Но клиент ответил: «Я доверяю человеку, мы с ним 12 лет знакомы». Что ж, ОК, ваше решение, ваши деньги.

Через 14 месяцев случилось то, о чём мы предупреждали: программист уволился (нашёл работу в банке с зарплатой 380 тыс ₽/мес). Передачи кода не было, а вся документация уместилась на бумажке в трёх абзацах. Клиент пришёл к нам со словами «спасите». Мы посмотрели: да, спасти можно, но это будет стоить 2.4 миллиона ₽ (за передачу кода нашей команде и доработку недостающего функционала). В итоге клиент всё же выбрал переехать на 1С УТ + Cleverence — то самое решение, которое мы предлагали изначально, — и заплатил за это 2.5 миллиона.

Давайте подсчитаем потери клиента: 4.5 миллиона, потраченные на программиста, плюс 2.5 миллиона на миграцию, плюс 14 месяцев упущенного развития. В сумме получилось 7 миллионов ₽. И всё это для того, чтобы в итоге прийти к решению, которое мы предлагали с самого начала за 2.7 миллиона! Это не упрёк клиенту, вовсе нет. Это просто яркая иллюстрация того, как работает подход «доверяю человеку» вместо чёткого фреймворка.

FAQ: что чаще всего спрашивают клиенты

С какого размера компании имеет смысл писать своё ПО?

По моему опыту работы с МСБ в Москве, реальный порог для custom-разработки появляется, когда у вас 30+ РМ и одновременно есть какой-то уникальный бизнес-процесс, которого действительно нет в массовых SaaS-решениях. Если процессы стандартные, то даже для 100 РМ SaaS будет и дешевле, и быстрее. А если процессы уникальные, то custom может окупиться уже на 25 РМ. Я лично наблюдал обе эти крайности у своих клиентов.

Какой ROI считается приемлемым для custom-разработки?

Я не очень люблю рассуждать про «приемлемый ROI» в целом — это, на мой взгляд, слишком абстрактно. Я считаю немного по-другому: если custom-разработка окупается за 18-24 месяца и при этом помогает снизить операционные риски, тогда она имеет смысл. Если же срок окупаемости превышает 36 месяцев, то это почти всегда, как я вижу, попытка написать «своё ПО» вместо того, чтобы использовать стандартное. В таких случаях я активно отговариваю клиентов. Самый частый антипаттерн, с которым я сталкиваюсь, — это желание написать свою CRM, когда уже есть AmoCRM или Bitrix за 30 тысяч ₽/мес.

Что обычно недооценивают, выбирая custom-разработку?

Три очень важные вещи. Первая — это поддержка: программисты систему построят, но потом эта штука должна жить 5-10 лет, и каждый год она будет требовать от 18-25% от изначальной стоимости на поддержку и доработки. Вторая — exit cost: если разработчик уйдёт, найти замену под чужой код в 4 раза дороже, чем, например, найти специалиста по 1С или CRM. И третья — обновления безопасности: SaaS обновляется автоматически, а custom-систему вам придётся лично патчить под каждую CVE.

Можно ли совместить SaaS и custom в одной компании?

Не просто можно, а даже нужно! У наших клиентов типичная конфигурация выглядит так: SaaS для стандартных функций (например, CRM, почта, аналитика, HR), а custom-доработки или микросервисы — для уникальных процессов. К примеру, это может быть custom-интерфейс для отдела, который работает с какой-то очень специфичной аудиторией клиента. Связь между ними обычно реализуется через REST API. Главное здесь — не пытаться custom-решением заменить весь стек, это прямой путь к долговой разработке.

Сколько стоит custom-разработка под МСБ в Москве в 2026 году?

В среднем по нашим клиентам, вот какие примерно цены и сроки мы видим: микросервис на 1-2 экрана с одной интеграцией обойдётся в 320-550 тысяч ₽ (это 2-3 месяца работы). Внутренний веб-портал на 5-8 разделов с авторизацией и базой данных будет стоить 1.2-2.1 млн ₽ (займёт 4-6 месяцев). А серьёзная система, включающая мобильное приложение, бэк-офис и несколько интеграций, оценивается в 3.5-7.5 млн ₽ (это 8-14 месяцев). Важно понимать, это цены рынка 2026 года, где ставки разработчиков примерно такие: Junior 80k, Middle 180k, Senior 320k ₽/мес.

Итог

Выбор между «SaaS или custom» для МСБ с 50 РМ — это, знаете ли, совсем не про модные технологии или их красоту. Это, в первую очередь, про деньги, риски и время. Наш фреймворк, основанный на 5 факторах и включающий расчёт ROI на 3 года, позволяет получить результат всего за 30-60 минут разговора. По трём недавним кейсам, которые мы рассматривали: медклиника — тут SaaS экономит 4.96 млн ₽; юрфирма — а здесь custom, наоборот, экономит 2.72 млн ₽; торговая компания — им SaaS сэкономит 2.58 млн ₽. Вырисовывается такое среднее правило: если процесс стандартный — смело берите SaaS; если же он уникальный и связан с регуляторными требованиями — тогда custom может быть лучшим выбором. Гибридное же решение часто оказывается оптимумом для большинства клиентов с 50 РМ.