Нотатки · Для власника

Як малому бізнесу знайти надійного програміста і не витратити на нього всі гроші

Олександр Антоненко · Вільнюс · 28 жовтня 2026

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

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

Що насправді кажуть відгуки

Відгук підтверджує одне: людина щось здала, і замовник у момент здачі був задоволений. Він не каже, чи працює та програма через рік і чи заробив на ній бізнес хоч гривню.

Буває, що система зроблена акуратно, здана вчасно, похвалена у відгуку, а через пів року в офісі знову працюють у таблиці в Excel. У відгуку про це не напишуть.

Тому «перевірений програміст» для мене той, чию роботу можна перевірити самому, а не той, у кого багато зірочок.

Що перевірити до першої оплати

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

Якщо програміст чекає від вас технічне завдання

Класичний програміст добре робить те, що написано в технічному завданні. Це нормальна робота, і в ній нічого поганого. Проблема в тому, що ТЗ треба комусь написати, і написати технічною мовою.

Якщо програміст, якого ви знайшли, чекає готового ТЗ, спочатку знайдіть бізнес-консультанта, який розбереться у ваших процесах і перекладе їх на мову програміста. Інакше ви напишете завдання так, як розумієте його самі, програміст зробить так, як зрозумів він, і є реальний шанс отримати роботу, яка нікому не потрібна.

Почніть з одного місця, де щотижня витікають гроші

Поширена помилка власника, який уперше замовляє розробку, це замовити все одразу: сайт, CRM, склад, мобільний застосунок, інтеграції з банком. Великий проєкт довго робиться, довго не приносить нічого і з’їдає бюджет ще до того, як ним хтось скористався.

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

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

Першу версію робіть саме для цього місця. Вона маленька, тому швидко готова і швидко починає економити. З цієї економії оплачується другий крок, і так далі. Кроки складаються в систему, де весь шлях замовлення живе в одному місці.

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

Порахуйте проблему в грошах до розмови з програмістом

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

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

Отримаєте число. Перший крок розробки має коштувати менше, ніж ця проблема за кілька місяців. Якщо програміст пропонує щось дорожче, значить, або крок занадто великий, або він не почув, де у вас болить.

З цим числом розмова з програмістом стає зовсім іншою. Ви вже знаєте, що купуєте і за скільки це окупиться.

Будьте власником усього з першої хвилини

Це найважливіший пункт, і про нього найчастіше забувають. Часто власник бізнесу стає заручником свого програміста. Код лежить у програміста, сервер оформлений на програміста, домен на програміста. Коли програмісту щось не подобається, він просто перестає брати слухавку, і бізнес стоїть.

Щоб цього не сталося, з першого дня:

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

Це не питання довіри. Добрий програміст сам запропонує так зробити, бо йому теж спокійніше, коли межі відповідальності зрозумілі.

Вимагайте документацію з першого дня

Кожне завдання і кожне рішення мають бути записані: що зробили, чому саме так, як це запустити і де що лежить. Якщо документації нема, замінити програміста практично неможливо, і ви знову заручник.

У часи ШІ це вже не тягар для програміста. Якщо просити ШІ записувати хід роботи і рішення, документація з’являється майже автоматично. Тому відповідь «документацію напишемо потім» сьогодні не приймається.

Хтось сторонній має дивитися за процесом

Ще одна порада, яка економить багато грошей: знайдіть професіонала, який годину на тиждень дивитиметься, як іде розробка. Він читає, що зроблено, звіряє з планом і каже вам простими словами, рухається проєкт чи стоїть.

Зовнішній контроль тримає програмістів у рамках. Коли розробник знає, що його роботу раз на тиждень переглядає колега, він не затягує і не байдикує за рахунок замовника. Для вас це дешева страховка проти найдорожчого сценарію, коли через пів року з’ясовується, що зроблено не те.

Як працюю я

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

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

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

Починаємо з короткої розмови. Після неї я надсилаю письмову відповідь: що зробив би першим кроком, скільки це займе часу і скільки коштує. Рішення ви ухвалюєте вже з цим документом у руках.

Коротко