Як я витратив 2 роки на власний task-менеджер, і чому він не полетів

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Сьогодні хочу розповісти, як я вирішив спробувати з власного пет-проєкту побудувати продукт під назвою TaskJect. Що пішло не так? і чи можна було цього уникнути? А також, чому хороший продукт може не знайти відгуку в світі, про все це — далі.

Всім привіт, мене звати Сергій, я .NET розробник з 8+ роками досвіду.

Із чого все почалось?

Почалась історія в січні 2023 року, коли я, взявши на озброєння декількох студентів почав розробляти гру в Unity — це була виробнича практика у цих студентів. Після практики частина хлопців вирішила продовжити працювати над грою, склад команди трохи змінювався, і переді мною постало питання, як взагалі трекати виконану роботу, планувати спринт, банально аналізувати продуктивність кожного, щоб можна було більш прогнозовано планувати спринти. Відповідно виникла потреба в task-менеджері.

Еволюція сервісів, які ми використовували:

• Project в GitHub — мало функціоналу, не гнучко, через тиждень відмовились;
• Trello — в якийсь момент це просто стала дуже роздута дошка з нерозумінням актуальності задач, через 2 місяці відмовились;
• Notion — це вже було краще рішення, інструмент краще лягав на наші бізнес-процеси, через 4 місяці відмовились;
• Jira — зупинились на етапі аналізу: він був задорогим і громіздким для наших потреб.

У результаті експлуатації різних сервісів і впорядкування процесів, визначили для себе наступні важливі функції:

1. Облік задач по проєктах.
2. Трекінг часу по кожній задачі — час виконавці трекали самостійно, для мене це більше аналітична інформація.
3. Можливість вказувати бали за задачу з подальшим аналізом в певному періоді (як умовна одиниця складності).

Це описані базові функції, з часом додалось ще наступні функції:

1. Інтеграція з Telegram: коли хтось з виконавців перетягує задачу в статус «On review», я одразу про це знаю через Telegram.

   

2. Інтеграція з GitHub: відкриваючи pull request або якщо задача була приєднана до основної гілки — в TaskJect автоматично оновлювались статуси задач.

Не знайшовши зручного рішення для себе, вирішили реалізувати власний task-менеджер.

Стек і технічні особливості розвитку

Стек технологій наступний:

• Back-end: ASP .NET CORE 8 + EF CORE.
• Front-end: Razor Pages + Bootstrap 5.
• Інфраструктура: спочатку хостинг для ASP .NET додатків, з часом перехід на Azure App Service.

Доволі просто, не було бажання ускладнювати собі життя складними технологіями.

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

Але мінуси в архітектурі також є, в моєму випадку пов’язані з адмініструванням і витратами на обслуговування: як часовими, так і фінансовими. Кожен сервіс окремо треба хостити, для кожного тримати окрему БД, кожному мати окремий домен. Тут я вже почав шахраювати: я використовував лише одну БД.

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

На додачу до цього, коли ми почали думати про створення продукту з внутрішньої системи обліку, вирішили розділити середовище: окремо тестове, окремо production. Чому так?

Ну, по-перше, контроль якості — іноді доопрацювання ламали інші механіки (unit і integration-тести, добрий день вам). Те, що у розробника локально все працює, не означає що працюватиме після публікації, оскільки це інше середовище. Чому не було тестів? Банально не пріоритет № 1, функціоналу розроблено чимало, все покрити тестами — це зупинити інші важливі роботи.

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

Окремо варто поговорити про оптимізацію процесів і швидкість/зручність випуску в production нових фіч:

Спочатку ми наш хостинг залишили як тестове середовище, а в Azure був production. Як відбувалась процедура публікації нової фічі:

1. Створюємо pull request.
2. Після чого я додаю конфіги для публікації на хостинг (якщо паралельно ведуться декілька робіт, то я вже публікую після завершення всіх робіт — таким чином економив власний час).
3. Додатково тестуємо вже опубліковану версію в тестовому середовищі.
4. Якщо все добре, переходимо до підготовки публікації в production.
   1. Звіряю структуру БД, оскільки в production використовувався Azure SQL, там управляти станом БД через міграції не хотів.
   2. Якщо зміни в структурі є — переношу їх вручну.
   3. Якщо немає додаю конфіги і параметри від Azure App Service і публікую.

Ця ітерація була довгою, іноді тиждень-два на одну-дві фічі. Тут було купа ручних операцій, підкидання файлів публікації і параметрів. Мені це набридло, тому я вирішив частково автоматизувати цей процес. Що я зробив:

1. Переніс тестове середовище в staging-slot в Azure App Service.
2. Налаштував параметри для Development і Production середовища виключно в Azure, можна було забути про json-файлики.
3. Реалізував GitHub Action, який після merge на main автоматично збирає білд в тестове середовище, яке вже в Azure.

