Есть упоротая упорная логика, которая время от времени всплывает даже у серьезных собственников с серьезными бизнесами. И вот ее смысл: раз айтишный стартап — это про будущее, то и платить за настоящее можно мало. Ну а что? Пообещаем 3–5% будущей компании — и разработка станет дешевле. Проблема только в одном: будущей компании ещё нет. Клиенты в ней — гипотеза. Рынок — предположение. Монетизация — туманная надежда. Но продукт, который должен всё это превратить в реальность, нужен уже сейчас. И его, почему-то, хотят собрать «экономно».
И вот здесь происходит главный сбой мышления: в традиционном бизнесе можно экономить на маркетинге, офисе, даже на мебели — и это не убьёт компанию.Но в айтишном продукт и есть бизнес. Это не дополнение. Это не второстепенная часть. Это фундамент. Основание. Сердце всей модели. И его пытаются собрать «дёшево, быстро и качественно». При этом забывают простую вещь: разработка не состоит из маржи конкретного руководителя разработки. Там нет «запаса», который можно отрезать под красивую сказку. Это архитектура, которая либо выдерживает масштабирование, либо умирает в первый же день. Это тестирование, инфраструктура, интеграции, риски. Это реальный труд, а не волшебство. И когда основу продукта собирают «из говна и палок», результат всегда одинаковый: проект, который трещит по швам ещё до релиза, и бизнес, который потом обвиняет всех вокруг, кроме собственного желания сэкономить на фундаменте, просто пообещав кому-то из разрабов, какие-то преференции будущего, которого может и не наступить.

Хотите серьёзный результат — относитесь к разработке как к основному активу, а не как к расходу, который можно «подрезать». Только так продукт имеет шанс родиться, а не остаться красивой мечтой на слайде.

Есть в бизнесе забавная традиция — чинить продукт до последнего, как старый японский некрокорч из девяностых, который уже дымится, но «ещё же едет». Каждый баг называют «особенностью», каждый костыль — «временным решением», а каждое падение системы — «ну, бывает». И всё это продолжается до тех пор, пока приложение не начинает разваливаться быстрее, чем нервная система у проджекта.

Самое смешное, что почти все компании уверены: ещё чуть-чуть подлатаем — и вот оно, идеальное будущее. Спойлер: нет. Иногда дешевле и быстрее признать очевидное — продукт пора переписывать. И вот как это понять без шаманов и астрологии.

Определить, что продукт пора переписать, достаточно не сложно: он начинает вести себя как сильно уставший организм. Каждое новое изменение ломает три старых — эффект домино в реальном времени. Разработчики смотрят на код с тем же выражением лица, что и врач, когда говорит: «Мы сделали всё, что могли». Простые задачи внезапно превращаются в археологические раскопки, где каждый модуль — как слой древней породы. Никто уже толком не понимает, как всё работает, а интеграции вызывают нервный тик. Если продукт пугает собственную команду — всё, приехали, пора начинать заново.

Латание всегда кажется дешёвым — как починить старую стиралку «ещё один раз». Но в ИТ каждый такой «ещё один раз» превращается в недели багфиксов, срывы сроков и потерянные нервы. Команда вместо развития занимается тушением пожаров, новые функции вырастают в цену мини-проекта, а производительность падает быстрее, чем вера в светлое будущее. В итоге бизнес платит не за продукт, а за попытки удержать на плаву то, что тонет по законам природы. Переписать выходит не только быстрее — это часто единственный здравый путь.

Есть редкие случаи, когда переписывать — ошибка. Если продукт ещё молод и проблемы — от неопытности, а не от архитектуры. Если компания не достигла PMF и сам продукт ещё не ясен — зачем переписывать то, что завтра может не понадобиться. Или если дело вообще не в коде, а в хаосе управления: менять систему бессмысленно, пока процессы живут по принципу «кто первый встал — того и фича». Важно отличать технический долг от организационного. Иногда проблема вовсе не в продукте, а в том, как им распоряжаются.

“Час Х” легко заметить: команда больше чинит старое, чем делает новое. Любой релиз — как операция на сердце: риск высокий, исход непредсказуемый. Разработчики открыто говорят, что код опасен, а менеджеры начинают фразой «только давайте ничего не сломаем». Производительность падает, скорость разработки ползёт, и все мечтают «начать заново». Это не прихоть — это диагноз. Когда страх изменить код превышает страх не менять его вовсе — пора объявлять техническую амнистию и переписывать.

