Від Google Translate до власного SaaS: історія AI-асистента для WhatsApp

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Ця історія почалася не з ідеї бізнесу, а з власної проблеми — як не загубитися та не пропустити корисну інформацію серед купи повідомлень у WhatsApp, мовою якою я не володію.

Для контексту трохи передісторії. Місце дії — Каталонія, Іспанія. Я батько двох дітей-школярів, і тут також існують батьківські чати на усі випадки життя і приводи. Нюанс: регіон має дві мови — каталанську та кастильську (вона ж іспанська). У шкільних батьківських чатах спілкування відбувається обома, часто вони заміксовані в одному повідомленні. Через певний час у Каталонії я порахував, у скількох WhatsApp-чатах я фактично «сиджу»:

• Два шкільні чати для батьків: по одному на кожну дитину. Оголошення про скасовані заняття, зміни розкладу, «завтра принести спортивну форму», «урок плавання о 15:00 замість 16:00», «репетиція», «що давати з собою з їжі», «чия машинка у нас в рюкзаку?», «поговоримо про нову професорку» та інші буденності шкільного життя.
• Додаткові чати про дні народження дітей: також на кожного з двох для обговорення варіантів подарунків, святкування, кому скидати гроші, хто буде присутній.
• Чати спортивних секцій, гуртків, курсів: кілька на дитину + наші з дружиною. Тренери й адміни пишуть про переноси/скасування занять, виступи, а також про те, який костюм потрібно взяти на виступ і яку зачіску зробити — у деталях і подробицях.
• Чат місцевої активності для мене самого: координація, події, зміни в розкладі транспорту...

Разом набралося понад десять активних груп, у яких я фігурую як батько або як учасник. Сорок-п’ятдесят повідомлень на день загалом. Більшість із них — це балачки батьків і знайомих, фотографії з прогулянки і таке інше. З них шість-сім на день все ж є критичними. Якщо я їх пропускаю, одну дитину можу привести до закритої школи або секції, інша може прийти непідготовленою до активностей, де треба щось принести з дому (від смаколиків до сміття для переробки, щоб з нього зліпити проєкт).

Google Translate працює, якщо у вас є лише одне повідомлення. Якщо у вас п’ятдесят повідомлень з кількох чатів, то кожне треба скопіпастити, прочитати й тримати в голові, з якого чату це повідомлення і якої дитини воно стосується. До п’ятого повідомлення — ви втомилися. До десятого — ви просто пропускаєте чат. До тридцятого — ви пропускаєте єдине повідомлення, яке мало значення для сьогоднішнього дня. А у вас паралельно ще йде своє життя і робочі чати.

Це не тільки проблема перекладу з іноземної мови декількох чатів одночасно, а й фільтрації «шумів»- неважливих повідомлень, помножена на координацію між кількома дітьми.

Перший час я викручувався доступним способом (Google Translate), допоки не закінчив курси з роботи зі штучним інтелектом і не вирішив створити інструмент для конкретного мого запиту.

Поки я будував першу версію для своїх каталанських чатів, дав потестувати її своїй мамі (їй 69 років), яка допомагає з онуком у Нідерландах і яка додалася до батьківської групи в школі. Привіт, данська. Також купа повідомлень на день. Та сама динаміка, що й у мене з каталанською. Через два дні вона написала мені повідомлення:

«Тільки що перезапустила програму й увійшла. І одразу маю сповіщення англійською мовою (Примітка: тоді перша версія ще не підтримувала український інтерфейс), що онука треба забрати раніше. Оце програма!!!»

Мамина похвала — то, звісно, приємно, але я подумав, що попри всі наявні ресурси для перекладу, можливо, є люди, яким я можу допомогти більше?

Так з’явився Mytralala — AI-асистент для WhatsApp, який не просто перекладає повідомлення, а й розуміє контекст розмови, допомагає відповідати різними мовами та автоматично витягує важливі події.

Чому існуючі рішення не працюють (для мене)

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

Ринок виявився зовсім не порожнім. Є вбудований переклад у WhatsApp, окремі застосунки для перекладу повідомлень, рішення на базі ботів. Тобто, формально відповідь на питання «як перекласти повідомлення?» вже давно існує.

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

Для себе я умовно поділив наявні рішення на кілька категорій.

