Більшість агентств будують продукти і передають їх. Ми будуємо продукти і потім запускаємо їх — включаючи власні. ChiliAuto, Billwaze, MoonBeauty, MoonLinks та ще чотири. Всі живі. Всі підтримуються тими ж інженерами, що працюватимуть над вашим продуктом. Це свідомий вибір, і він змінює все у тому, як ми будуємо.
Тест о 2 ночі
Коли ви будуєте продукт і передаєте його, вам ніколи не доводиться мати справу з тим, що відбувається о 2 ночі, коли він ламається. Клієнт має справу. Команда підтримки має справу. Ви переходите до наступного проєкту.
Коли ви самі запускаєте продукт — 2 ночі ваша проблема. І спосіб, яким ви реагуєте на цю реальність, змінює кожне рішення під час збірки: моніторинг, що ви налаштовуєте, сповіщення, що конфігуруєте, runbook'и, що пишете, архітектурні вибори, що робите, щоб уникнути дзвінка о 2 ночі з самого початку.
Ми отримували дзвінок о 2 ночі. Це робить вас кращим архітектором, ніж будь-яка методологія.
Чого нас вчить експлуатація власних продуктів
Кожне припущення, що ви робите під час збірки, перевіряється в продакшені. Деякі з них неправильні. Ті, що неправильні, стають дорогими — в інженерному часі, у довірі користувачів, у дзвінку о 2 ночі, який вам доводиться робити.
Уроки від експлуатації ChiliAuto (нашого маркетплейсу переїздів):
- Час push-сповіщень — продуктове рішення: наше 5-хвилинне вікно прийняття було занадто коротким для бригад на полі. Ми розширили до 10 хвилин і коефіцієнт прийняття зріс на 40%.
- Перша суперечка вчить більше, ніж перші 100 бронювань: ми переробили потік завантаження доказів після першого спірного замовлення, що виявило прогалини в наших припущеннях.
- Щільність пропозиції — операційна метрика, а не метрика запуску: ми щотижня використовуємо адмін теплову карту для виявлення областей з тонким покриттям до того, як клієнти це помітять.
Уроки від запуску Billwaze (нашого білінгового SaaS):
- Помилки в білінгу — екзистенційні: неправильний рахунок на білінговій платформі руйнує довіру. Ми додали попередній перегляд тестового email до кожного MSP перед доставкою рахунку.
- Інтерв'ю при відтоку цінніші за зворотний зв'язок активних користувачів: ті, що пішли, сказали нам те, до чого активні користувачі адаптувалися.
- Мультивалютність ніколи не завершена: кожна нова країна виявляє новий податковий або форматний граничний випадок.
Як це проявляється, коли ми будуємо для вас
Ми пишемо runbook'и, бо вони нам були потрібні. Ми налаштовуємо моніторинг до запуску, бо самі опинялися без нього. Ми налаштовуємо тестові стенди з другого тижня, бо дізналися, що відбувається, коли QA відбувається лише в продакшені.
Ми відкидаємо фічі, що здаються розумними, але вносять операційну складність — бо самі підтримували ці фічі о 2 ночі і знаємо, скільки вони коштують. Ми проектуємо для інженера підтримки так само, як для користувача.
Більшість агентств дають вам ПЗ. Ми даємо вам ПЗ, яке готові поставити власне ім'я і запускати самі. Планка різна.
Аргумент власної шкіри в грі
Є простий фільтр для оцінки агентства ПЗ: чи готове воно запускати те, що будує для вас? Не підтримувати — запускати. Обробляти інциденти, управляти деплоями, відповідати за доступність.
Якщо відповідь "ні" — а для більшості агентств так і є, бо запуск ПЗ складний, тривалий і виявляє кожен ярлик, прийнятий під час збірки — це говорить вам щось про якість рішень, що приймаються під час роботи.
Ми запускаємо вісім продуктів. Команда, що будуватиме ваш, отримувала дзвінок о 2 ночі через власний код. Стандарти не теоретичні.
Хочете побачити, що ми запускаємо? Подивіться на наші продукти — кожен з них живий і підтримується тією ж командою, що працюватиме над вашим.
Переглянути наші продукти