Мій фільтр ідей: як вбити поганий проєкт до першого рядка коду

<p>Зараз у моєму пайплайні паралельно розробляються або чекають у беклозі десятки мобільних застосунків і кілька SaaS-сервісів. І головне питання тут не в тому, як придумати ще одну ідею. Ідей завжди достатньо. Головне питання — як вирішити, що реально варте роботи, а що має померти ще до того, як ви відкриєте редактор коду.</p>

<p>Більшість людей переоцінюють момент придумування ідеї й недооцінюють момент її відбору. Вони думають, що успіх починається з “креативу”. Насправді дуже часто успіх починається з уміння вбити слабку концепцію раніше, ніж вона з’їсть ваш час, увагу, енергію і мотивацію.</p>

<p>Ідеї нічого не варті, якщо ви не можете їх швидко реалізувати та продати.</p>

</blockquote>

<p>Оскільки я працюю над своїми проєктами в обмеженому режимі — приблизно по дві години на день, — у мене немає розкоші помилятися у виборі. Я не можу дозволити собі місяць копирсатися в красивій, але нежиттєздатній ідеї. Саме тому в мене є жорсткий багаторівневий фільтр. Якщо ідея не проходить хоча б один важливий пункт, вона не “йде в подумати”, не “чекає свого часу”, не “можливо колись”. Вона летить у смітник.</p>

<p>І це не песимізм. Це гігієна. Бо для соло-розробника або невеликої команди найнебезпечніше — не брак ідей, а брак фокусу.</p>

<h2>Чому хороший фільтр важливіший за великий список ідей</h2>

<p>Проблема більшості беклогів не в тому, що там мало хороших задумів. Проблема в тому, що там надто багато всього впереміш: щось виглядає цікаво, щось звучить перспективно, щось “може колись зайти”, щось просто хочеться зробити для душі. І якщо не мати системи відбору, то дуже легко переплутати реальний продукт із фантазією.</p>

<p>На етапі ідеї майже будь-який проєкт здається красивішим, ніж він є насправді. У голові він уже працює, уже має користувачів, уже росте, уже приносить гроші. Але це самообман. Реальний проєкт починається не там, де ви придумали назву й логотип, а там, де ви чесно відповіли собі на незручні питання:</p>

<ul>

<li>хто цим реально буде користуватися;</li>

<li>чому людина взагалі повинна це відкрити;</li>

<li>чи можна це швидко зібрати;</li>

<li>чи не стане це фінансовою дірою;</li>

<li>чи не розвалиться все на підтримці;</li>

<li>і як ви це будете просувати.</li>

</ul>

<p>Саме тому мій фільтр побудований не навколо “наскільки мені подобається ідея”, а навколо її життєздатності. Не “чи прикольно було б”, а “чи є сенс витрачати на це обмежений ресурс”.</p>

<h2>Мій принцип: проєкт має пройти перевірку реальністю</h2>

<p>Я не роблю продукти “для всіх”. Я не закохуюся в концепт тільки тому, що він звучить сучасно або розумно. Я не починаю розробку лише тому, що мені технічно цікаво це зібрати.</p>

<p>Ідея проходить далі тільки тоді, коли витримує перевірку реальністю. Тобто коли я можу уявити не просто продукт, а конкретний сценарій:</p>

<ul>

<li>хто цією штукою користується;</li>

<li>яку конкретну проблему вона закриває;</li>

<li>як людина зрозуміє цінність із перших секунд;</li>

<li>як я це зберу без зайвого болю;</li>

<li>і як це не вб’є мене в підтримці ще до перших грошей.</li>

</ul>

<p>Нижче — ті самі 6 питань, які й вирішують долю проєкту.</p>

<h2>1. Чи є у проєкту потенційна аудиторія?</h2>

<p>Це перший фільтр, і він важливіший за всі інші. Бо якщо немає реальної аудиторії, усе інше не має значення. Ні гарний дизайн, ні зручний код, ні красивий маркетинг не врятують продукт, який нікому не потрібен.</p>

