Несколько проектов параллельно, один я: как это устроено

Меня зовут Чимитдоржи Дарижапов. Я делаю сайты, боты, мини-приложения и админки — и делаю это в одиночку. Почти каждый разговор с новым заказчиком рано или поздно упирается в один и тот же вопрос. Иногда его задают прямо, иногда прячут за вежливостью, но он всегда там. И это правильный вопрос. В этой статье я на него отвечаю — так, как отвечал бы себе самому.

Вопрос, который задают все

Звучит он примерно так: «Ты работаешь один? А если ты заболеешь? А если у тебя завал и ты просто не успеешь? Потянешь ли ты несколько проектов сразу, не бросишь ли мой на полпути?»

Я не считаю этот вопрос обидным. Наоборот — если человек его задаёт, значит, он серьёзно относится к своим деньгам и к своему делу. Заказчик рискует: он отдаёт задачу, от которой зависит его бизнес, одному человеку, а не компании с отделами и подстраховкой. Было бы странно, если бы он не переживал.

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

Если хотите шире посмотреть на то, как вообще работает студия из одного человека в 2026 году — там я разбираю саму модель. Здесь же — про будни.

Как расставляю приоритеты

Главная ошибка, которую совершает соло-разработчик, — пытаться двигать все проекты одновременно, по чуть-чуть каждый день. Это путь в никуда: постоянное переключение съедает больше сил, чем сама работа, а внутри головы каша. Я так не делаю.

Вместо этого я расставляю приоритеты по трём простым признакам.

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

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

Третье — этап проекта. Проекты живут стадиями: сначала обсуждение и архитектура, потом активная разработка, потом отладка, потом запуск и поддержка. Эти стадии требуют разной энергии и разного склада мышления. Я стараюсь не держать все проекты в стадии «активная разработка» одновременно — это физически невозможно вести качественно. Один проект в горячей фазе, другой — на стадии обсуждения, где нужны редкие, но важные решения, третий — на поддержке, где основная работа уже сделана. Так нагрузка распределяется естественно.

Принцип, если сжать в одну фразу: не хвататься за всё сразу, а вести проекты по стадиям. Тогда параллельность перестаёт быть перегрузкой и становится нормальным ритмом.

Ритм работы

Дисциплина приоритетов ничего не стоит без дисциплины дня. Вот три вещи, на которых держится мой ритм.

Блоки фокуса. Я работаю не «понемногу обо всём», а длинными блоками на одной задаче. Внутри блока — только она. Никаких «дай гляну, что там в другом проекте». Сложный код и архитектуру невозможно держать в голове, если тебя дёргают каждые десять минут. Один блок — одна задача — один проект. Переключение стоит дорого, и я плачу за него как можно реже.

Фиксированные точки коммуникации. Я не сижу в мессенджерах весь день. Если реагировать на каждое сообщение в момент его прихода, ни одного блока фокуса не останется — день рассыплется на реакции. Поэтому у меня есть определённые окна, когда я разбираю переписку, отвечаю заказчикам, обсуждаю правки. Между окнами я работаю. Заказчики знают, что ответ придёт — просто не в ту же секунду, а в предсказуемое время. Это, как ни странно, повышает доверие: человек видит систему, а не хаос.

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

Где выручает ИИ

Честно скажу прямо: без ИИ я бы не вёл столько проектов параллельно. Не потому, что ИИ пишет за меня всё, — а потому, что он забирает ту рутину, которая раньше съедала часы и выматывала голову.

Что именно я отдаю ИИ:

• Типовой код. Формы, CRUD-операции, обработчики, повторяющиеся компоненты. То, что я и так знаю, как написать, но что заняло бы время на набор.
• Черновики. Первый вариант функции, первый набросок вёрстки, скелет модуля. Черновик всегда быстрее довести до ума, чем начать с чистого листа.
• Разбор документации. Новая библиотека, чужой API, незнакомый формат — ИИ быстро вытаскивает суть, а я не трачу полдня на чтение.
• Тексты. Описания, черновики писем, пояснения для заказчика, наполнение страниц.
• Проверки. Прогнать код на типичные ошибки, найти забытый случай, посмотреть свежим взглядом.

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

Где только руки

А теперь честно про обратную сторону, потому что вокруг ИИ много шума и легко подумать, что он делает всё. Не делает.

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

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

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

Принятие решений и ответственность. Когда что-то идёт не так, отвечаю я. Не ИИ, не инструмент. Заказчик доверяет результат конкретному человеку, и этот человек за него отвечает целиком.

Вкус в деталях. Отличие «работает» от «работает и приятно» — в мелочах, которые ИИ не чувствует. Где поставить отступ, как назвать кнопку, что убрать, чтобы стало легче. Это ручная, вдумчивая работа, и именно она отличает живой продукт от сгенерированного.

Про то, как весь этот путь проходит проект целиком — от первого наброска до рабочей версии в проде — я подробно рассказал в статье от MVP до продакшена.

Честно про риски

Теперь самое важное, и я не буду это приукрашивать. Один человек — это риск. Отрицать глупо.

Я могу заболеть. Я могу устать так, что качество просядет. У меня нет коллеги, который подхватит задачу, пока я лежу с температурой. Это правда, и заказчик имеет полное право её знать до начала работы, а не узнавать потом.

Что я делаю, чтобы этот риск снизить:

• Реалистичные сроки. Я закладываю запас, а не называю героическую дату, которая держится на том, что всё пройдёт идеально. Идеально не проходит никогда. Срок с запасом переживёт и простуду, и внезапную сложность.
• Не беру больше, чем тяну. Это, наверное, главное. Я сознательно не набираю столько проектов, чтобы каждый следующий отнимал качество у предыдущих. Лучше отказать новому заказчику или подождать, чем взять и подвести двоих сразу. Отказ — это не слабость, это честность.
• Документирую проекты. Каждый проект описан так, что в него можно войти со стороны. Если по-настоящему прижмёт, другой разработчик сможет разобраться — не с нуля, а по документации, структуре и понятному коду. Это подстраховка не только для заказчика, но и для меня.
• Договор. Отношения зафиксированы на бумаге: что делаю, в какие сроки, что происходит в разных ситуациях. Договор защищает обе стороны и убирает почву для недомолвок.

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

Частые вопросы

А если вы заболеете или пропадёте? Это честный риск одного человека, и я его не прячу. Снижаю его так: беру ровно столько проектов, сколько тяну; фиксирую договорённости и документирую проект, чтобы его при необходимости мог подхватить другой; держу реалистичные сроки без обещаний «вчера».

Не пострадает ли мой проект от того, что я не единственный клиент? Нет, если приоритеты выстроены. Я веду проекты по стадиям и не хватаюсь за всё сразу — у каждого свой блок внимания. Если чувствую, что не потяну качественно, честнее отказать, чем взять и подвести.

Коротко о главном

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

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

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