Developer Mode vs Store

1. Вступ

У попередніх лекціях ми вже говорили про те, що таке ChatGPT App, з яких компонентів він складається та чим відрізняється від старих плагінів і «просто ботів» на OpenAI API. Тепер переходимо до другої важливої теми — життєвого циклу такого застосунку.

Якщо ви вже кілька років пишете вебсервіси, слово «lifecycle» вас навряд чи лякає. У будь‑якого продукту є доволі прямолінійний шлях: «написали локально → розгорнули на staging → розгорнули на production → інколи щось зламали → полагодили». В екосистемі ChatGPT із App загальна логіка така сама, але є нюанси. Зʼявляється Developer Mode усередині самого ChatGPT і окрема сутність — Store.

Важливо чітко розрізняти дві площини:

1. Де фізично живе ваш код: локальний сервер Next.js, Vercel, якийсь Kubernetes‑кластер тощо. Це ваш світ — ви повністю його контролюєте.
2. Як ChatGPT бачить ваш App: як набір метаданих, URL і дозволів. Його можна або під’єднати в Developer Mode, або оформити як готовий продукт у Store. Це вже світ OpenAI зі своїми правилами, ревʼю та користувачами.

Ця лекція — саме про другу площину. Ми спиратимемося на звичну модель середовищ (dev / staging / prod), але подивимося на неї очима ChatGPT. Мета проста: щоб ви будь‑якої миті могли відповісти собі на кілька запитань. Який саме код зараз запускає мій App? Хто його бачить? Як безпечно експериментувати? І що взагалі означає «оновити App» у Store?

2. Developer Mode: особиста пісочниця всередині ChatGPT

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

Developer Mode — це спеціальний режим у ChatGPT, у якому ви можете підʼєднувати свої ChatGPT Apps напряму за URL — без ревʼю, без публікації App у Store і без показу App всьому світу. За відчуттями це схоже на localhost:3000 у браузері — тільки у світі ChatGPT.

Як це виглядає концептуально

Найпростіше уявити схему так:

flowchart TD
    User("ChatGPT UI (Dev Mode)")
    AppConfig["Dev‑конфігурація App (URL + метадані)"]
    AppServer["Ваш App‑сервер (Next.js + Apps SDK)"]

    User -->|запит у чаті| ChatGPTCore[GPT]
    ChatGPTCore -->|потрібен App| AppConfig
    AppConfig --> AppServer
    AppServer -->|UI/інструменти| ChatGPTCore
    ChatGPTCore --> User

Ви, як розробник, у налаштуваннях Developer Mode кажете ChatGPT: «Ось мій App, ось його URL, ось як він називається і що вміє». Після цього ChatGPT починає вважати вказаний URL джерелом вашого застосунку. Поки ви не подали App у Store, бачити його будете лише ви (і, можливо, інші учасники команди, якщо додасте їх як розробників).

Технічні деталі підʼєднання (HTTPS‑тунель, Vercel та інші радощі) ми розберемо далі. Тут важливо зрозуміти саму ідею: Developer Mode — це «динамічний ярлик» на ваш dev‑сервер, який ChatGPT уміє викликати.

Як увімкнути Developer Mode

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

• Перейдіть за посиланням https://chatgpt.com/#settings/Connectors/Advanced або зайдіть у Settings -> Connected apps -> Advanced.
• Developer Mode - ON

Щойно ви це зробите, зʼявиться кнопка Create App.

Чим Developer Mode відрізняється від production

Різниця дуже схожа на відмінність dev‑середовища від production у звичайному вебі. Водночас є кілька специфічних моментів.

По‑перше, видимість. Ваш App у Developer Mode, як правило, недоступний звичайним користувачам ChatGPT. Його бачите лише ви і, можливо, учасники вашої організації з відповідними правами. Тож можна експериментувати, не боячись, що випадкова людина натрапить на напівзламаний UX.