<p>Тут важливо не плутати “може комусь знадобиться” з “є люди, у яких це болить прямо зараз”. Мене не цікавлять ідеї, де аудиторія описується словами “ну це може бути корисно майже всім”. Якщо продукт “для всіх”, то майже завжди він ні для кого конкретно.</p>

<p>Я хочу бачити чітку людину. Не абстрактний сегмент, а реальний тип користувача. У нього є конкретний біль, конкретний контекст і конкретна причина шукати рішення. Якщо я не можу в голові намалювати цю людину і її ситуацію — розробка не починається.</p>

<p>Хороший знак — коли проблему можна сказати простою людською мовою. Наприклад: людина постійно забуває щось важливе, не може швидко оформити контент, плутається в розкладі, не встигає вести харчування, губить документи, хоче швидко зібрати певний сценарій без складного софту. Поганий знак — коли проблема звучить як презентація для інвестора, а не як реальне життя.</p>

<p>Ще один критерій: людина повинна не просто “погодитися, що таке буває”, а бути готовою шукати рішення. Бо є купа проблем, які існують, але не мають достатнього болю, щоб користувач відкривав App Store, Google, TikTok або Reddit і шукав вихід.</p>

<p>Якщо я не бачу конкретну людину з конкретною проблемою, я не починаю розробку. Усе інше — фантазія.</p>

</blockquote>

<h2>2. Чи зможу я легко подати ідею та показати користь без складного онбордингу?</h2>

<p>Сучасна людина не хоче “розбиратися”. Вона не хоче вивчати ваш продукт. Вона не хоче дивитися 10-хвилинний туторіал, читати інструкцію або проходити складний шлях, щоб дістатися до користі. Якщо цінність не видно швидко, користувач не дасть вам другого шансу.</p>

<p>Тому я дивлюся на ідею дуже просто: чи можна пояснити, що це і навіщо воно, буквально за кілька речень? Чи можна показати цінність із першого екрана? Чи зрозуміє людина без підготовки, що тут робити далі?</p>

<p>Якщо продукт вимагає складного онбордингу, він автоматично стає дорожчим у всьому:</p>

<ul>

<li>його важче маркетити;</li>

<li>його важче пояснювати в рекламі;</li>

<li>його важче просувати короткими відео;</li>

<li>його важче пакувати в App Store;</li>

<li>його важче утримувати в перші секунди.</li>

</ul>

<p>А для соло-запуску це критично. Бо що складніший перший контакт із продуктом, то більше зусиль потрібно, щоб просто довести людину до моменту “ага, я зрозумів, у чому сенс”.</p>

<p>Я люблю ідеї, де цінність читається майже миттєво. Людина відкрила застосунок і відразу зрозуміла: ось що це робить, ось чому це корисно, ось що натиснути далі. Не тому, що люди дурні. А тому, що увага дорога.</p>

<h2>3. Чи зможу я реалізувати MVP без витрат грошей, на безкоштовних сервісах?</h2>

<p>Це один із найжорсткіших фільтрів. Якщо ідея вимагає помітних грошей уже на вході, вона дуже швидко стає небезпечною. Бо ви ще не знаєте, чи потрібен продукт комусь, а вже починаєте вкладати в нього бюджет, ніби він усе довів.</p>

<p>Я не хочу платити за дорогі сервери, підписки й інфраструктуру до того моменту, поки продукт не показав бодай якісь ознаки життя. Якщо для самого старту розробки треба одразу витягнути кількасот доларів, ідея майже завжди вилітає.</p>

<p>Саме тому для мене дуже важливе питання: чи можна зібрати мінімальну версію на безкоштовному стеку? Якщо так — це хороший знак. Якщо ні — я дуже уважно дивлюсь, чи справді така ідея варта ризику.</p>

