Як некодер за 45 днів перезапустив BDG‑додаток на Claude Code
Американський підприємець і розробник Остін Марчезе розповідає, як разом із засновником сервісу BDG Ніком повністю перезібрав споживчий додаток для фанатів фентезі‑футболу — і зробив це за 45 днів, спираючись на Claude Code. Нік до цього ніколи не писав код, попередня версія застосунку мала трьох штатних інженерів і майже не рухалася вперед, а оновлений продукт тепер приносить понад $250 000 на рік і обслуговує більше ніж 100 000 користувачів. Ця історія — показовий кейс того, як змінюється розробка споживчих застосунків у добу AI‑асистованого кодування.
Від трьох інженерів до 45 днів: що сталося з BDG
BDG — це споживчий додаток для фанатів фентезі‑футболу. Його цінність не розмазана по десятках функцій: продукт робить дві речі, які логічно доповнюють одна одну — дає інформацію для фентезі‑футболу та дозволяє грати у фентезі‑вікторини.
До перезапуску в BDG була класична команда: троє фултайм‑інженерів, які підтримували застосунок. Попри це, продукт «ледве шипив» нові фічі — розвиток ішов повільно, а технічний борг і складність кодової бази гальмували будь‑які зміни. Для молодого споживчого сервісу в конкурентній ніші це фактично означає стагнацію.
У цей момент Нік, засновник BDG, прийшов до Остіна з радикальним запитанням: чи реально повністю перебудувати застосунок за допомогою AI‑інструменту Claude Code? Відповідь виявилася ствердною — і стала відправною точкою експерименту, який закінчився повноцінним релізом за півтора місяця.
За 45 днів команда з двох людей — один досвідчений інженер і один засновник без технічного бекграунду — з нуля зібрала нову версію BDG. Усі сторінки, усі фічі, весь інтерфейс будувалися через Claude Code. На виході — застосунок, який:
- генерує значно більше ніж $250 000 річного доходу;
- має понад 100 000 користувачів;
- стартував із більш ніж 2 000 платних підписників у день запуску оновленої версії.
Ці цифри важливі не лише як бізнес‑успіх. Вони демонструють, що AI‑асистоване кодування вже здатне замінити традиційну команду розробки в певних сценаріях — за умови правильної організації роботи.
Дві фрази, що тримають продукт: як BDG спростив цінність
Ключ до швидкого перезапуску BDG — радикальне спрощення продукту. Перед тим як відкривати Claude Code, команда сформулювала, яку саме проблему розв’язує застосунок і як це можна описати в одному реченні.
Остін наводить показовий приклад іншого продукту — додатка для підрахунку калорій CaliAI. Його цінність вкладається в одну фразу: «Зроби фото їжі й отримай кількість калорій». Усе: дві екрани, одна дія, зрозумілий результат. Без складних сценаріїв, без десятків вкладок і прихованих можливостей.
BDG пішов тим самим шляхом. Замість того щоб намагатися бути «платформою для всього, що стосується фентезі‑футболу», застосунок сфокусувався на двох доповнювальних сценаріях:
- отримання інформації для фентезі‑футболу;
- гра у фентезі‑вікторини.
Це не 15 різних функцій, а дві, які користувач може легко зрозуміти й одразу почати використовувати. Такий підхід знижує когнітивне навантаження: користувачеві не потрібно розбиратися, «що тут взагалі можна робити». А для команди це означає менший обсяг роботи на старті, чіткіший фокус і швидший шлях до релізу.
Остін формулює принцип, який добре описує цю логіку: абстракція — ворог конверсії. Кожне додаткове запитання, яке користувач змушений поставити собі, зменшує ймовірність, що він узагалі скористається продуктом. Тому перший крок у перезапуску BDG — жорстке звуження й кристалізація ціннісної пропозиції.
«Інженер» проти «пірата»: як розділили роботу між AI і людьми
Ще один принцип, який дозволив перезапустити BDG за 45 днів, — чітке розмежування зон, де потрібна інженерна педантичність, і зон, де можна «піратити», тобто рухатися максимально швидко, експериментувати й не боятися ламати.
Остін описує це як два режими роботи: AI‑інженер і пірат.
Режим інженера — це все, де помилка коштує грошей або довіри користувача. Сюди входять:
- автентифікація та логін;
- платежі;
- робота з користувацькими даними;
- архітектура бази даних;
- критичні бізнес‑процеси.
У цих зонах команда сповільнюється, ретельно перевіряє кожну зміну, двічі думає, перш ніж деплоїти. Тут AI виступає радше як помічник, а не як автономний автор рішень.
Режим пірата — усе інше: контентні сторінки, екрани налаштувань, інтерфейс, нові не критичні фічі, кольори кнопок. Тут можна дозволити собі швидкі ітерації, проби й помилки, часті правки. Якщо щось зламається, це не призведе до втрати грошей або даних — а отже, ризик прийнятний.
У кейсі BDG розподіл виглядав так:
- Остін узяв на себе «інженерну» частину: автентифікацію, платежі, інфраструктуру — усе, де збій міг би вдарити по сотнях тисяч доларів доходу й довірі понад 2 000 платних клієнтів на старті.
- Нік, засновник без досвіду програмування, працював у режимі пірата: заходив у Claude Code, описував, які фічі хоче бачити, надсилав скриншоти, просив «зробити ось так», змінював UI, додавав нові екрани.
Фактично Нік займався «вайб‑кодингом» — формулював бажаний результат природною мовою, а Claude Code перетворював це на робочий інтерфейс. За оцінкою самого Ніка, такий підхід дозволяє некодеру пройти 90–95% шляху до готового продукту. Однак останні 5–10% — це все ще зона відповідальності «дорослого в кімнаті», який розуміє безпеку, архітектуру й ризики.
Щоб зробити цей поділ ще чіткішим, Остін використовує Claude MD — файл контексту, який передається моделі при кожному зверненні. Він пропонує прямо в цьому файлі позначати критичні робочі процеси й просити Claude попереджати перед будь‑якими змінами в цих зонах. Це створює своєрідну «пам’ять» для AI: модель знає, де потрібно рухатися повільно, а де можна експериментувати.
Як некодеру стати ефективним із AI: вивчити терміни, а не синтаксис
Один із найцікавіших висновків із кейсу BDG стосується ролі технічних знань. Нік не вчився програмуванню в класичному сенсі — не розбирався в синтаксисі мов, не заглиблювався в алгоритми. Натомість він опановував технічну лексику.
Остін формулює це так: некодерам не потрібно вчитися коду, їм потрібно вчитися словнику. AI‑моделі, зокрема Claude Code, тренувалися на величезних масивах технічної документації, кодових баз і статей. Вони чудово розуміють усталені терміни. Коли користувач використовує правильне слово, модель майже безпомилково вгадує, що саме потрібно зробити. Коли ж термінологія розмита, AI змушений здогадуватися — і не завжди влучає.
Різниця між «чудовим результатом» і «фрустрацією» часто зводиться до одного слова. У BDG це проявилося на прикладі реального функціоналу: спільної дошки драфту, де кілька користувачів одночасно взаємодіють і мають бачити дії одне одного в реальному часі.
Якби некодер описав задачу фразою «мені потрібно, щоб користувачі бачили дії інших миттєво, без перезавантаження сторінки», Claude Code, швидше за все, реалізував би це через polling — періодичні запити до сервера, які імітують «живе» оновлення. Технічно це працює, але має серйозний недолік: сторінка кожного користувача робить запит до бази даних кожні кілька секунд. За тисячі одночасних підключень це перетворюється на тисячі зайвих запитів за хвилину, що може просто «покласти» застосунок.
Якщо ж у запиті до Claude Code з’являється одне слово — «використай web sockets» — модель будує зовсім інше рішення: постійне з’єднання в реальному часі без безперервного опитування бази. Менше навантаження, стабільніша робота, кращий досвід для користувачів.
BDG пройшов через цю помилку на власному досвіді. І саме вона підкреслила головний урок: для роботи з AI‑кодерами некодеру достатньо знати базові технічні терміни — від web sockets до modal, toast notification, responsive design, «щасливий» і «нещасливий» сценарій. Це не вимагає років навчання, але радикально підвищує якість взаємодії з моделлю.
Остін навіть підготував спеціальний промпт, який охоплює близько 40 таких термінів і дозволяє Claude Code пояснити їх у контексті конкретного проєкту. Для Ніка йому подібних це стало швидким способом «підтягнути словник» і почати говорити з AI однією мовою.
Безпека швидкості: як BDG не зламався під час росту
Швидкий розвиток — одна з головних переваг AI‑асистованої розробки, але водночас і головне джерело ризиків. Якщо постійно рухатися в режимі пірата, рано чи пізно щось зламається — і вже не в тестовому середовищі, а в руках реальних користувачів.
У BDG це розуміли з самого початку, тому поверх швидкості вибудували систему запобіжників. Вона складалася з кількох рівнів.
По‑перше, планування перед написанням коду. Перед тим як реалізовувати нову фічу, Остін просив Claude Code не писати код, а… ставити запитання. Модель мала з’ясувати, яку саме проблему розв’язує функція, для кого вона, як виглядає успіх і чого фіча робити не повинна. Лише після цього Claude формував резюме вимог — і тільки тоді починався етап реалізації.
Це звучить як зайва бюрократія, але на практиці економить години. Без такого етапу запит «зроби мені сторінку налаштувань» перетворюється на десятки ітерацій: AI щось будує, засновник уточнює, просить переробити, додає поля, видаляє зайве. Замість трьох годин хаотичних правок можна витратити десять хвилин на чітке формулювання вимог — і отримати потрібний результат із першої спроби.
По‑друге, автоматизований code review. Після кожної фічі, перед тим як випустити її для тисяч користувачів, команда запускала перевірку коду — не вручну, а через спеціальний skill у Claude Code. Було створено дві команди: умовний «/code review» для пошуку проблем у коді та «prepare to deploy» для перевірки готовності до продакшену.
Ці команди працювали як обов’язковий чек‑пойнт і для Остіна з восьмирічним досвідом розробки, і для Ніка, який покладався на «вайб‑кодинг». AI не просто давав рекомендації — він повертав чітку відповідь, чи готовий код до деплою, і, якщо ні, пояснював, що потрібно виправити. За словами Остіна, це врятувало BDG від десятка потенційних поломок.
По‑третє, чистота кодової бази. Хоча в наданому фрагменті розмова про це лише починається, контекст зрозумілий: швидкі ітерації через AI легко перетворюють проєкт на хаотичний набір файлів і патчів. Для застосунку з понад 100 000 користувачів це прямий шлях до технічного боргу, який знову загальмує розвиток — як це сталося з попередньою версією BDG.
Поєднання цих практик — планування, автоматизованого рев’ю й дисципліни в роботі з кодом — дозволило команді одночасно рухатися швидко й не ламати продукт під навантаженням реальних користувачів і реальних грошей.
Що означає кейс BDG для майбутнього розробки
Історія BDG — це не просто успішний перезапуск одного застосунку. Вона демонструє кілька ширших тенденцій, які вже змінюють індустрію.
По‑перше, роль некодерів у створенні продуктів радикально зростає. Засновник без технічного бекграунду, озброєний AI‑кодером і базовим технічним словником, може самостійно будувати більшість користувацьких фіч. Це не скасовує потребу в досвідчених інженерах, але зміщує їхню роль у бік архітектури, безпеки й критичних систем.
По‑друге, швидкість розробки перестає бути лінійною функцією розміру команди. Попередня версія BDG із трьома фултайм‑інженерами «ледве шипила» фічі. Нова версія, створена двома людьми за 45 днів із Claude Code, не лише вийшла на ринок, а й одразу стартувала з понад 2 000 платних користувачів і вийшла на шестизначний річний дохід.
По‑третє, архітектура продукту й чіткість ціннісної пропозиції стають важливішими за кількість функцій. BDG не намагався охопити все — він сфокусувався на двох сценаріях, які добре працюють разом. Те саме видно й у прикладі CaliAI: один простий use case, зрозумілий будь‑кому за секунду.
По‑четверте, AI‑асистоване кодування вимагає нової дисципліни. Без поділу на «інженерні» й «піратські» зони, без позначення критичних робочих процесів у Claude MD, без планування й автоматизованого рев’ю швидкість легко перетворюється на хаос. BDG показує, що поєднання AI‑інструментів із продуманими процесами дозволяє уникнути цього сценарію.
Нарешті, кейс BDG ставить запитання про те, як виглядатимуть команди майбутнього. Якщо один досвідчений інженер може забезпечити фундамент — автентифікацію, платежі, інфраструктуру, — а засновник‑некодер разом із AI бере на себе більшість користувацьких фіч, традиційна структура «велика команда розробки + окремий продукт» може виявитися надмірною для значної частини споживчих застосунків.
Висновок: 45 днів, 100 000 користувачів і нова норма
Перезапуск BDG — це концентрований приклад того, як AI‑інструменти на кшталт Claude Code змінюють правила гри в розробці споживчих продуктів. За 45 днів двоє людей — один інженер і один засновник без досвіду коду — створили з нуля застосунок, який:
- обслуговує понад 100 000 користувачів;
- стартував із більш ніж 2 000 платних клієнтів;
- генерує річний дохід, що суттєво перевищує $250 000.
Цей результат став можливим завдяки трьом речам: радикальному спрощенню ціннісної пропозиції, чіткому поділу між критичними й некритичними зонами продукту та ставці на технічну лексику замість класичного навчання програмуванню.
Усе це не означає, що «AI замінить розробників». Швидше, змінюється конфігурація: досвідчені інженери будують фундамент і захищають бізнес‑критичні частини, тоді як засновники й продакт‑менеджери, озброєні Claude Code та базовим технічним словником, беруть на себе більшу частину користувацьких фіч. BDG показує, що в цій моделі можна не лише швидко шипити, а й будувати реальний, прибутковий продукт.
Джерело
How I Built a $481k App With Claude Code (Beginner Strategy)