Заметки · Для владельца

Как малому бизнесу найти надёжного программиста и не потратить на него все деньги

Александр Антоненко · Вильнюс · 28 октября 2026

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

Главное, чего я хочу от такого проекта: чтобы первая версия начала приносить или экономить деньги как можно раньше. Тогда следующие шаги оплачиваются уже из этих денег, а владелец не рискует всем сразу.

Что на самом деле говорят отзывы

Отзыв подтверждает одно: человек что-то сдал, и заказчик в момент сдачи был доволен. Он не говорит, работает ли та программа через год и заработал ли на ней бизнес хоть копейку.

Бывает, что система сделана аккуратно, сдана вовремя, похвалена в отзыве, а через полгода в офисе снова работают в таблице в Excel. В отзыве об этом не напишут.

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

Что проверить до первой оплаты

• Попросите показать работающую систему, которую можно открыть и покликать. Если проект под NDA, нормальный программист покажет его на демо-данных.
• Спросите, что изменилось для владельца той системы в деньгах и времени. «Сделал на React» не говорит ничего. «Отчёт, который занимал семь рабочих дней, теперь готов за два часа» говорит всё.
• Поговорите с тем владельцем. Один короткий вопрос: пользуетесь ли программой до сих пор.
• Послушайте, о чём программист говорит с вами. Если о ваших заказах, складе, оплатах и людях, это хороший знак. Если о фреймворках и архитектуре, он ещё не понял ваш бизнес.
• Получите письменный план до оплаты: что будет сделано, в каком порядке, сколько времени и сколько денег. Устно всё это звучит убедительно и забывается за неделю.

Если программист ждёт от вас техническое задание

Классический программист хорошо делает то, что написано в техническом задании. Это нормальная работа, и в ней нет ничего плохого. Проблема в том, что ТЗ кому-то нужно написать, и написать техническим языком.

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

Начните с одного места, где каждую неделю утекают деньги

Распространённая ошибка владельца, который впервые заказывает разработку, это заказать всё сразу: сайт, CRM, склад, мобильное приложение, интеграции с банком. Большой проект долго делается, долго ничего не приносит и съедает бюджет ещё до того, как им кто-то воспользовался.

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

• заказы из мессенджера перепечатывают в таблицу, а потом ещё раз в службу доставки;
• оплаты сверяют руками по выписке;
• отчёт для руководителя или заказчика пишут по вечерам;
• остатки на складе проверяют звонком, потому что в таблице они не совпадают с полкой.

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

Вот как это выглядит на примере из моей практики. Бренд ухода за волосами сам производит свой продукт, и я сделал для него систему, где всё держится вместе. Когда выпускают партию, сырьё списывается по рецептуре и сразу считается себестоимость. Товар лежит на нескольких складах: центральном, региональных и в салоне. Заказ от розничного клиента или салона-партнёра резервирует товар на конкретном складе, дальше идут доставка, оплата и прибыль за месяц. Производство, склад, клиент, заказ и деньги в одной системе, и никто ничего не перепечатывает между программами.

Посчитайте проблему в деньгах до разговора с программистом

Перед первой встречей сядьте с калькулятором и посчитайте, сколько ваша проблема стоит в месяц:

• часы людей на ручную работу × стоимость их часа;
• потерянные или перепутанные заказы × ваша маржа;
• штрафы, возвраты, повторные доставки;
• подписка на сервис, который вы оплачиваете, но он вам не подходит.

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

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

Будьте владельцем всего с первой минуты

Это самый важный пункт, и о нём чаще всего забывают. Часто владелец бизнеса становится заложником своего программиста. Код лежит у программиста, сервер оформлен на программиста, домен на программиста. Когда программисту что-то не нравится, он просто перестаёт брать трубку, и бизнес стоит.

Чтобы этого не случилось, с первого дня:

• репозиторий на GitHub принадлежит вам, программиста вы туда приглашаете;
• сервер, домен и все сервисы оформлены на вашу почту и вашу карту;
• в рабочих чатах администратор вы, а не программист.

Это не вопрос доверия. Хороший программист сам предложит так сделать, потому что ему тоже спокойнее, когда границы ответственности понятны.

Требуйте документацию с первого дня

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

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

Кто-то сторонний должен смотреть за процессом

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

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

Как работаю я

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

Систему беру полностью: база данных, сервер, сайт, мобильное приложение, запуск и присмотр после запуска. За результат отвечаю лично. Для узких задач подключаю опытных специалистов, с которыми уже работал на предыдущих проектах.

Среди моих работ LilyAssist, помощник, который пишет отчёты для школьных психологов: отчёт, который раньше занимал семь рабочих дней, теперь готов примерно за два часа. Curl School, платформа курсов для парикмахеров, где запись, оплата, доступ к материалам и сертификат происходят без участия офиса. На главной странице сайта тринадцать проектов.

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

Коротко