<p>Я нещодавно окремо зібрав добірку про те, як побудувати <a href="/blog/free-infra">безкоштовну інфраструктуру для проєкту</a>, щоб не палити бюджет на старті. І це не дрібниця. Це один із фундаментів фінансової безпеки. Бо чим довше проєкт може жити без постійних витрат, тим вищий шанс, що він доживе до моменту, коли з’являться користувачі, зворотний зв’язок і гроші.</p>

<p>Для мене хороший продукт на старті — це той, який можна зібрати на безкоштовному хостингу, безкоштовній базі, дешевій або нульовій автоматизації, без важких щомісячних рахунків за все підряд. Не тому, що я боюся вкладень. А тому, що я не хочу платити за ілюзію прогресу.</p>

<h2>4. Чи зможу я підтримувати це безкоштовно або майже безкоштовно?</h2>

<p>Багато хто думає тільки про старт. Але справжня пастка часто починається не в момент запуску, а через місяць, коли продукт уже живе і тягне за собою регулярні витрати. І якщо ці витрати з’являються раніше, ніж монетизація, проєкт перетворюється не на актив, а на пасив.</p>

<p>Щомісячні операційні витрати вбивають інді-проєкти значно частіше, ніж помилки в коді. Бо ви можете пережити сирий інтерфейс, неідеальний маркетинг, навіть слабкий перший реліз. Але якщо кожен місяць у вас іде обов’язкова сума на інфраструктуру, сторонні API, платні сервіси, нотифікації, аналітику, генерацію, зберігання і ще купу дрібниць, то проєкт починає висіти на шиї.</p>

<p>Саме тому я запитую не тільки “чи можу я це запустити”, а й “чи зможу я це тримати без болю”. Якщо продукт вимагає постійних витрат ще до появи доходу, це дуже поганий сигнал.</p>

<p>Я люблю ідеї, де навіть після запуску система може жити або майже безкоштовно, або з настільки малими витратами, що це не створює психологічного тиску. Бо коли продукт не душить вас щомісячно, ви можете працювати спокійніше, тестувати довше і приймати рішення без паніки.</p>

<h2>5. Чи працює це без складного бекенду?</h2>

<p>Що менше складної серверної частини, то краще. Особливо якщо ви соло-розробник або невелика команда. Ідеальний застосунок для мене — це той, що максимально самодостатній на телефоні користувача або в простій інфраструктурі.</p>

<p>Чому це важливо? Бо складний бекенд — це не просто “трохи більше роботи”. Це:</p>

<ul>

<li>більше точок, які можуть зламатися;</li>

<li>більше витрат на підтримку;</li>

<li>більше часу на налагодження;</li>

<li>більше інфраструктурного шуму;</li>

<li>більше ризику, що ви потонете в технічних деталях ще до перевірки попиту.</li>

</ul>

<p>Я не кажу, що бекенд — це погано. Є продукти, де без нього ніяк. Але якщо ідея вимагає складної серверної архітектури вже з першої версії, я дуже сильно підозрюю, що ми намагаємося будувати “дорослу систему” ще до того, як довели базову цінність.</p>

<p>Мені подобаються проєкти, які можна спочатку зробити майже автономними: частина логіки живе на клієнті, дані мінімальні, синхронізація проста, а сервер — це не монстр із мікросервісів, а легка допоміжна частина. Чим менше важкої інфраструктури на вході, тим більше шансів у проєкту дожити до реальності.</p>

<h2>6. Чи легко буде зробити маркетинг?</h2>

<p>Це питання добиває дуже багато “технічно цікавих” ідей. Бо продукт може бути розумний, зручний, елегантний, але якщо я не розумію, як і де його просувати, я не беру його в роботу.</p>

<p>Чудовий продукт без каналу дистрибуції — це мертвий продукт.</p>

<p>Я хочу ще на етапі ідеї бачити хоч приблизну картину маркетингу:</p>

<ul>

<li>чи можна це нормально упакувати в ASO;</li>