Це суттєво підвищило швидкість появи фічі на проді, з 1-2 тижнів до 1-2 днів зазвичай, однак це і підняло вартість на інфраструктуру, станом на зараз це 200-300$ на місяць, в порівнянні зі стартовими 50$ витрати зросли в 4-6 разів. Як це працює зараз:

1. Зводимо pull request.
2. Протягом 5 хвилин зміни з’являються в Development середовищі.
3. Тестувальник може відразу це тестувати.
4. Залишився один ручний процес — контроль стану БД.
5. Якщо все ок — натискаю лише кнопку Swap, і мій основний і staging слот міняються місцями, зберігаючи параметри. Тобто остання редакція додатку вже на проді, але з production-параметрами.

Як я прийшов до того, що наш додаток може стати продуктом?

У кінці 2024-го, коли в мене був прощальний дзвінок з одним з моїх розробників, ми зачепили цікаву тему — TaskJect і процес роботи над ним. Чому дзвінок прощальний? Тому що мій розробник знайшов full-time роботу, у чисто IT-середовищі, де він може розвиватись ще більшими темпами (звісно, маючи бажання). Тому я тішусь за кожного члена моєї команди, який в подальшому може себе реалізувати в сфері, отже наші спільні вечори за code review ми проводили не даремно 🙂

Але повернемось до самого прощального дзвінка — мій колега відкрив мені наш сервіс під іншим кутом, сказавши, що це був крутий досвід і це може бути цікавим альтернативним рішенням великих task-менеджерів. Це дійсно змусило замислитись, бо раніше я не розглядав це як сервіс загального користування. З часом прийняв рішення спробувати запустити цей сервіс як продукт.

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

Підготовка до Launch нашого TaskJect

Вирішили сервіс трохи уніфікувати, прибрати дуже кастомні якісь фічі, додати функції, які must have для багатьох команд, тобто привести до більш презентабельного стану, основні з них:

1. Додали англійську мову.
2. Додали встановлення ролей в проекті.
3. Реалізували landing.
4. Додали тарифні плани з інтеграцією з платіжною системою.
5. Зробили демо-відео.

Після чого на кінець червня 2025 ми готові були запускатись, про що я радісно проінформував свою спільноту в LinkedIn. Що ми отримали в результаті? Декілька реєстрацій від друзів, декілька реєстрацій від незнайомих людей. Друзі хоча б надали свій фідбек, що вже цінно, проте очікування були в мене на той момент завищені.

Після неуспішного старту, ми почали думати над шляхами залучення нових користувачів. Для мене це була повністю нова галузь, бо до цього я був виключно розробником. Тому такі речі як визначення цільової аудиторії, визначення юніт-економіки, аналіз конкурентів і т.д. це були дуже нові речі для мене. Почали опрацьовувати різні стратегії, в умовах дуже обмеженого бюджету, основні з них:

1. Просування через персональну сторінку в LinkedIn, я почав там регулярно писати, і не лише про TaskJect, щоб не бути спамом.
2. Публікація дописів про TaskJect на Indie Hackers.
3. Лідогенерація в LinkedIn.

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

Перехід від холодного outreach до спроби заявити про себе

Першим великим кроком була IT Arena, яку я відвідав в 2025.

Я давно хотів відвідати якусь велику IT-конференцію, відчути цю атмосферу, завести нові професійні конекти, послухати цікавих спікерів, подивитись які стартапи виграють гранти.

Чи було це цікаво? Так, з радістю відвідаю ще раз такий захід.

Чи було це корисно? Для власного розвитку в IT-сфері — так, як для розвитку TaskJect — практично ні. На виході отримав декілька конектів, декілька спітчів, декілька демо-дзвінків по поверненню в Київ з людьми, з якими познайомився на IT Arena.

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

Мережеве просування

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

Я почав ознайомлюватись з різними майданчиками і з чим вони працюють, визначив наступні категорії:

1. Платформи-каталоги сервісів (типу Alternetive.to).
2. Сервіси для одноразового Launch (типу Product Hunt).
3. Сервіси, що генерують трафік за рахунок знижок (Saas Pirate).
4. Блоги (типу Indie Hackers).

Нижче зображена окрема моя папка з усіма збереженими закладками для мережевого просування по TaskJect

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

1. Отримати локальний фідбек і провести його аналіз, ймовірно він може бути валідним для покращення сервісу перед виходом на більші платформи.
2. Зрозуміти механіку цих мереж, як правильно подавати свій продукт.
3. Отримати стартовий трафік, рейтинг домену і бек-лінки.

Найбільше цікавого фідбеку отримував саме на Indie Hackers, там часто була об’єктивна і аргументована критика та пропозиції.
Одним із перших майданчиків був Fazier, де ми зайняли Топ-1 з 48 upvotes протягом дня (fazier.com/launches/taskject). Це був локальний успіх, однак глобально він ні в що не конвертувався.

