Технічне завдання на мобільний застосунок: шаблон на 1 сторінку

Технічне завдання на мобільний застосунок: коротка відповідь

Добре технічне завдання на мобільний застосунок, коли ти створюєш власний застосунок, вміщується на одній сторінці. Воно відповідає на десять запитань: для кого, яка проблема, яка головна функція, як застосунок заробляє гроші, що відбувається без акаунта, які дані мають зберегтися, на якій платформі, що не входить у першу версію, як ти зрозумієш, що все працює, і з якими обмеженнями. Шаблон для копіювання нижче. Також можеш завантажити шаблон і чекліст перевірки (.md) без реєстрації.

Шаблони на 40 сторінок, які ти знайдеш в інтернеті, написані для іншого: для клієнта, що замовляє застосунок у підрядника і потребує документа для договору. Ти ж водночас і ухвалюєш рішення, і будуєш, часто з допомогою ШІ. Твоє ТЗ потрібне для двох речей: ухвалити рішення до того, як писати код, і дати Claude, ChatGPT чи Cursor чіткий контекст, щоб вони збудували саме той застосунок.

Я публікую власні iOS-застосунки. Solys, будильник із міні-іграми, і TradaZen, симулятор трейдингу, є в App Store. Nolera і Clic Apple відхилила, потім я їх виправив. Це метод, який я застосовую до кожного з них, і саме його я тобі пропоную.

Чому однієї сторінки достатньо, щоб окреслити власний застосунок

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

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

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

Що має містити технічне завдання на мобільний застосунок?

Відповідай на кожне з цих запитань одним-двома реченнями.

1. Хто користується застосунком і в якій ситуації? Не «люди 18-35 років». Краще конкретна людина в конкретний момент її дня.
2. Яку проблему розв'язує застосунок, одним реченням? Якщо тобі потрібне «а ще», ти описуєш два застосунки.
3. Яка ГОЛОВНА функція першої версії? Лише одна. Решта почекає на цифри. На сторінці MVP iOS-застосунку пояснюю, як обрати.
4. Як застосунок заробляє гроші? Підписка, разова покупка чи безкоштовно. Ця відповідь змінює застосунок уже з першого екрана. Якщо вагаєшся, прочитай підписка чи разова покупка для iOS-застосунку.
5. Що можна робити без створення акаунта? Якщо рано вирішиш, що доступно без реєстрації, тобі не доведеться переробляти весь онбординг.
6. Які дані мають пережити зміну телефона? Саме це запитання вирішує, чи потрібен тобі бекенд на зразок Supabase, чи все може лишатися на пристрої.
7. Лише iOS чи iOS і Android? Моя порада новачкам: спершу iOS. Чому, детально пояснюю в статті застосунок для iOS і Android одночасно.
8. Що явно НЕ входить у першу версію? Найкорисніший розділ документа. Він обриває суперечки ще до їхньої появи, і з самим собою, і з ШІ.
9. Як ти зрозумієш, що все працює? Один сигнал, який можна виміряти в перші тижні після релізу: запущені безкоштовні пробні періоди, підписники, користувачі, які повертаються.
10. Які в тебе реальні обмеження? Час, який ти можеш приділяти щотижня, твоє обладнання і твій акаунт Apple Developer, що коштує 99 $ на рік. Немає Mac? Це не перешкода, як я пояснюю в статті опублікувати iOS-застосунок без Mac.

Шаблон технічного завдання для копіювання

Скопіюй цей шаблон у нотатку або в текстовий файл у корені проєкту, потім заміни кожен рядок.

• Робоча назва застосунку: …
• Для кого: людина, яка … у момент, коли …
• Проблема, яку розв'язує, одним реченням: …
• Головна функція версії 1: …
• Що користувач бачить, коли вперше відкриває застосунок: …
• Бізнес-модель: підписка / разова покупка / безкоштовно, і що саме платне: …
• Без акаунта можна: …
• Дані, які треба зберегти при переході на інший телефон: жодних / …
• Платформа: спершу iOS (Android пізніше, якщо цифри дозволять)
• Поза версією 1: …, …, …
• Сигнал успіху: …
• Стек: React Native, Expo, Supabase, якщо потрібні акаунти, RevenueCat для підписок
• Обмеження: … годин на тиждень, акаунт Apple Developer відкритий чи ні, є Mac чи ні
• Застосунки, досвід яких мені подобається, і чому: …

Додай три-п'ять скриншотів застосунків, які тобі подобаються, з коротким коментарем, що саме тобі в них до вподоби. Це наочніше за брендбук і для тебе, і для ШІ.

Технічне завдання не є списком бажань. Це список ухвалених рішень.

Приклад: заповнена сторінка для вигаданого застосунку

Щоб побачити потрібний рівень деталізації, ось шаблон, заповнений для вигаданого застосунку, таймера для навчання.