Переписывать — не значит “сломать всё”. Сначала нужен технический аудит: понять, что живо, а что давно мертво. Потом — выделить минимальный набор ключевых модулей и проектировать архитектуру, которая выдержит рост, а не рухнет в первый же пик нагрузки. Параллельная разработка — золотое правило: старый продукт работает, новый собирается рядом. Чёткий план, прозрачный бюджет, разумные сроки и команда, которая понимает, что делает. Так переписывают не ради красоты — а ради того, чтобы бизнесу было на чём стоять.

Продукт можно чинить бесконечно, как старый автомобиль родственника: тарахтит, греется, но «жалко выбросить». Проблема в том, что бизнес — не гараж, и на костылях далеко не уедешь. Если ваш продукт боится нагрузки, а разработчики боятся к нему прикасаться — он не нуждается в ремонте, он нуждается в перерождении. Переписать — не признать поражение, а выбрать скорость, стабильность и будущее. Потому что в ИТ есть одна истина: дёшево починенное всегда выходит дорого.

В прошлую пятницу нам позвонил клиент номер один. Буквально. Самый первый оплаченный счет, и с самый первый подписанный акт. Elgrow в те времена, состояла из меня, ноутбука и количества энтузиазма, за которое сегодня, наверное, штрафуют.
Естественно, на встречу нужно было ехать исключительно мне. И, естественно, вытирая рукавом слёзы ностальгии — всё-таки не каждый день видишь человека, который поверил в тебя, когда у тебя ещё даже сайта не было.
Клиент сразу заявил, что подрядчиков, кроме нас, рассматривать не будет. Причина достойная каменной таблички: их система работает почти 15 лет без внешнего вмешательства. Хотя, если честно, я до сих пор не уверен, что это физически возможно. Мы тогда писали код с настроением: «Лишь бы дожил до релиза». А он, похоже, взял и решил жить вечной жизнью.
Пообщались, обсудили планы, договорились делать снова — и, судя по всему, ещё на 15 лет вперёд. Приятно, конечно, но слегка тревожно: выходит, мы тогда делали лучше, чем понимали сами.

На этой неделе завершились два богических события юридической плоскости. Один из клиентов Miceconnect (да, он не сдох на MVP и продолжает захватывать гостиничный сервис), наконец, согласился начать работу, с которой тянул больше месяца. Почему? Потому что пытался понять, на каком основании авторы ПО владеют своим же ПО. В итоге, никаких значимых изменений договор так и не претерпел, но на подпись генеральному лег. Аминь!

Другой кейс — уже Elgrow. Заказчик третью неделю охотится за багами в договоре, которые благородно сам и создаёт. То цену срежет, то сроки перепутает, то разделы местами поменяет. Мы за это время сделали 90% работ и уже собрали требования ко второму этапу, а договор всё лежит на подписи, как артефакт, к которому страшно прикасаться.

Ничто так не тормозит прогресс, как бюрократия, уверенная, что без нее все превратится в хаос. Да, иногда мы начинаем работать до подписания договора. Риск? Возможно. Клиентоориентированность? Абсолютно.

Неделя выдалась весьма интересной на стартапы..

CoreOps.AI получил $3.5 млн на идею, на которой, честно говоря, должны были заработать ещё лет пять назад: заставить ИИ чинить древние корпоративные системы, которые уже и своих разрабов–то пережили. Авторы обещают научить своего питомца читать легаси-код, находить связи, предлагать миграции и вообще избавить мир от страшного слова “онбординг”. Бизнесу это нравится: дешевле, быстрее, не так больно. Разработчики, правда, пока смотрят с подозрением: если ИИ научится чинить легаси, то кто же будет рассказывать клиентам, что «тут проще переписать всё с нуля»?

Пока одни стартапы учат ИИ лечить древний код, Honeyjar AI решил заняться куда более сложной задачей — лечить корпоративные коммуникации. За $2 млн инвестиций компания собирается автоматизировать PR, упорядочить хаос в соцсетях и, возможно, впервые в истории сделать корпоративные тексты читабельными. Звучит фантастично, но рынок поверил: если разработчики могут делегировать ИИ рутину, почему бы маркетологам не делегировать штампы?

А между тем TechPred-2025 дал редкий по нынешним временам сигнал: хватит бояться, пора снова запускать продукты. Стартапам обещают упрощённые процедуры, новые меры поддержки и программы, налоговые льготы, что очень актуально, вообще-то. Для разработчиков это означает одно: нас ждёт сезон массовых MVP, срочных архитектур и клиентов, которые приходят со словами «хотим всё и сразу, но желательно вчера». Хорошая новость: спрос на настоящую разработку растёт. Плохая: ленивым снова будет тяжело.

