← Усі проєкти
проєкти

PAPUGtesting

PetTech · B2C

B2C PetTech-продукт для власників папуг, який допомагає відстежувати зміни у стані птаха та зберігати структуровану історію спостережень.

Проблема

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

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

Discovery

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

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

Початкова ідея містила community-механіки, але дослідження змістило фокус: проблема не в браку спілкування, а в невпевненості «чи все зараз нормально з моїм птахом?».

Валідація попиту

Запустила landing з квізом на 22 питання (профіль власника, поведінка птаха, стан здоров'я) і паралельно зробила 150 холодних outreach серед аудиторії bird-інфлюенсерів та власників папуг у TikTok.

Воронка квізу: 794 кваліфіковані візити → 250 почали проходити квіз → 54 дійшли до результату (~22%) → 11 залишили контакт (~20% від тих, хто побачив результат).

Медіанний час проходження: 4 хвилини 5 секунд.

Outreach: 19 зацікавлених відповідей зі 150 надісланих (~13%). Кількість прочитаних повідомлень канал не показує, тому реальна конверсія від прочитаних може бути вищою.

Інсайт про канали: навіть якщо рахувати квіз від найвужчої бази, тобто від тих, хто вже почав відповідати, конверсія в контакт склала 4,4%. Точковий outreach в аудиторію нішевих інфлюенсерів дав ~13%, тобто майже втричі краще від найвужчої бази квізу і приблизно на порядок краще, якщо рахувати від рівня візиту. Це змістило пріоритет каналів у бік influencer-маркетингу та роботи зі спільнотою, а не платного трафіку на мікробюджетах.

794кваліфіковані візити
250почали квіз
54дійшли до результату
11залишили контакт
150відправлено outreach
19зацікавлених відповіли

* На жаль, немає даних про прочитані.

Інсайт про аудиторію: основну цінність квіз дав не як лідмагніт, а як дослідницький інструмент. 54 людини добровільно пройшли 22 питання за 4 хвилини, що само по собі сигнал зацікавленості в темі. Зібрані відповіді дозволили деталізувати профіль власника: серед 145 відповідей 66% мали птаха менше двох років, а розподіл за видами показав, які саме породи домінують в аудиторії. Це вплинуло на продукт напряму: менше професійної термінології, простіші сценарії, пріоритет контенту під найпоширеніші види й орієнтація на новачка, а не на досвідченого заводчика.

Ключова продуктова ітерація

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

Переробила її на два сценарії.

«Все як зазвичай» → один тап

«Є зміна» → запис конкретного спостереження

Так трекінг став фоновою звичкою, а деталі з'являються лише тоді, коли вони справді потрібні.

Що вже побудовано

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

AI-асистент (Pro). Чат, у якому власник пише або диктує голосом, а асистент сам пропонує записи (вага, симптом, ліки, зміни в житті, новий птах). Записи зберігаються лише після підтвердження, і їх можна скасувати. Асистент пам'ятає факти про птаха, відповідає з бази знань і нотаток за видами, а про отруєння чи небезпечні симптоми попереджає окремо: це визначає перевірка в коді, а не модель. Дозування ліків не дає.

База знань. Гід по їжі на понад 100 продуктів із вердиктом і поясненням, нотатки по 20+ групах видів.

Безпека й контроль AI. Журнал кожного виклику моделі (токени, вартість, затримка, fallback) без тексту користувача, денний ліміт витрат на акаунт, kill switch в адмінці, фільтр, що прибирає з відповіді будь-яке дозування ліків.

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

Платформа. Вхід за кодом з пошти або через Google, тарифи Free / Plus / Pro, адмінка (користувачі, птахи, витрати й надійність AI), встановлення як застосунок (PWA), десктопна версія, форма зворотного звʼязку, лендинг закритої бети.

Окремо побудувала 60-місячну фінансову модель з реальними цінами AI, стелею ринку та додатковими потоками (ветконсультації, маркетплейс), щоб перевірити економіку freemium до того, як вкладатися в acquisition.

Якість AI

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

Суддю калібрувала власною розміткою: семантичній перевірці довіряю тільки тоді, коли вона збігається з моїми оцінками щонайменше на 80%. Інакше відповідь іде мені на ручне ревʼю. Критичні сценарії (екстрені випадки, дози, повторне підтвердження) проганяються тричі, щоразу з чистого стану.

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

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

Надійність AI

Fallback-и. Основна модель асистента Claude Sonnet, резервна OpenAI GPT. Якщо провайдер повертає помилку, запит один раз повторюється, а якщо знову не вдається, відповідає резервна модель. Коли основний провайдер падає кілька разів поспіль, система 90 секунд звертається одразу до резервного, а потім пробним запитом перевіряє, чи основний відновився. Для власника це виглядає як одна звичайна відповідь. Екстрене попередження спрацьовує, навіть коли обидві моделі недоступні, бо перевіряється кодом ще до виклику моделі.

Вибір speech-to-text. Модель для голосового введення обирала сліпим тестом. Зробила закриту сторінку: один запис іде одразу в чотири моделі (ElevenLabs Scribe v1 і v2, GPT-Transcribe, Gemini Transcribe), а назви моделей приховані, доки я не оціню кожну розшифровку. Так оцінка не залежала від того, якій моделі я довіряла заздалегідь. Тестувала на реальних записах про птахів: клички, назви видів, змішана мова. Основною стала GPT-Transcribe, резервною Gemini. Імена птахів з акаунта передаються моделі як підказки, щоб вона правильно писала клички.

Як влаштований процес

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

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

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

Аналітика

Під час аналізу acquisition-воронки виявила, що частину трафіку створюють боти та preview-сканери, які завищували знаменник.

Тому замість сирого page view ввела qualified visit: візит з достатньою видимістю сторінки або реальною взаємодією. Це очистило базу для подальшого аналізу конверсії.

Відкриття застосунку записуються разом з UTM-мітками, тож в адмінці видно, скільки акаунтів привела кожна кампанія. Для матеріалів до заявки в SKELAR AI Lab є окремий трекінг переглядів по сторінках і слайдах.

Статус

Зараз: шліфую асистента за результатами прогонів журі та завершую випускний проєкт SKELAR AI Lab.

До закритої бети: QA з реальними власниками, вмикання продуктової аналітики (Amplitude вже підключений, чекає юридичного блоку), ревʼю бази знань ветеринаром на позначці 1 000 активних користувачів.

Далі: нативні обгортки під Android та iOS, оплата підписки, потім ветконсультації та маркетплейс усередині продукту.

Монетизація: freemium. Безкоштовно один птах і структурований трекінг, Plus додає кількох птахів, Pro відкриває AI-асистента.

Stack

React · TypeScript · Supabase (Postgres, RLS, Edge Functions) · Cloudflare Pages · PWA · GitHub Actions

AI-моделі:

асистент: Claude Sonnet, резервна OpenAI GPT

голос: GPT-Transcribe, резервна Gemini Transcribe

веб-пошук: OpenAI web search за allowlist джерел

AI-assisted development: Cursor, Claude Code

Аналітика: власна подієва + Amplitude