Коли продукт зібраний із наймодніших технологій, а попередня команда пішла, кожне доопрацювання стає дорогим: людей, здатних розібратися в системі, мало, а перевірити просту зміну складно. NaturalTTS, SaaS-сервіс на основі ШІ, який перетворює текст на аудіо й мовлення на текст. Він працює за підпискою через інтеграцію Stripe, бекенд написано на NodeJS у сервісах Amazon Web Services із системою Amazon Pipelines, фронтенд на React. Проєкт прийшов до нас від іншої команди, і головним викликом стала не функція, а складність самої архітектури.
Natural TTS
Що це за продукт і що видно одразу
Для користувача все починається з форми на головній: вставити текст, обрати мову й голос, прослухати результат. Головна обіцяє понад 61 природний голос, 6 популярних мов і безкоштовне завантаження MP3.
Розділ голосів дає прослухати приклади, щоб обрати звучання до оплати.
Тарифи на скриншоті вересня 2024 року побудовані навколо ліміту символів: безкоштовний план на 5000 символів і 6 мов, особистий за $9.99 на місяць на 200 000 символів і 15 мов, комерційний за $79.99 на місяць на 1 000 000 символів і всі мови. У платних планах є розмітка SSML, історія файлів і завантаження тексту з файлу .txt, а для комерційного використання заявлено розпізнавання тексту зі сканів.
Голос у текст: кабінет розшифрування
Друга половина скриншотів показує кабінет розпізнавання мовлення, на екранах він працює під брендом Rythmex. Вхід через пошту, Google або Facebook, далі робочий стіл: завантаження файлу перетягуванням (mp3, m4a, mp4, ogg, flac, webm, wav), баланс у хвилинах та історія розшифрувань.
Монетизація в кабінеті побудована на хвилинах: пробний період на 7 днів із 5 безкоштовними хвилинами, Premium за $12 на місяць із двома безкоштовними годинами й ціною $5 за годину понад них, команда до 3 акаунтів, Enterprise за індивідуальною ціною. Річна оплата дає знижку 25 %.
Партнерська програма дає користувачеві реферальне посилання на головну або на реєстрацію, показує конверсію 5 %, переходи, заробіток і виведення коштів. У меню є окремий розділ API для підключення сервісу із зовнішніх систем.
З чого почалася наша робота
Ми підключилися не з самого початку: ключові архітектурні рішення вже було ухвалено. Через запити на швидке масштабування й автоскейлінг (автоматичне розширення ресурсів сервера без його вимкнення) обрали повністю хмарну модель розробки. У неї свої плюси, але для цього проєкту мінусів, імовірно, було більше, особливо з огляду на те, що попередня команда не стала продовжувати роботу.
Ключовий успіх: ми швидко розібралися в низці специфічних технологій, у яких не мали навіть теоретичного досвіду, і взяли проєкт у розробку.
Чому складна архітектура стала ризиком для бізнесу
Перша проблема проста: коли проєкт напханий складними технологіями, різко звужується коло людей, здатних його доопрацьовувати. Друга: через деякий час сам автор проєкту може не впоратися зі складністю або втомитися від неї.
У проєкті зливалися компетенції кількох фахівців:
- AWS DevOps з хмарних обчислень і серверів. Інфраструктуру продумано цікаво, і коли розберешся, вона навіть зручна, але заплутана й без документації. Рідкісний програміст поєднує добрий код і глибокий досвід у сервісах Amazon.
- React-розробник зі знанням TypeScript. Йому найпростіше налагоджувати застосунок, але лише фронтенд: поставити бекенд локально для тестів в умовах цього проєкту не зможе майже ніхто з фронтендерів.
- NodeJS-розробник зі знанням TypeScript. Таких фахівців багато, але тут треба знати особливості сервісів Amazon, і бекендер середнього рівня перший тиждень просто не розуміє, як прокинути звʼязку параметрів, яка в простішій архітектурі робиться за хвилину.
Усі ці компетенції сильно перетиналися через сервіси Amazon, і поріг входу виявився дуже високим. Розробник без досвіду з AWS не розуміє, як провести тест змін і як запустити покрокове налагодження без окремого спеціального софту, з яким теж потрібен досвід. TypeScript виправдовує себе, коли стабільна команда веде проєкт від початку до кінця, а при зміні команди стає ще одним барʼєром.
Як ми приймаємо проєкт від іншої команди
- Аудит коду й інфраструктури: які хмарні сервіси задіяні, як іде збірка й викладка, де зберігаються налаштування.
- Карта системи й документація, без якої наступний розробник знову витратить тижні на вхід. Чому це окуповується, розбираємо у статті про документування.
- Контур для тестів, де зміну перевіряють без ризику для живих користувачів.
- План спрощення: що залишити, а що перевести на простішу схему. Підхід описано у статті про деплой та інфраструктуру.
Чесна межа: обсяг робіт у чужому проєкті неможливо назвати до аудиту, тому оцінку даємо після розбору коду й інфраструктури.
Де ще це застосовне
Синтез і розпізнавання мовлення потрібні голосовим агентам і колцентрам, онлайн-навчанню для озвучення курсів, сервісам розшифрування зустрічей та інтервʼю. Як голос працює в телефонії, показано в кейсі AI-секретаря.
Якщо Вам дісталася складна система від іншої команди або Ви плануєте голосовий продукт, запишіться на безкоштовну консультацію з архітектором. Після неї Ви отримаєте розрахунок ціни й строків за етапами.