Рынок, похоже, просыпается. ИИ лечит старое, автоматизирует новое, а стартапам снова дают разгон. Будем посмотреть!

И в продолжение истории...

По плану разработка в сжатые сроки должна была занять полтора месяца с момента подписания договора. Но реальность, как обычно, решила посмеяться над планами. Документы ушли на согласования по всем возможным службам Заказчика, а мы, глядя на календарь, поняли простую истину: если ждать всех формальностей, в этом году релиза не будет.

Поэтому в проект мы вошли 24 ноября, не дожидаясь бумажной бюрократии. А уже 10 декабря завершили предрелизное тестирование. Чуть больше двух недель — и готова полноценная ERP с проектами, чатами и трёхуровневой ролевой моделью.

Самое забавное, что договор нам подписали… 8 декабря. То есть к моменту подписи мы уже уверенно подходили к финалу.

Тот редкий случай, когда за девятью женщинами действительно можно родить за месяц. Аминь.

Очередные итоги суматошного ноября. Заходим на усиление команды разработки первого серьезного сервиса доставки в Крыму. Названий не будет — NDA. Скажем лишь, что речь не про «привезти Филадельфию соседу». Проект обещает быть большим, сложным — все как мы любим. И, казалось бы, причем здесь геополитика?

Российский ИТ-рынок в 2025 году внезапно вспомнил, что бизнес — это не презентации и «growth mindset», а деньги. По данным CNews, за январь–ноябрь число ИТ-компаний, ушедших в банкротство, выросло на 28%: 630 случаев против 491 годом ранее. Это не «стартапы на энтузиазме», а рабочие компании с контрактами. Рынок сжался, бюджеты стали осторожными, а право на ошибку — исчезло. ИТ больше не баловство, а статья расходов, которую проверяют трижды.

Казалось бы, если ИТ-компании банкротятся — значит, бизнес перестал тратить. Но нет. Опрос CIO российских компаний показывает куда более странную картину: проблема не в технологиях, а в самих компаниях. Около 50% ИТ-директоров признают, что внедрения буксуют из-за инертных процессов, страха изменений и желания «ничего не сломать». В итоге бизнес выбирает короткие PoC и локальные решения вместо больших трансформаций. ИТ готовы покупать — но только без риска, боли и сюрпризов.

Когда внедрять страшно, а ошибаться дорого, начинаются разочарования. Эксперты ГК ЛАНИТ фиксируют то, о чём в отрасли шепчутся давно: в 2025 году рост ИТ-рынка замедлился, облачный сегмент просел, а спрос сместился в сторону сложных кастомных решений. Универсальные платформы оказались слишком общими, а подписки — слишком дорогими. Бизнес всё чаще выбирает больную, долгую, но понятную кастомизацию вместо красивых обещаний «из коробки».

Логичное продолжение всей этой истории — сокращения. В декабре стало известно о массовых увольнениях ИТ-специалистов в «Делимобиле». Причина банальна и от этого ещё неприятнее: пересмотр стратегии, давление на финансы и отказ от части внутренних разработок. Это не единичный случай, а симптом рынка, где ИТ впервые за долгое время обязано доказывать экономическую целесообразность, а не просто «быть». Внутренние команды больше не священны — если не дают отдачи, идут под нож.

Пока рынок внутри страны сжимается, часть российских ИТ-компаний делает самый рациональный шаг — выходит за пределы России. По данным ComNews, более 40 отечественных ИТ-компаний уже продают свои решения во Вьетнаме, а около 14 открыли там полноценные представительства. АТР перестаёт быть «экзотикой» и становится реальным источником выручки. Экспорт больше не выглядит как стратегия роста — это способ остаться на плаву, когда дома слишком тесно.

Российский ИТ-рынок в 2025-м выглядит как парковка после распродажи: тихо, пусто и слегка тревожно. Компании банкротятся, бюджеты режут, решения принимают медленно и с дрожью в коленях. Но у этой истории есть обратная сторона. Пока внутри страны экономят, за рубежом продолжают покупать — прагматично, без пафоса и за живые деньги. ИТ-бизнес снова учится делать то, что давно должен был: конкурировать, считать, адаптироваться и продавать не «планы», а результат. Да, здесь пусто. Зато там — густо. И, что особенно приятно, платят вовремя.

И если что, нам сегодня 14 лет 🥂

Внимание: открыта вакансия менеджера проектов!

Клиенты приходят с ожиданиями, сроками и завышенными представлениями о реальности.
Им нужен не продавец и не оператор поддержки, а человек, который умеет вести разговор с бизнесом и превращать хаос в понятный процесс.