По‑друге, стабільність і експерименти. У Developer Mode ви можете змінювати код хоч кожні дві хвилини: підіймати локальний сервер, зупиняти його, перезапускати тунель. ChatGPT намагатиметься звертатися за вказаним URL, але не «образиться», якщо ви іноді повертаєте 500 або взагалі не відповідаєте. Для dev‑режиму це нормально.

По‑третє, дозволи та політики. У Developer Mode вам простіше випробовувати різні конфігурації. Але важливо памʼятати: політики контенту й базової безпеки не вимикаються навіть у dev‑режимі. ChatGPT не дозволить вам раптово перетворитися на «хакерський App для всього». Водночас вимоги ревʼю Store тут ще не застосовуються: можна обійтися без ідеального лістингу, виполірованої іконки тощо.

І нарешті, у Developer Mode зазвичай легше діагностувати проблемні місця. Ви можете швидко змінювати логіку, бачити, які запити йдуть від ChatGPT до вашого сервера, і коригувати поведінку, не думаючи про «міграції користувачів».

Ми вже подивилися на Developer Mode як на особисту пісочницю для застосунків і трохи зазирнули в бік Store. Тепер зберімо все це в зрозумілу «машину станів» життєвого циклу App.

3. Стани ChatGPT App: від чернетки до зняття з публікації

Оформімо це як «машину станів» для вашого App. Умовно поговоримо про чотири основні стани: Draft / Dev‑only, Under review, Published і Paused/Removed.

Машина станів життєвого циклу

Спробуємо намалювати це як діаграму:

stateDiagram-v2
    [*] --> Draft

    Draft: Dev Mode / чернетка
    Review: Under review (Store)
    Published: У Store, доступний користувачам
    Paused: Paused / Removed

    Draft --> Review: Надіслати на рев’ю
    Review --> Draft: Відхилено / повернути на доопрацювання
    Review --> Published: Схвалено
    Published --> Paused: Поставити на паузу / зняти
    Paused --> Draft: Відновити роботу в dev-режимі
    Draft --> Published: Внутрішній rollout без Store (для організації)

У стані Draft ваш App існує лише як dev‑ресурс. Ви можете підʼєднати його в Developer Mode, пробувати різні можливості, але не показувати його в Store.

Коли ви вирішуєте, що App час показувати людям, ви надсилаєте його «на ревʼю» — це стан Under review. Тут OpenAI (або внутрішня система перевірки у вашій організації) оцінює відповідність політикам, стабільність, базову безпеку та адекватність UX.

Якщо все добре, App переходить у Published: він зʼявляється в Store або стає доступним користувачам вашої компанії (якщо це корпоративний сценарій). Від цього моменту до нього приходять реальні користувачі, а всі зміни в коді та конфігурації доведеться планувати обережніше.

Якщо ж ви тимчасово не хочете, щоб App був доступний, його можна перевести в стан Paused/Removed. У стані Paused він прихований від нових користувачів, але може продовжувати працювати для вже розпочатих сесій або взагалі вимикатися. Деталі залежать від реалізації платформи та налаштувань.

4. Store: коли ваш App стає продуктом

Developer Mode — це ваш особистий гараж. Store — це вже офіційний дилерський центр. Тут у гру вступають користувачі, рейтинг, правила лістингу та ревʼю.

Що змінюється, коли ви виходите в Store

Перше й головне: ваш App стає «продуктом». У нього зʼявляється лістинг: назва, опис, іконка, категорії, іноді стартові підказки для діалогу. За цими метаданими ChatGPT у Store шукатиме та рекомендуватиме ваш застосунок користувачам, а сама модель — розумітиме, у яких сценаріях App релевантний.

Друга важлива річ — ревʼю та політики. Перш ніж App зʼявиться в Store, його перевірять на відповідність вимогам безпеки, змісту та UX. Це означає, що:

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

Про політики та пісочницю ми ще докладно поговоримо в наступних лекціях. А поки корисно сприймати Store як місце, куди варто приносити лише відносно «виховані» версії свого App.

