Нет, я не масштабируюсь. И это моя стратегия.

Мне периодически говорят: «Тебе надо масштабироваться». Я веду boutique-студию разработки и намеренно её не масштабирую. Соглашаюсь кивком и не делаю ничего. Не потому что лень. Потому что я пробовал.

Вот что вышло.

Когда я всё-таки попробовал

Был период, когда у нас одновременно шло три проекта. Восемь человек в команде — не гигантская студия, но уже не два человека в чате. Выручка на бумаге выглядела нормально. Я думал: вот оно, масштаб. Работает.

Потом я начал считать.

Встречи. Ежедневные статусы по каждому проекту. Время на онбординг человека, которого взяли специально под третий контракт. Переключения контекста — из Elasticsearch в Bitrix-интеграцию, оттуда в code review по Next.js. В такой неделе у меня оставалось часа четыре на то, что я умею лучше всего: архитектурные решения и работу с клиентом напрямую.

Один из проектов дал баг в продакшне. Не критический — но такой, который я в режиме двух проектов поймал бы на review. В режиме трёх он дошёл до клиента.

Я не сгорел. Просто перестал понимать, что мы строим.

Три признака, что проект вышел за boutique-предел

За несколько лет я научился замечать момент, когда очередной контракт переводит нас из зоны управляемого в зону перегруженного. Вот три конкретных сигнала.

Первый — я начинаю назначать встречу, чтобы вспомнить, где мы остановились. Если контекст по проекту не держится в голове без повторной встречи — проект уже не boutique. Это не дисциплина и не Jira. Это ёмкость.

Второй — я привлекаю человека, которого не выбирал специально под задачу. Когда нанимаем «просто чтобы закрыть слот» — качество решения не растёт, растут только согласования. В 2022 году я взял разработчика на проект с 28k SKU в каталоге. Мы с ним два месяца тянули Elasticsearch в правильную сторону — это работало, потому что я лично участвовал в каждом техническом решении. Добавь туда ещё один параллельный контракт — не участвовал бы.

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

Моя capacity policy

Сейчас у меня простое правило: не более двух активных проектов одновременно. Не три, не «зависит от размера». Два.

Расчёт, не консерватизм. При двух проектах я успеваю вникнуть в проблему до того, как дать ответ. Провожу presales сам. Принимаю архитектурные решения лично, без посредника.

Год назад ко мне пришёл потенциальный клиент с проектом миграции на headless. Бюджет хороший, срок реальный, клиент вменяемый. Единственная проблема: я уже вёл два проекта на пике нагрузки. Я отказал. Клиент нашёл другого подрядчика. Через три месяца вернулся — с тем же запросом, с лучшими условиями, потому что к тому моменту у первого подрядчика что-то пошло не так.

Не магия. Репутация boutique держится на предсказуемости, а предсказуемость — на capacity.

Стоимость четвёртого проекта

Переключение контекста стоит дороже, чем кажется. Я мерил.

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

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

Ещё одна цифра: когда команда росла до восьми человек, выручка на человека падала. Не потому что люди хуже. Потому что росло время на координацию — а оно не продаётся клиенту.

Boutique — это не маленький, а глубокий

Когда кто-то говорит «у вас маленькая студия» — я слышу «у вас мало людей». Это неправильная единица измерения.

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

Это не масштабируется без потерь. И я не пытаюсь.

Если проект требует больше, чем может дать boutique-студия — я об этом говорю прямо. Иногда это означает, что сделка не состоится. Чаще — что клиент знает, что у меня получать.

Я не закрываю тикеты. Я закрываю риски. И риск первый — взять больше, чем можешь сделать хорошо.