• Вбудований переклад WhatsApp. Працює, і це чудово. Але для мого сценарію цього було недостатньо. Станом на жовтень 2025 року (останній публічний список мов, який я знайшов перед написанням статті) Android підтримував лише шість мов: English, Spanish, Hindi, Portuguese, Russian та Arabic. Каталанської не було. Української теж. На iPhone через Apple Translate українська вже підтримувалася, але каталанської також не було.
  Для Каталонії це означало, що приблизно половина повідомлень у моїх чатах взагалі не перекладалася, а решту все одно потрібно було відкривати вручну: long-press, Translate, вибір мови — окремо для кожного повідомлення. Коли таких повідомлень сорок-п’ятдесят на день, це швидко перестає працювати.
• Сторонні застосунки. Їх виявилося чимало: WhatLingo, LangLang, WA Translator, Hi Translate, Translatify та інші. Чесно кажучи, я не проводив їхнього систематичного порівняння. Досить швидко зрозумів, що хочу будувати власне рішення, тому не можу об’єктивно оцінити, наскільки добре кожен із них працює сьогодні.
  Проте з відкритих джерел було видно, що більшість із них зосереджується саме на перекладі повідомлень. Чи вирішують вони сьогодні задачу контекстного перекладу для змішаних каталансько-кастильянських чатів — не знаю, тому не хочу робити категоричних висновків.
• Боти в групах. Цей варіант я відкинув майже одразу. Технічно він можливий, але мені не подобалася сама модель: сторонній бот, який має доступ до повідомлень у шкільному чаті. Це особисте рішення, а не твердження, що такий підхід неправильний.

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

Я просто відкриваю вебсторінку Mytralala, бачу повідомлення вже своєю мовою, а якщо в чаті написали: «У четвер екскурсія, потрібно 8 євро і бутерброд», ця інформація автоматично з’являється в списку нагадувань (дивіться скріншот).

Довго казати та коротко слухати — навіщо все зробив сам? Я не хотів вирішувати свою проблему чужим продуктом, а хотів збудувати щось реальне на тому, що знаю, під свій запит. Перекладати чат через WhatLingo — це не є використанням знань про LLM, pydantic-ai, MCP, OpenTelemetry, multi-tenant архітектуру.

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

Що я побудував

Перший порив був передбачуваним — мікросервіси, Kubernetes, 3 рівні кешування, message bus, окремий сервіс для feature flags. Але постало логічне питання: скільки в мене зараз користувачів? Один — я сам, тому половина плану була відкинута і я залишив архітектуру, яку можна обслуговувати ввечері після основної роботи, і яка не розвалиться, коли з’явиться другий і десятий користувач.

Поточний стан (середина 2026, після місяців по вечорах і вихідних):

WhatsApp Bridge — той самий механізм, який використовує WhatsApp Web у браузері. Один процес тримає одну сесію. Користувач сканує QR-код зі свого телефону, а далі сесія «живе» на сервісі. Так, є офіційний WhatsApp Business API. Він коштує 0,005–0,07 євро за розмову плюс верифікація бізнесу, плюс template messages з апрувом Meta. Для мене та інших користувачів наразі — це економічно необґрунтовано. Коли доростемо до тисячі клієнтів, тоді можна буде повернутися до цього питання.

MCP-сервер — Python plus pydantic-ai. Це шар, який виконує переклад і витягує події. Перекладач — публічно доступна популярна LLM; її якість користувач бачить у кожному повідомленні. Судді (topic-classifier, hallucination-detector, мовний детектор для edge-кейсів, публічно доступні LLM, але менш потужні, ніж перекладач) — це бінарні класифікатори «так/ні», яким топова модель не потрібна. Різниця у вартості токенів між цими двома приблизно 5x. Вважаю, що наразі це відповідність LLM-моделі задачі, яку вона виконує.

Web UI — тут авторизація, керування підпискою і окремий «календар» (список того, що треба зробити, витягнутий з перекладених повідомлень). Якщо в шкільному чаті написали повідомлення з контекстом події — воно автоматично з’являється в полі нагадувань. Також у самому WhatsApp ви отримаєте повідомлення, ніби самі від себе про цей івент (дивіться скріншот).

Observability з першого дня. Я бачу витрати на користувача за день. Це обовʼязково для AI-продукту: без цього неможливо зрозуміти, хто з користувачів має net-loss і чи окупається тариф.

Користувацький інтерфейс Mytralala на зараз

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

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

Що було складно