Чем ты будешь заниматься (спойлер: не херней)
- Вести клиентов Elgrow — от первого «а давайте созвонимся» до спокойного «спасибо, было приятно работать».
- Понимать, что клиент на самом деле хочет, даже если он сам пока не уверен.
- Быть связующим звеном между клиентом и командой разработки (и не теряться между ними, как багаж в Шереметьево).
- Контролировать ожидания, сроки, договорённости и здравый смысл.
- Иногда — аккуратно говорить «нет», потому что «да» здесь приведёт к пожару.

Ты нам подойдёшь, если:
- Умеешь общаться с людьми без скриптов и пластиковых улыбок.
- Не боишься сложных клиентов и не теряешься при словах «ERP», «интеграция» и «а это точно в ТЗ было?».
- Понимаешь, что IT-проекты — это не магия, а процесс (иногда шумный, но управляемый).
- Любишь порядок в договорённостях и ненавидишь фразы «мы же вроде договаривались».
- Умеешь держать лицо, когда клиент в десятый раз меняет мнение.

Опыт в IT, digital, агентстве или студии — большой плюс. Опыт «я всё понял, сейчас спрошу у разработчиков» — вообще золото.

Что мы предлагаем
- Работу в Elgrow — студии с 14+ годами реальных проектов, а не презентаций ради презентаций.
- Клиентов из бизнеса, а не «стартап за идею».
- Вменяемую команду, с которой можно говорить нормальными словами.
- Гибкий формат работы (офис / гибрид / удалёнка — обсудим).
- Жалование в 120 - 250 т.р в месяц (зависит от твоего скилла и опыта)
- Возможность расти: в аккаунт-директора, проджект-менеджера или куда захочешь, если есть голова.

Чего точно не будет
- Холодных звонков «по базе».
- Продаж «впарь любой ценой».
- Токсичного микроменеджмента.
- Крика «почему клиент ещё не доволен?!» без контекста.

В 2026 году можно чувствовать себя очень умным человеком. Одна нейросеть напишет вам техническое задание. Другая — сравнит стеки. Третья аккуратно разложит аргументы в таблицу с колонками “производительность”, “масштабируемость” и “современность”. Всё выглядит настолько логично, что остаётся только расслабиться и получать удовольствие.

Проблема в том, что системы редко живут в лабораторных условиях. Они живут в бизнесе. А бизнес — это не синтетический тест. Это пользователи, которые делают не то, что вы ожидали. Это базы данных, которые внезапно становятся узким местом. Это интеграции, которые не читают документацию. И это требования, которые меняются быстрее, чем обновляется презентация для инвестора.

Сейчас я нахожусь в пресейле одного проекта, где стек обсуждается с почти научной серьёзностью. Сравниваются цифры. Приводятся тесты. Делается вывод: один фреймворк быстрее другого.
И в этот момент всегда хочется задать простой вопрос: а это “быстрее” оно сейчас с нами в этой комнате?

Очень часто собственники задают неправильные вопросы, хотя звучат они донельзя логично: “Что быстрее?”, “Что современнее?”, “Что выдержит 15 тысяч пользователей, одновременно нажавших одну кнопку?” Проблема в том, что эти вопросы возникают слишком рано. Когда у продукта еще нет подтвержденного спроса и понятной нагрузки, обсуждать предельную производительность — это как проектировать скоростную автомагистраль, не зная, поедет ли по ней хотя бы один автомобиль.

Когда ТЗ написано нейросетью, сравнение сделано нейросетью, аргументы аккуратно разложены по колонкам, создаётся впечатление, что человеческий фактор устранён. Всё выглядит нейтрально. Рационально. Почти научно. Но архитектура — это не экзамен по теории. Это выбор, за который кто-то будет отвечать. Нейросеть не будет объяснять инвестору, почему сроки сдвинулись. Не будет сокращать бюджет, если инфраструктура оказалась дороже поддержки. Не будет переписывать систему, когда реальная нагрузка окажется совсем другой. Она всего лишь сгенерировала аккуратную картинку.

Подмена происходит незаметно: инженерное мышление заменяется чек-листом, ответственность — таблицей сравнений, а сложные вопросы — формально правильными ответами. И вот это уже не вопрос технологий. Это вопрос управленческой зрелости.