Третя річ — відповідальність за стабільність. Поки ви експериментуєте в Developer Mode, ваші падіння — це передусім ваша проблема. У Store від вашого App очікують належної доступності, прийнятної затримки та відсутності «червоних екранів смерті» у віджеті. У пізніших модулях ми говоритимемо про SLO, метрики й ревʼю Store саме в цьому контексті.

Версії: dev проти production

Типове питання: «Якщо я оновлю код, що побачить користувач?». У світі ChatGPT Apps корисно мислити одразу двома «гілками»:

• dev‑гілка, яка підʼєднана до Developer Mode і може вказувати на dev‑сервер поруч із вашою IDE;
• production‑гілка, яка асоційована з опублікованою конфігурацією в Store і вказує на стабільний URL.

З погляду архітектури це можна виразити навіть за допомогою невеликого TypeScript‑типу у вашому проєкті:

type AppStage = 'dev' | 'production';

interface ChatGPTAppConfig {
  id: string;
  stage: AppStage;
  endpointUrl: string;
}

const giftGeniusDev: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'dev',
  endpointUrl: 'https://dev.giftgenius.example.com',
};

const giftGeniusProd: ChatGPTAppConfig = {
  id: 'giftgenius',
  stage: 'production',
  endpointUrl: 'https://app.giftgenius.example.com',
};

У реальному житті конфігурацію зберігає не ваш код, а платформа ChatGPT. Але подібні структури допомагають тримати в голові, що це два різні «образи» одного й того самого App.

Реліз ChatGPT App більше схожий на реліз застосунку в Apple App Store, ніж на оновлення сайту. Ваші віджети й MCP tools щоразу кешуються під час релізу застосунку. А ревʼю може тривати 2 тижні. Тож ніяких «розгорнемо в production, і там дотестимо». На ревʼю варто віддавати вже повністю протестований і стабільний застосунок.

5. Організаційний контекст: особистий обліковий запис vs компанія

Ми вже розділили App на dev‑ і production‑гілки та подивилися, як це відбивається в Store. Є ще один важливий вимір життєвого циклу — організаційний: «де саме» живе ваш застосунок.

У найпростішому випадку ви робите App як приватна особа у своєму особистому ChatGPT Plus. Тоді Developer Mode — суто ваш, а Store теж привʼязаний до вашого облікового запису. Усе відносно просто: зробили для себе, виклали, потішили світ.

Але дуже часто ChatGPT Apps живуть у корпоративному контексті. Тоді зʼявляється кілька додаткових ролей. Є адміністратори організації, які вирішують, які Apps доступні співробітникам, які треба заблокувати, а які можна дати лише пілотній групі. Ваш App можуть опублікувати не для всього світу, а лише для конкретної компанії — або навіть для окремих підрозділів.

У такому сценарії життєвий цикл може виглядати так: спочатку App існує лише як dev‑проєкт усередині команди. Потім зʼявляється «внутрішній production» — доступний, наприклад, лише відділу продажів для пілота. І лише потім, якщо все пішло добре, ви вирішуєте надіслати App у глобальний Store і зробити його зовнішнім продуктом.

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

6. Практичний сценарій: життєвий цикл GiftGenius

Щоб усе сказане не залишилося абстракцією, подивімося на умовний App GiftGenius — помічник із підбору подарунків, який супроводжуватиме нас протягом курсу.

Етап 1. Ідея і чернетковий прототип у Developer Mode

Ви вирішуєте зробити GiftGenius: App, який запитує в користувача, кому потрібен подарунок, на який бюджет він розраховує та які інтереси в отримувача. А потім пропонує варіанти, використовуючи ваш каталог товарів.

На першому кроці ви:

1. підіймаєте простий проєкт Next.js з мінімальним віджетом;
2. вмикаєте Developer Mode у ChatGPT і додаєте туди URL свого dev‑сервера;
3. проводите кілька тестових діалогів: просите GPT «Допоможи вибрати подарунок другові‑геймеру до 50 $» і дивитеся, як він викликає ваш App, рендерить віджет і як у підсумку виглядає UX.