Далі ми почергово публікувались на різних майданчиках, фінальною точкою якою я вважав повинен бути Product Hunt — майданчик який може генерувати великий трафік і дійсно забустити Launch. Однак ми там з тріском провалились, на кінець дня було лише 7 upvotes. Це був маркер, що продукт в конкурентному середовищі не цікавий ринку.

Одна з останніх спроб просування в мережі була співпраця з майданчиками, які надають пожиттєву знижку на ваш сервіс. Здається, топ-1 в цій ніші це App Sumo, проте з ними комунікація не задалась, альтернативним варіантом обрали Saas Pirate. Поспілкувавшись з представниками, вони надали свої середні результати, ми після аналізу, вирішили підготувати матеріали до публікації і на виході отримали... нічого. Абсолютно нічого.

На цьому етапі мережеве просування сповільнилось, нові канали не з’являються в цій ніші так швидко, подальша підтримка/комунікація на існуючих майданчиках профіту не дала.

Останні ідеї

Чи я допускав, що я свою роботу виконую не якісно або банально не маю відповідної експертизи? Звісно, і не раз, але як це виправити? Все водночас дуже просто і не просто — мати спеціалістів високого рівня, які зможуть ділитись власною експертизою. Тобто делегувати задачі експертам в цій галузі. А гарний експерт = гарні гроші. Була комунікація з деякими спеціалістами за частку, а не за зарплату, проте це скоріше винятки + ці спеціалісти все одно потребують бюджету, не для себе, а для продукту.

Тому тут постала ідея залучення коштів від інвесторів чи фондів. Проте не було розуміння з чого почати, де шукати цих інвесторів, здавалось що це все дуже складно і технічно, і юридично. Пропрацьовуючи цю ідею, в цей час побачив статтю на DOU про Connecto і частково про пройдений шлях, який мене чекав попереду, захотілось поспілкуватись глибше з засновницею Світланою Мусійко, Світлано тобі вітання👋.

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

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

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

Цей фідбек дуже важливий, оскільки він:

1. Об’єктивний — людей цікавить бізнес-модель, якщо вони бачать потенціал чи ні, то вони про це говорять.
2. Конструктивний — це не просто критика заради критики, просто люди існують за межами нашої бульбашки і дивляться на ситуацію ширше.

На цьому етапі ми вирішили зупинити наш taskject.com. При невдачі головне вчасно її усвідомити і проаналізувати помилки.

Результати та висновки

Перш за все, про результати:

Станом на зараз в TaskJect зареєстрована 21 команда, з яких активних 7. Жодної команди на платному тарифі.

Найбільший профіт реєстрацій дало просування через мережу (близько 50%).

Це про метрики сервісу, однак отриманий досвід це також результат.

А тепер щодо власних висновків:

Перший і ключовий пункт — я вийшов за межі бульбашки технічного спеціаліста. Ми, технічні люди, часто вважаємо нашу діяльність ключовою. Частково це правда, бо ми створюємо продукт. Але який сенс від цього продукту, якщо про його цінність/крутість знаєш лише ти?

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

Команда — це дуже важлива складова. Ключові аспекти які варто виділити:

1. Атмосфера в команді, її варто вибудовувати, іноді через складні рішення. Проте команда ефективніша, коли немає токсичності і зайвої напруги.
2. Варто делегувати задачі, намагатись робити все самому — це шлях у нікуди. Якщо ти не розумієшся в маркетингу, то запит до AI «Зроби мені маркетинг» не дасть бажаного ефекту.

Частину з описаних стратегій, ідей і підходів в цій статті активно допомагав застосовувати Роман Пихалов. Так само і технічну частину — можна делегувати колегами і отримати win-win, для мене — розвантаження технічними задачами і фокус на стратегічних, для них — вища зона відповідальності, відповідно і технічне прокачування навичок, де треба переходити від прямої реалізації задачі до пропозиції щодо задачі.

Що далі?

На початку я згадував, що все починалось з мобільної гри — вона все ще в роботі, сподіваюсь літом буде реліз, але це не точно 😅

Сам TaskJect піде в історію, проте відкриваю його як публічний репозиторій, можливо комусь буде цікаво погратись: github.com/skyfer77/TaskJect

Трохи планую видихнути, призупинити такий турборежим — нагадую розвиток сервісу був як part-time, а іноді як другий full-time. Оскільки весь цей час маю основну роботу. Зараз хочу сфокусуватись на основній роботі, приділити більше власному технічному розвитку, можливо трохи активніше вести свій LinkedIn.

А ще маю одну нову футболку з логотипом TaskJect, розмір M, така як на фото. Готовий віддати за донат на військо.