<li>чи можна це показати в короткому відео для TikTok, Reels або Shorts;</li>

<li>чи є профільні форуми, спільноти, сабредіти, Telegram-канали або тематичні групи;</li>

<li>чи можна це пояснити однією сильною тезою;</li>

<li>чи є в цього продукту контентний потенціал.</li>

</ul>

<p>Якщо я не бачу канал дистрибуції, я не бачу продукт. Бо маркетинг — це не те, що “додамо потім”. Для інді-проєкту маркетинг — це частина самого дизайну ідеї.</p>

<p>Хороша ідея зазвичай не тільки корисна, а ще й зрозуміла для просування. Її можна зняти на відео, показати в одному сценарії, пояснити через очевидну проблему, упакувати в заголовок, опис, ключові слова і нормальний CTA. Якщо цього немає, значить продукт уже на старті занадто важкий для ринку.</p>

<h2>Що відбувається, коли ідея не проходить хоча б один фільтр</h2>

<p>Найважче в такій системі — не придумати правила. Найважче — реально їх дотримуватись. Бо майже завжди є спокуса “зробити виняток”. І саме винятки найчастіше з’їдають місяці.</p>

<p>У цей момент мозок починає торгуватися:</p>

<ul>

<li>“ну аудиторія не зовсім ясна, але ідея ж прикольна”;</li>

<li>“так, інфраструктура трохи дорога, але ж потенціал великий”;</li>

<li>“так, маркетинг неочевидний, але продукт дуже сильний”;</li>

<li>“так, бекенд складний, але це ж можна якось потім вирішити”.</li>

</ul>

<p>І саме тут треба бути жорстким. Бо якщо ви вже на рівні концепції бачите слабке місце, то після початку розробки воно не зникне. Воно, навпаки, стане дорожчим. У грошах, у часі, у втомі, у переключеннях, у незавершених циклах.</p>

<p>Тому мій підхід простий: якщо ідея не проходить хоча б один критичний фільтр, я не намагаюся “врятувати” її силою волі. Я просто її відсікаю. Можливо, назавжди. Можливо, до кращих умов. Але точно не запускаю в роботу лише тому, що вона мені емоційно подобається.</p>

<h2>Чому такий підхід дає більше свободи, а не менше</h2>

<p>Збоку може здатися, що такий фільтр занадто жорсткий і душить креативність. Насправді все навпаки. Він не забирає свободу. Він прибирає шум.</p>

<p>Коли у вас немає чітких критеріїв, кожна нова ідея виглядає як потенційний шанс. Ви починаєте скакати між концептами, захоплюватися новими напрямками, плодити беклог, не завершувати старе й постійно жити з відчуттям, що “десь поруч є щось краще”.</p>

<p>Чіткий фільтр відрізає цей шум. Він залишає не всі можливі ідеї, а тільки ті, які мають шанс пережити реальність. Саме тому він економить не лише час, а й психіку.</p>

<p>Фокус — це не коли у вас мало варіантів. Фокус — це коли ви вмієте вчасно вбити ті варіанти, які не варті вашого ресурсу.</p>

<h2>Висновок</h2>

<p>На старті найцінніше — не натхнення і не кількість ідей. Найцінніше — вміння відсікти все, що не витримує перевірки реальністю.</p>

<p>Мій фільтр дуже простий: аудиторія, зрозуміла цінність, можливість зібрати MVP без витрат, дешева підтримка, мінімум складного бекенду і зрозумілий маркетинг. Якщо хоча б один із цих блоків сиплеться, я не витрачаю на ідею свій ресурс.</p>

<p>Слабкий проєкт треба вбивати рано. Не після трьох тижнів дизайну. Не після двох місяців розробки. Не після першого болючого релізу. А ще до першого рядка коду.</p>

</blockquote>

<p>Бо що швидше ви відрізаєте утопії, то більше часу залишається на речі, які справді можуть стати продуктом, а не просто красивою фантазією в беклозі.</p>