• Для кого: студент, який увечері навчається сам і відволікається вже через десять хвилин.
• Проблема: він не може витримати навчальну сесію, не торкаючись телефона.
• Головна функція: запустити сесію з таймером і бачити свою серію днів.
• Перший екран: одна кнопка, щоб почати сесію.
• Бізнес-модель: підписка на детальну статистику, базова сесія безкоштовна.
• Без акаунта: усе, крім збереження даних між двома телефонами.
• Поза версією 1: груповий режим, рейтинг серед друзів, віджети, версія для Android.
• Сигнал успіху: користувачі, які повертаються кілька днів поспіль.

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

Як використовувати технічне завдання, щоб скеровувати ШІ

Саме тут твоя сторінка дає найбільшу віддачу. ШІ, що пише код без контексту, вгадує, і часто вгадує зовсім інший застосунок.

Поклади сторінку в постійний контекст проєкту. Claude Code читає файл CLAUDE.md у корені, у Cursor є власні файли правил. Встав туди своє ТЗ разом зі стеком. Тоді кожен запит починається з тієї самої бази.

Посилайся на розділ «поза версією 1», коли ШІ перестарається. Асистенти охоче пропонують зайві функції: темну тему, можливість поділитися, сповіщення. Твій список винятків дає готову відповідь: не зараз.

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

Давай йому перечитати сторінку, а не лише код. Запитай: «які пункти цього ТЗ розмиті або суперечливі?». Це недооцінений спосіб використання ШІ, і він вбереже тебе від тижнів роботи в хибному напрямку.

Якщо хочеш заглибитися, я детально розписав пастки й перевірки в статті створити iOS-застосунок за допомогою ШІ.

Як перетворити рішення на критерії перевірки

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

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

Ось заповнена таблиця для нашого вигаданого таймера. Це критерії для перевірки, а не вже пройдені тести:

Рішення з ТЗ	Що перевірити	Очікуваний результат
Базова сесія доступна без акаунта	Встановити застосунок і запустити сесію без реєстрації	Жодна форма реєстрації не блокує запуск
Перервана сесія не зараховується в серію	Зупинити сесію до кінця, потім відкрити історію	Жодної завершеної сесії не додано
Історія зберігається на пристрої	Завершити сесію, закрити й знову відкрити застосунок	Сесія з'являється лише один раз із правильною тривалістю
Базовий таймер працює без мережі	Увімкнути авіарежим і завершити сесію	Таймером і локальним збереженням можна користуватися
Детальна статистика платна	Відкрити статистику без підписки	Показується пропозиція; базова сесія залишається доступною

Питання, які ще розмиті, стають рішеннями, які треба ухвалити. Наприклад: що робити, якщо користувач блокує екран або змінює час на телефоні під час сесії? Не дозволяй агентові мовчки вирішувати за тебе. Опиши бажану поведінку, потім додай цей випадок у таблицю. Щоб організувати таке тестування на реальному встановленні, скористайся гайдом тестувати свій застосунок для iPhone через TestFlight.

Як вирішити, що прибрати, коли перша версія розростається

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

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

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

Пастка каталогу функцій

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

Добра перша версія робить одну річ і робить її добре. Але остерігайся й протилежної крайності: Apple вимагає, щоб застосунок був чимось більшим за обгорнутий вебсайт, згідно з правилом 4.2 App Review Guidelines. Одна головна функція: так; порожня оболонка: ні, це підстава для відмови за guideline 4.2.

Чого не має бути в технічному завданні на мобільний застосунок

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

Коли оновлювати технічне завдання?

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

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

Від сторінки до опублікованого застосунку

Якщо ти відповів на десять запитань, ти вже зробив роботу, яку багато проєктів пропускають. Далі треба збудувати головну функцію, протестувати її на своєму iPhone, підключити підписки й підготувати все для Apple.

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

Не знаєш, чи твоя ідея вже готова вміститися на одну сторінку? Безкоштовна діагностика покаже, що зараз блокує твій проєкт і з якого етапу почати. А на головній сторінці показано, як створити мобільний застосунок на основі цього ТЗ за допомогою Claude Code.

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

Поширені запитання

Як скласти технічне завдання на мобільний застосунок?

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

У якій програмі писати технічне завдання на застосунок?

Звичайна нотатка або текстовий файл у корені проєкту: копіюєш туди шаблон і замінюєш кожен рядок. Також можеш завантажити шаблон і чекліст перевірки (.md) без реєстрації. Щоб скеровувати ШІ, потім поклади його у файл контексту проєкту.

Чи потрібне технічне завдання на 40 сторінок для застосунку?

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

Як передати технічне завдання ШІ, що пише код?

Поклади сторінку в постійний контекст проєкту: Claude Code читає файл CLAUDE.md у корені, у Cursor є власні файли правил. Посилайся на розділ «поза версією 1», коли ШІ перестарається. Перед великим шматком роботи попроси план, що відповідає сторінці, без написання коду одразу.

Як перевірити, що функція відповідає технічному завданню?

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

Чого не варто писати в технічному завданні на застосунок?

Чотири речі, яких слід уникати: повний брендбук, план на кожен день, детальна технічна архітектура і функції «на потім», змішані з усім іншим. На старті вистачить кількох референсних скриншотів, а для планування достатньо мети на тиждень. Функції на потім ідуть у розділ «поза версією 1».