Избыточная сложность почти никогда не выглядит как ошибка. Она выглядит как предусмотрительность. Добавим ещё один слой “на будущее”. Заложим масштабирование “с запасом”. Подготовимся к росту, который пока существует только в презентации. И в этот момент проект начинает медленно дорожать. Больше инфраструктуры — больше времени на настройку. Больше компонентов — больше точек отказа. Больше “правильных решений” — меньше скорости. Команда тратит недели на согласование технических деталей, которые не приближают продукт к рынку. Релиз откладывается. Гипотезы не проверяются. Обратная связь не собирается. Зато архитектура выглядит впечатляюще. Самое ироничное в том, что сложность почти всегда оплачивается дважды. Сначала — в бюджете. Потом — в невозможности быстро изменить направление, когда рынок говорит: “ребята, нам нужно немного другое”.

И в этот момент становится понятно: дело было не в выборе технологии. Дело было в выборе масштаба задачи. И вот этот вопрос нельзя просто взять и делегировать алгоритму.
Нейросеть отлично отвечает на вопрос “что возможно”, но она не отвечает на вопрос “что уместно”. Она не знает вашей финансовой модели. Не чувствует, насколько команда способна переварить сложность. Не понимает, где вы строите систему, а где — иллюзию контроля. Её задача — расширять поле вариантов, а не сужать его до “единственно правильного”. Поэтому нейросеть не нужно заменять. Её нужно правильно использовать. Она может ускорить анализ, подсветить альтернативы, проверить логику. Но решение о масштабе — это всегда выбор осознанный. Алгоритм считает. Человек несет ответственность. И пока эти роли не перепутаны, технологии работают на бизнес. Как только перепутаны — бизнес работает на технологии...

У меня все

На прошлой неделе, в роли независимого приглашённого эксперта, проводил тендер на разработку сайта и мобильного приложения для стартапа. Было полноценное ТЗ. Структура продукта, роли, сценарии, интеграции, требования. Всё аккуратно разложено. Не салфетка с номером телефона из ресторана. Документ, по которому сам бы работал. И вот что оказалось интересным: большинство потенциальных подрядчиков ТЗ даже не открыли. Зато все, как один, настаивали на встрече, без которой «посчитать сроки и стоимость проекта невозможно». Разумеется, встречи состоялись и представляли они собой трату времени на хвастовство портфолио и какими-то непонятными достижениями. Иногда даже были вопросы, ответы на которые есть в техзадании.
Технарей же на встречах либо не было, либо они подключались где-то удаленно (иногда из машины, иногда без камеры) и, чаще всего, на базовые вопросы касательно своей квалификации ответить не могли.
Финал был ещё красивее. Мы получали «Коммерческое предложение»: 20 страниц достижений, наград и логотипов. И одна строка по делу: «Стоимость — 300 000, или 800 000, или 1 500 000, или 3 000 000. Без калькуляции. Без декомпозиции. Без логики. Просто цифра.. Как прогноз погоды. У меня закономерно возник вопрос: что стало с рынком малой разработки? Пресейл превратился в формальность? Продажи окончательно отделились от производства? Техническая экспертиза больше не участвует в оценке? Или никто не готов тратить ресурс до подписания контракта?
Если говорить прямо — так считать проекты нельзя. Разработка, пусть даже и малая, — это инженерная дисциплина. Инженерия начинается с декомпозиции. Если нет разбивки на функциональные блоки, если не оценена трудоёмкость, если не обозначены риски, если не определён состав команды — это не оценка. Это рождественские гадания. А их в IT всегда оплачивает заказчик.
Плохой пресейл почти гарантирует: смещение сроков, рост бюджета, бесконечные «допработы», и конфликт в середине проекта. Почему? Потому что неопределённость никуда не исчезает. Она просто переносится на этап исполнения.
Зрелый подрядчик ведёт себя иначе. Он либо приходит с видением сразу — даже без идеального ТЗ, опираясь на опыт десятков проектов. Потому что понимает типовые архитектурные сценарии, узкие места и экономику разработки. Либо, если проект действительно сложный, он тратит встречу на проект. Не 40 минут про награды и логотипы клиентов, А 90% времени — про архитектуру, модель данных, интеграции, риски, сценарии роста. И только 10% — про себя.
Он может сказать: «Вот три возможных варианта реализации с плюсами и минусами». «Вот где будет дороже». «Вот где зона неопределённости». И даже если цифра пока диапазонная — она объяснена. Потому что пресейл — это не просто этап продажи. Это первая точка проектирования.
А если проектирование начинается после аванса — значит, оно просто оплачивается позже. Если подрядчик не инвестирует в понимание продукта до подписания — он не будет инвестировать в архитектуру во время разработки. А разработка без архитектуры всегда заканчивается одинаково: сдвинутыми сроками, пересборкой решений и разговором о «неучтённом объёме». Хороший пресейл — это не услуга для клиента. Это маркер профессиональной культуры компании. И если его нет — стоит ли удивляться всему остальному?