На цьому етапі ви не думаєте про Store, ревʼю чи гарні іконки. Завдання інше — довести собі й команді, що ідея взагалі працює і що платформа ChatGPT дозволяє реалізувати потрібний сценарій.

Етап 2. Зміцнення прототипу та внутрішня «альфа»

Коли ви переконалися, що базовий сценарій працює, починається етап «зміцнення». Ви:

• приводите логіку до більш‑менш зрозумілої структури;
• починаєте думати про те, які дозволи та дані насправді потрібні App;
• перевіряєте, як App поводиться під час помилок (наприклад, коли каталог товарів не відповідає).

Усе ще в Developer Mode, але вже не наодинці: ви додаєте колег як розробників або тестувальників, щоб вони теж могли підʼєднати App до свого ChatGPT. Життєвий цикл на цьому етапі все ще обертається навколо стану Draft. Ви швидко оновлюєте код, пробуєте різні UX‑патерни та обговорюєте зворотний звʼязок усередині команди.

Етап 3. Підготовка до Store і ревʼю

На цьому кроці ви вирішуєте: «Так, GiftGenius уже достатньо пристойний, щоб показати його зовнішнім користувачам». Тепер фокус зміщується з коду на продуктове пакування:

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

Це момент переходу зі стану Draft в Under review. Ви надсилаєте App на ревʼю, і певний час він живе в цьому проміжному стані. Можливо, вам надійдуть зауваження: потрібно уточнити політику конфіденційності, виправити формулювання, звузити дозволи. Ви повертаєтеся в Draft, доробляєте — і надсилаєте знову.

Етап 4. Публікація і «справжнє життя»

Після схвалення ваш GiftGenius опиняється в стані Published. Тепер його можуть знаходити користувачі в Store, ChatGPT може пропонувати його за релевантними запитами, а ви починаєте збирати реальний зворотний звʼязок, дивитися на використання і думати про масштабування.

Відтепер кожна зміна коду — це не просто «я швидко дороблю функцію». Це міні‑реліз. Вам потрібно думати про зворотну сумісність, продумувати міграції, а за можливості — спочатку змінювати dev‑версію, перевіряти її й лише потім оновлювати production‑конфігурацію.

За потреби ви можете тимчасово перевести App у Paused. Наприклад, якщо знайшли критичну вразливість або ваш бекенд не справляється з навантаженням. Але ідеальна картина — поступово розвивати Published‑гілку, не забуваючи про dev‑середовище для експериментів.

7. Як розробнику думати про середовища: dev, staging, production + Developer Mode

На прикладі GiftGenius ми пройшли шлях від ідеї в Developer Mode до опублікованого App. Тепер давайте вкладемо це у звичну для розробника схему середовищ — dev/staging/production — і подивимося, як вона співвідноситься з Developer Mode та Store.

Найчастіше зручно тримати в голові таку матрицю:

Developer Mode, по суті, «приклеюється» до вашої dev‑ або staging‑інфраструктури: ви публікуєте туди тимчасовий URL, який ChatGPT використовує для тестів. Конфіг Store при цьому вказує на вже дорослий production‑URL.

У майбутньому, коли ми говоритимемо про деплой на Vercel і тунелі, ця матриця перетвориться на набір цілком конкретних кроків. Але вже зараз корисно тримати просту ідею: завжди віддавайте собі звіт, куди потрапляє поточний запит ChatGPT — у вашу dev‑пісочницю чи в бойове середовище, куди ходять користувачі.

8. Невеличкий «шматочок коду» про життєвий цикл

Щоб повʼязати все це зі звичним для вас TypeScript‑підходом, опишімо простий тип, який відображає життєвий цикл App вже не на рівні платформи, а на рівні вашого власного інструментарію. Його можна покласти в репозиторій, щоб не плутатися в різних станах.

type AppLifecycleState = 'draft' | 'under_review' | 'published' | 'paused';

interface LifecycleSnapshot {
  id: string;
  name: string;
  state: AppLifecycleState;
  lastDeployedAt: Date | null;
  devUrl?: string;
  prodUrl?: string;
}

