Ось конспект доповіді Всеволода з конференції fwdays, підготовлений згідно з вашими інструкціями.
1. Тема та контекст
Назва доповіді: «Будуємо прибутковий B2B Software Service без інвестицій та мікросервісів»
Конференція/формат: fwdays (технічна конференція для IT-спеціалістів)
Спікер: Всеволод (ім'я та нікнейм не вказано, з контексту зрозуміло, що він кофаундер компанії)
Суть доповіді: Спікер ділиться практичним досвідом побудови нішевого B2B SaaS-продукту з нуля. Його компанія надає послуги з пошуку експертів для рецензування наукових статей та грантових заявок. Ключовий меседж: для досягнення прибутковості та швидкості розробки в B2B не обов'язково використовувати модні технології на кшталт мікросервісів або хмарних гігантів. Натомість, ефективніше обрати простий моноліт, наймати відповідальних інженерів і фокусуватися на вирішенні проблем клієнтів, а не на технічному вдосконаленні заради самого процесу.
2. Ключові тези
- Прибутковість — це не інвестиції, а ефективність. Спікер чітко визначає ціль бізнесу: заробляти більше, ніж витрачати. Він свідомо відмовився від стратегії "роздування штату" для залучення інвестицій. Натомість, його підхід — мати невелику команду висококваліфікованих і високооплачуваних людей, які можуть самостійно вирішувати складні задачі. Це дозволяє тримати фонд оплати праці під контролем, не знижуючи якість.
- Швидкість розробки — головна конкурентна перевага. У B2B, де клієнти — великі організації з довгим циклом прийняття рішень, здатність швидко реалізувати нову фічу може стати вирішальним фактором для укладення контракту. Спікер наводить приклад: потенційний клієнт готовий платити понад $100 000, але йому потрібні дві специфічні функції. Компанія може або поставити їх у план на півроку, або зробити за чотири дні і підписати контракт негайно. Другий варіант — це не просто задоволення клієнта, а прямі незароблені гроші, які компанія отримує раніше.
- Мікросервіси — ворог швидкості (для такого бізнесу). Спікер аргументує, що для їхнього продукту, де всі дані глибоко взаємопов'язані (180 млн статей, які посилаються одна на одну), мікросервіси є шкідливими. Вони уповільнюють розробку, ускладнюють тестування (особливо з використанням AI-кодингу), і збільшують накладні витрати на комунікацію. Їхній технічний стек — це свідомий вибір на користь простоти: моноліт, HTML-шаблони, мінімум залежностей. Вони навіть відмовилися від React та GraphQL на користь старої школи, тому що це дозволяє їм розробляти швидше.
3. Технічні деталі
- Архітектура: Суворий моноліт. Спікер підкреслює, що це свідомий вибір, який дозволяє уникати складнощів, пов'язаних з інтеграцією та синхронізацією мікросервісів. Це "нікчемне" (за його словами) рішення виявилося найефективнішим для їхніх задач.
- Інфраструктура:
- Хостинг: Dedicated сервери на Hetzner, а не AWS чи інший великий хмарний провайдер. Причина — ціна. Для їхніх об'ємів даних хмара коштувала б у 20 разів дорожче, що могло б призвести до банкрутства.
- База даних: PostgreSQL як основна база.
- Пошук та вектори: Vespa. Це було ключове технічне рішення. Спікер рекомендує переходити на Vespa з Elasticsearch для задач, де потрібно працювати з векторами та складним пошуком, оскільки Elasticsearch складно змусити ефективно працювати в таких умовах.
- Інструменти AI-кодингу: Спікер згадує, що використання AI (вейпкодинг) добре працює для ізольованих, чітко визначених частин коду (наприклад, парсер для DSL). В моноліті це простіше, ніж у мікросервісах, де AI-генерація тестів та коду потребує складних фреймворків.
4. Практичні поради
- Наймайте "product developer", а не "ticket executor". Спікер описує ідеального інженера як того, хто не бере задачу з Jira і не виконує її буквально. Натомість, він має розуміти бізнес-проблему, сам пропонувати рішення і знаходити шляхи реалізації. На співбесіді він не питає про технології, а питає: "Як ти організовуєш свій робочий день?" Якщо відповідь починається з "приходжу на daily standup", це для нього червоний прапорець.
- Звільняйтеся від повільних людей. Якщо швидкість розробки є критичною, а людина працює повільно, спікер рекомендує прощатися. Це не про те, щоб мучити людей, а про те, що така людина не підходить під бізнес-модель, де швидкість має найвищий пріоритет.
- Дайте розробникам свободу вирішувати їхні власні проблеми. Найкращий приклад — історія з "Domain Specific Language" (DSL). Один з інженерів довгий час мучився, пишучи скрипти для розподілу заявок з безліччю обмежень. Замість того, щоб виконувати задачі "зверху", він сам знайшов проблему, вигадав DSL, написав для нього редактор з валідацією, і створив новий внутрішній продукт, який тепер вирішує задачу за 5-10 хвилин замість тижня. Спікер каже: "50% продакт-менеджменту роблю я, але цю штуку придумав він сам".
- Будьте готові до compliance. Це нудна, але необхідна частина B2B-бізнесу. Спікер визнає, що ненавидить цим займатися, тому найняв окрему людину, якій це подобається. Порада: знаходьте людей, які люблять робити те, що не люблять інші.
5. Дискусійні моменти
- "Мікросервіси погані" — це спрощення. Спікер робить дуже сильну заяву проти мікросервісів, але з чітким контекстом: його дані "unchartable" (їх неможливо розділити між сервісами). Він не каже, що мікросервіси — це завжди погано для всіх, але наводить приклад іншої компанії, яка стикнулася з величезними проблемами під час спроби інтегрувати AI-кодинг через складності мікросервісної архітектури. Його позиція — "для нас це не працює, і ось чому".
- Культура "Product Developer" — це ризик. Спікер визнає, що наймати людей, які не просто виконують завдання, а самі вигадують продукти, дуже важко. Він прямо каже, що у нього немає "social program for employment of developers". Це елітарний підхід, який підходить не всім компаніям і не всім ринкам. Він визнає, що на старті не міг платити "5x market rate", як Valve, але зараз, з падінням ринку, утримувати таких людей стало легше.
- Відсутність QA — це свідомий ризик. Спікер стверджує: "Тестувальників у нас не було ніколи. Розробник має сам перевірити, що те, що він зробив, добре працює". Це дуже радикальний підхід, який можливий лише за умови надзвичайно високої кваліфікації та відповідальності цих самих інженерів. Він повністю суперечить поширеній практиці, особливо в регульованих галузях, де потрібні сертифікації (PCI DSS, SOC 2 тощо). Спікер визнає, що compliance — це біль, і радить наймати людину, яка цим займається, але не каже, що ця людина має займатися QA.
