Фраза «SaaS мертвий» останнім часом набирає популярності. Суть аргументу в тому, що ми живемо в епоху, коли ШІ може писати код, тож варто перестати платити щомісячні підписки за SaaS і просто створювати потрібне власними силами.
У моїй компанії, Emooove, ми останні кілька місяців повністю присвятили себе створенню внутрішніх систем власними силами. І, зробивши це на практиці, я пізнав і успіхи, і гіркі уроки. Сьогодні я хочу поділитися своїм поглядом на наратив «SaaS мертвий» на основі цього реального досвіду.
Щоб усе було зрозуміло: я пишу це з позиції користувача/творця систем, а не постачальника SaaS.
Дивовижна епоха, коли кожен може створювати системи
Перш за все, як передумова: поява Claude Code справді відкрила еру, коли «будь-хто може створити систему». Це не перебільшення.
В Emooove керівниця рекрутингу, яка пропрацювала з нами лише два місяці, створила внутрішню ATS (систему відстеження кандидатів). Вона не інженерка і не має жодного досвіду в розробці. Попри це, вона створила функціональну систему, яка охоплює все: від імпорту кандидатів до управління відбором та інформаційних панелей.
Більше того, зараз ми розробляємо внутрішню систему для підвищення операційної ефективності та якості нашого основного бізнесу — агентських послуг з продажів. Я особисто щодня працюю над цим, і менш ніж за два тижні від старту я відчуваю, що ми на порозі створення чогось досить хорошого.
Зрозуміло, чому людям хочеться говорити «SaaS мертвий», коли можна створити власними силами те, що інакше коштувало б десятки чи сотні тисяч єн на місяць у вигляді підписки на SaaS.
Однак усе не так гладко
Це головний момент. Коли ми спробували зробити це на практиці, усе виявилося не таким райдужним.
1. Обслуговування неймовірно складне
Так чи інакше, будувати можна «на ходу», тому системи швидко набувають форми. Однак через те, що вимоги не до кінця продумані, лишається багато шорсткостей.
У випадку з нашою ATS ми стикалися, наприклад, із таким:
- Записи, які мали імпортуватися, не імпортувалися.
- Цифри на інформаційній панелі були дещо зламані.
- Критично важливих кнопок бракувало, через що робота повністю зупинялася.
Ми зіткнулися з багатьма «недоліками, які помічаєш лише після початку використання». З нашою внутрішньою системою підтримки продажів навіть був ранок, коли ми раптово не змогли отримати до неї доступ — екран просто не відкривався.
Звісно, ці проблеми можна певною мірою виправити, ретельніше прописуючи вимоги або вносячи покращення в процесі роботи. Однак увесь цей час страждають звичайні бізнес-процеси. Якщо почати будувати з очікуванням, що буде «легко і швидко», можна опинитися в скрутному становищі. Я зрозумів, що не варто підходити до цього з настановою «побудував і закінчив», а радше «побудував — і продовжуй виправляти».
Оскільки масштаб нашого рекрутингу невеликий, ми переживемо, навіть якщо ATS на деякий час зупиниться. Але я здригаюся, коли думаю про те, що було б, якби це була система з багатьма зацікавленими сторонами. Зі збільшенням кількості користувачів і масштабу впливу втрати від однієї помилки зростають, а рівень складності стрімко злітає вгору.
Якщо для внутрішніх систем це ще можна терпіти, то до створення будь-чого для зовнішнього продажу або того, що контактує із зовнішнім світом (наприклад, форми зворотного зв'язку), варто ставитися вкрай обережно.
2. UI/UX ніколи не доводиться до досконалості
Будуючи систему самостійно, я зрозумів: фінальний результат виглядає посередньо.
Екрани, які ШІ генерує спочатку, виглядають «пристойно», але коли починаєш ними користуватися, деталі виявляються незграбними. Так, можна зрештою довести все до гарного вигляду, віддаючи інструкції знову і знову, але для цього потрібні справжня одержимість і час. Більшість людей, найімовірніше, підуть на компроміс десь на півдорозі.
Інтерфейси SaaS відполіровані тому, що професійні дизайнери роками втілювали відгуки користувачів; це не те, що можна отримати задарма.
3. Проблема безпеки
Це найстрашніша частина.
Навіть не-інженери можуть використовувати Claude Code, щоб створювати функції та UI/UX із підходом «робимо як вийде». Але чи можна так само легко опанувати безпеку? Принаймні для мене — ні. Автентифікація, управління правами доступу, реагування на вразливості — «працює» і «є безпечним» — це дві абсолютно різні речі.
У нашому випадку нам пощастило: у команді є людина з досвідом інженера з безпеки, тож ми стежимо, щоб саме вона займалася цією частиною. Але навіть так лишається частка тривоги. Сама думка про організацію без експертів, яка вносить дані клієнтів у систему, створену нашвидкуруч, і виставляє її на публіку, змушує мене вкриватися холодним потом.
Бінарна логіка «живе чи помирає» — хибна
Я перелічив негативні сторони внутрішньої розробки, але, чесно кажучи, у неї багато й хороших сторін.
- Можна створити систему, яка ідеально підходить саме вашому бізнесу.
- Якщо потрібно щось виправити, це можна зробити вже наступного дня.
- Щомісячних витрат майже немає.
- Компанія набуває ноу-хау та впевненості, що «ми можемо будувати системи самі».
Проблема в тому, що все намагаються спростити до питання «Чи виживе SaaS, чи помре?». Використовувати SaaS чи будувати власними силами — залежить від ситуації в компанії. На основі свого досвіду я виділив п'ять пунктів, які варто врахувати:
Пункт 1: Чи є у вас інженери в команді?
Якщо ні, ви зазнаєте невдачі в таких сферах, як безпека, які не-інженери не можуть закрити нашвидкуруч. Найстрашніше — це можливість створити функції, навіть не усвідомлюючи небезпеки. Ключовий момент — чи зможете ви залучити досвідчену людину для перевірки ключових напрямків.
Пункт 2: Кількість зацікавлених сторін
Якщо їх забагато, втрати в разі збою величезні, а рівень складності різко зростає. І навпаки, невеликі організації можуть легше експериментувати, адже якщо щось зупиниться, вони можуть просто вибачитися. Реалістично починати з процесів, які мають невеликий масштаб впливу.
Пункт 3: Зовнішні чи внутрішні системи
Із внутрішніми системами ризик обмежений, якщо щось трапиться. Однак для всього зовнішнього один-єдиний витік інформації може бути непоправним. SaaS дозволяє перекласти частину відповідальності на постачальника, тоді як у внутрішній розробці вся відповідальність — на вас. Цінність «перевіреної надійності» SaaS зростає для всього, що звернене назовні.
Пункт 4: Чи можете ви виділити людино-години на обслуговування?
Обслуговування вимагає більше зусиль, ніж ви уявляєте. Внутрішня розробка — це не «побудував і закінчив», а «продовжуй виправляти». Чи можете ви почати з таким розумінням? Якщо почати з легковажним ставленням, ви потонете у виправленні недоліків, і це тиснутиме на ваш основний бізнес.
Пункт 5: Чи подобається вам розробка зі ШІ / чи хочете ви цим займатися?
Зрештою, усе зводиться саме до цього. Це нудніше і складніше, ніж можна подумати, і дуже дратує, коли ШІ тебе не слухається (сміх). Чи зможете ви довести справу до кінця попри все? Це чудова епоха для тих, кому це подобається, але, на мою думку, на самому лише почутті обов'язку це не вивезеш.
Підсумок: SaaS не мертвий. Просто тепер є більше варіантів.
У заголовку я вжив слово «провал», але точніше було б сказати — це був «майже провал», і не один. Ми продовжуємо внутрішню розробку, бо маємо досвідчених інженерів, наша організація все ще невелика, системи призначені переважно для внутрішнього використання, ми готові виділяти час на обслуговування, і, найголовніше, я сам цього хочу. Можна сказати, ми робимо це, бо перебуваємо в привілейованих умовах, де виконуються всі п'ять пунктів.
І навпаки, якщо компанія, яка не відповідає цим умовам, сприйме «SaaS мертвий» буквально й спробує побудувати свої ключові процеси власними силами, вона справді провалиться.
SaaS не мертвий. Просто можливість «створити самому» тепер відкрита для всіх. Спокійно оцініть ситуацію у вашій компанії та використовуйте і SaaS, і внутрішню розробку. Хіба це не правильний підхід у цю зручну, але хитку епоху?