const giftGeniusLifecycle: LifecycleSnapshot = {
  id: 'giftgenius',
  name: 'GiftGenius – підбір подарунків',
  state: 'draft',
  lastDeployedAt: null,
  devUrl: 'https://dev.giftgenius.example.com',
};

Такий обʼєкт ви ніколи не відправите в ChatGPT, але він допомагає команді залишатися в одному контексті. Можна навіть зробити простенький CLI, який показує стан усіх ваших Apps, щоб не плутатися: де чернетка, а де вже щось, що знаходиться в Store.

У наступних модулях ми постійно повертатимемося до цієї моделі життєвого циклу: коли налаштовуватимемо тунелі й деплой на Vercel, проєктуватимемо MCP‑сервер і агентні сценарії, продумуватимемо комерційні флоу та підготовку до ревʼю в Store. Думайте про Developer Mode і Store як про два полюси однієї системи: пісочницю для експериментів і вітрину для вже дорослого продукту.

9. Типові помилки під час роботи з Developer Mode і Store

Помилка № 1: «Одразу в Store, а там розберемося».
Іноді хочеться якнайшвидше «захопити ринок» і викласти App у Store ще на стадії напівпрацюючого прототипу. Це майже гарантовано призводить до негативних відгуків користувачів, поганої статистики використання і додаткових запитань на ревʼю. Значно здоровіше спершу зробити кілька ітерацій у Developer Mode, зібрати зворотний звʼязок від колег і друзів, стабілізувати базовий UX — і лише потім іти в Store.

Помилка № 2: Змішування dev‑ і production‑середовищ.
Типовий сценарій: ви налаштовуєте Developer Mode на той самий URL, що й production, а потім дивуєтеся, чому «пару відладочних змін» раптово побачили реальні користувачі. Розводити dev‑ і prod‑URL потрібно так само акуратно, як ви це робите для звичайних вебсервісів. Якщо в конфігурації ChatGPT App стоїть production‑URL, не використовуйте його для «швидких експериментів увечері».

Помилка № 3: Відсутність чіткого уявлення про стани.
Коли розробники не усвідомлюють, у якому стані живе App (Draft, Under review, Published, Paused), виникають дивні ситуації: хтось у команді думає, що App уже в Store, а хтось інший усе ще вважає його локальним прототипом. Варто хоча б у README проєкту описати, де зараз App і що потрібно зробити для переходу на наступний етап.

Помилка № 4: Ігнорування політик і ревʼю до останнього моменту.
Деякі команди пишуть App «ніби це просто сайт», а про політики, дозволи й вимоги Store згадують за день до відправлення на ревʼю. У результаті виявляється, що потрібно серйозно переробляти збір і зберігання даних, переписувати описи та звужувати права. Краще тримати ці рамки в голові з самого початку й у Developer Mode одразу експериментувати з чесними, мінімальними дозволами.

Помилка № 5: Відсутність окремої стратегії для внутрішнього і зовнішнього використання.
Якщо App спочатку створюється як внутрішній корпоративний інструмент, а потім хочеться зробити з нього публічний продукт, легко переплутати цільову аудиторію. Усередині компанії можна дозволити собі менш «вітринковий» UX і складніші сценарії. У зовнішньому Store користувачі очікують іншого рівня зручності. Нерозуміння, у якому режимі ви перебуваєте зараз, призводить до того, що публічний App виглядає як внутрішній адмінський інструмент, а внутрішній пілот «застрягає», бо ви надто рано думаєте про глобальний Store.

Помилка № 6: Відсутність звʼязки між Developer Mode і спостережуваністю.
Developer Mode чудово підходить для відладки, але цією перевагою варто користуватися. Якщо ви не дивитеся логи й не фіксуєте, які саме запити ChatGPT надсилає у ваш App у dev‑середовищі, то пізніше, у production, на вас можуть чекати неприємні сюрпризи. Краще використовувати Developer Mode як майданчик для вивчення реальної поведінки моделі й користувачів, а не лише для перевірки «чи віджет компілюється».