• WhatsApp ідентифікатори. Видають кілька форматів JID для однієї людини — phone JID, @lid JID (Meta перевела на нього у 2024), @g.us для груп. Один контакт може писати в одному форматі, а відповідь приходить в іншому — і в історії розмови виникають «три Михайла», які насправді є однією людиною.

  Тиждень я писав канонізацію (з процесом виловлювання кожного окремого випадку, дякуючи моїм рідним, які зголосилися бути бета-тестерами) — функцію, яка зводить усі ідентифікатори контакту до однієї адреси, переживає міграцію Meta з phone на lid, і не плутає двох різних людей з однаковим телефоном (буває після зміни номера). Помилка тут означає, що одна людина бачить чужі повідомлення (головне правило було убезпечитися від цього, і в реальності таких ситуацій не було).

• Каталансько-кастильські мікси. Сучасні LLM з code-switching справляються — два-три роки тому це було катастрофою, а зараз уже працює. Але є нюанс: не можна дозволяти моделі «вгадати» мову повідомлення з контексту. Треба явно в системному промпті сказати: «Ці повідомлення приходять з каталансько-кастильського регіону, можливо, змішані в межах одного речення, не намагайся уніфікувати переклади як є». Без цієї інструкції модель іноді «виправляє» каталанські слова на кастильські варіанти і навпаки, і користувач отримує викривлений переклад.
• Пошкодження історії розмови в pydantic-ai. 22 червня 2026 року один користувач не міг отримати жодного перекладу — кожне повідомлення викликало помилку. Розбір показав: його історія розмови мала «висячий» RetryPromptPart без відповідного виклику інструмента. Кожна нова спроба завантажувала пошкоджене повідомлення; LLM API відмовлявся його приймати (validation error на структурі messages); fallback повертав вихідний текст. Полагодив функцію, яка нормалізує історію перед відправкою, щоб вона це ловила. Очистив пошкоджені рядки в базі даних.

  Я виніс з цього один висновок, який працює не лише для pydantic-ai. Коли ти зберігаєш діалог з LLM між запитами (у базі, у файлі, де завгодно), за цілісність цього збереженого діалогу відповідаєш ти. SDK скаже в документації: «messages мають таку структуру, ось такі частини мають бути в парі». Але SDK не покличе тебе ввечері, коли ти запишеш у базу зламану історію. Це виявиться через тиждень, коли користувач не зможе отримати жодного перекладу, і ти будеш переглядати базу даних, шукаючи, де саме зламалася структура.

• LLM упала 23 червня 2026 о 14:14 UTC. Major outage — рівень"critical" на їхньому status page. Мої користувачі отримали вихідний текст замість перекладу протягом чотирьох хвилин, поки fallback path працював. Зеро втрат даних, зеро повідомлень, які зникли — просто ці повідомлення не були перекладені. Це підштовхнуло задизайнити мульти-LLM failover, але не будувати його зараз. Чотири хвилини і сім повідомлень не виправдовують два тижні роботи плюс додатковий вендор у hot path. Зафіксував дизайн і 3 тригери, за якими починаю його будувати.

• Перший: ще одне падіння LLM довше за 15 хвилин у межах найближчих 30 днів — це означатиме, що 23 червня не була одноразовою аномалією.

• Другий: клієнтська база перевалила певну позначку, після якої 4 хвилини без перекладу — це вже не «пару повідомлень», а помітна частина денного трафіку.

• Третій: хоча б одна перерва тривалістю понад 30 хвилин.

До цих моментів — fallback на вихідний текст залишається прийнятним рішенням.

Таким чином, маю приклад того, як «почати з мінімального» виглядає на практиці та як «ніколи не будуй failover» перетворилося на «не будуй його до того, як математика incidents-per-month це виправдовує».

Що з цього вийшло

Сьогодні, через деякий час від першої версії, ситуація така:

Early-stage. Користувачі — переважно родина та друзі першого кола. Звісно, а хто ж ще?! Я не маю тисячі MRR, але маю людей, яким мій застосунок реально потрібен, бо альтернатива (читати кожне повідомлення через Google Translate або пропускати важливе) неприваблива.

Пару відгуків, з дозволу користувачів:

«Mytralala виручив мене у спілкуванні з орендодавцем. Перемовини щодо квартири, оплати, порядку населення, які документи треба показати», - Yurii, Switzerland

-----------------------------------------------------------------

"Классное приложение с очень удобным интерфейсом. Я использую его весь день, когда общаюсь с коллегами и друзьями из разных стран. Мне не нужно думать, к что-то им сказать — я просто пишу, что мне нужно на своём языке. Удобно, когда работаешь и параллельно общаешься весь день! 👍" - Alex, Spain 

Чому це ширше, ніж одна історія?

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

• Переїзд за кордон — мігранти та родини-мігранти у будь-якій країні.
• Сезонна робота — польські працівники в Іспанії, румунські в Німеччині, українські в Чехії... WhatsApp-групи на мові роботодавців.
• Місцеві активності у білінгвальних регіонах — Каталонія, Країна Басків, Галісія, Південний Тіроль, фламандська Бельгія. Місцева мова + державна мова, перемішані. Англійська вас не врятує, тому що далеко не всі нею володіють і користуються нею в повсякденному спілкуванні.
• Релокація на роботу в ЄС — ваш голландський орендодавець пише вам у WhatsApp інструкції щодо лічильників голландською мовою. Ви на дев’ять місяців у Роттердамі. А чи має сенс вчити голландську заради цього?

Спільне в усіх цих сценаріях: WhatsApp — один із основних каналів комунікації в більшості країн ЄС. Не e-mail, не Telegram, не Signal, а WhatsApp. І якщо ви не носій мови — ви або «герой зі шваброю проти океану» з 40+ повідомленнями на день, або ви випадаєте з комунікації. Навіть якщо повідомлень менше, кому потрібні зайві рухи під час перекладу?

Чому я вирішив будувати це як SaaS, а не як pet-проєкт

З моєї історії зрозуміло, що спочатку я хотів зробити Mytralala (навіть назва натякає на «мої балачки») лише для себе. Один Docker-контейнер на моєму ноутбуці, без авторизації, без білінгу, без нічого. Через деякий час мої знайомі почали питати: «А можна мені теж?»

У той момент були дві альтернативи:

(а) Залишити це домашнім проєктом і додавати користувачів вручну. Привабливо, але я витрачав би вихідні на адміністрування.

(б) Перебудувати в multi-tenant SaaS. Дорого з точки зору часу. Авторизація, ізоляція даних, білінг, видалення з дотриманням GDPR, моніторинг, аларми, runbook’и. Місяців три-чотири роботи.

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

Архітектурний принцип, який я заклав від самого початку: multi-tenancy — логічна, не фізична. Один інстанс, один набір баз, кожний рядок має user_id, кожний запит фільтрується. Окрема база на клієнта — це антипатерн для SaaS у моєму масштабі. Якщо колись з’явиться корпоративний клієнт з compliance-вимогами(HIPAA, PCI), тоді буде окреме рішення.

Що я зрозумів

Починай із власної проблеми, а не з чужої. Я будував для себе. Коли попросив рідних стати моїми бета-тестувальниками, то я вже мав готовий MVP. Якби я починав з «хочу зробити продукт для діаспори» — я б витратив місяці на дослідження ринку, досі не маючи нічого живого. Перший користувач — це я. Другий — моя родина, Третій — мої друзі... Тільки потім — незнайомці. Так «мої балачки» Mytralala, стали їхніми також і проект зажив своїм життям.

Push back собі. Я кілька разів хотів додати інтеграції, аналітику, дашборди для адмінів — те, що «правильні SaaS-и мають». Я ставив собі питання: «Це насправді потрібно зараз, чи я просто копіюю те, що бачу в чужих продуктах?» У 80% випадків відповідь — друге. Я викинув ці ідеї й повернувся до того, що важливо мені, як користувачеві.

EU-only — це фіча, не обмеження. Я працюю в Іспанії як autónomo (аналог ФОП). Я плачу місцеві податки, я використовую Lemon Squeezy (merchant-of-record), щоб вони вирішували VAT MOSS за мене. Дані в Європі. GDPR-compliant. Запускатися «глобально» з першого дня для соло-засновника — самосаботаж: ви додаєте десять юрисдикцій законодавства до того, як у вас зʼявиться перший сторонній клієнт.

Помилки — це корисний матеріал. Даунтайм LLM 23 червня, пошкодження історії 22 червня, тиждень на виправлення @lid ідентифікаторів — це не «хроніки невдачі», а інженерна біографія продукту. Я документую їх у файл, де в майбутньому можу прочитати, «чому було ухвалено рішення X» і такий підхід окупився вже десятки разів.

Фінал

Коли я починав цей проєкт, то просто хотів перестати губитися в іншомовних WhatsApp-чатах. Не більше. Згодом виявилося, що ця проблема знайома не лише мені. Саме так pet-проєкт поступово перетворився на SaaS.

Я не стверджую, що це єдиний чи найкращий спосіб будувати AI-продукти. Це лише шлях, який спрацював для мене. Якщо ви бачите місця, де я міг прийняти кращі інженерні рішення, або знаєте інші підходи до розв’язання подібної задачі — із задоволенням обговоримо їх у коментарях.

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

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

Дякую за увагу!