Що насправді створює компанія з розробки SaaS на замовлення?
Компанія з розробки SaaS на замовлення створює продукт, яким користуються ваші клієнти, і механізми навколо нього, що дають змогу продавати його за підпискою: акаунти, команди, тарифи, білінг, права доступу, онбординг, адмінський бек-офіс, інтеграції й хостинг, що обслуговує всіх клієнтів з однієї кодової бази. Видимі функції часто становлять менше половини роботи. Решта - це те, що робить продукт безпечним для продажу десятому й сотому клієнтові.
Lytvynov Production будує SaaS-продукти на PHP/Symfony, React або Vue і PostgreSQL або MySQL, з мобільними застосунками на React Native чи Flutter, коли вони потрібні. Ми працюємо зі стартапами, що створюють перший продукт, і з B2B-компаніями, які перетворюють внутрішній інструмент на те, що можна продавати.
Які складники потрібні кожному SaaS-продукту?
Кожному SaaS-продукту потрібен однаковий набір складників, і якщо рано вирішити, наскільки глибоко будувати кожен, це зекономить місяці надалі. Ось як ми зазвичай розбиваємо їх на етапи:
| Складник | SaaS MVP | Версія для B2B-продажів | Етап масштабування |
|---|---|---|---|
| Акаунти й автентифікація | Вхід через email і соцмережі | Команди, запрошення, SSO (Google, Microsoft, SAML) | SCIM-провізіонінг, корпоративний SSO |
| Мультитенантність | Спільна база даних, ідентифікатор тенанта в кожному рядку | Кешування з урахуванням тенанта, налаштування для кожного тенанта | Окрема база даних для великих клієнтів |
| Ролі й права доступу | Власник і учасник | Власні ролі, права на рівні об'єктів | Журнал аудиту, процеси погодження |
| Білінг | Один тариф через Stripe Checkout | Тарифи, пробні періоди, місця, ліміти використання, робота з несплатами | Оплата за використання, рахунки, обробка податків |
| Адмінський бек-офіс | Згенерована адмінка для вашої команди | Пошук клієнтів, вхід від імені клієнта, повернення коштів | Звітність, feature flags для кожного тенанта |
| Інтеграції | Одна ключова інтеграція | Публічний API, вебхуки | Застосунки в маркетплейсі, вбудовувані віджети |
| Експлуатація | CI/CD, резервні копії, відстеження помилок | Моніторинг, staging для кожної гілки | Автомасштабування, політики зберігання даних |
Як проєктувати мультитенантність?
Мультитенантність варто проєктувати з першого дня, навіть якщо у вас лише один клієнт, бо додавати ізоляцію тенантів у живий продукт дорого й ризиковано. Головне правило просте: кожен запит, що торкається даних клієнта, має бути обмежений тенантом, і це обмеження має забезпечувати фреймворк, а не пам'ять кожного розробника.
У Symfony ми реалізуємо це через резолвер тенанта (із субдомену, заголовка чи сесії користувача) і фільтр Doctrine, який автоматично додає умову тенанта до кожного запиту, плюс тести, що намагаються прочитати дані іншого тенанта й мають завершитися невдачею. Для більшості продуктів правильний старт - спільна база даних з колонкою тенанта. Окрема схема чи окрема база для кожного тенанта з'являються, коли корпоративні клієнти вимагають фізичного розділення або зберігання даних у певному регіоні. Ми тримаємо модель тенантів за єдиним інтерфейсом, тож перенесення великого клієнта в окрему базу згодом - це міграція, а не переписування.
Як працюють білінг підписок і ціноутворення в SaaS?
Білінг у SaaS працює найкраще, коли гроші обробляє білінг-провайдер, а продуктові правила ваш код. Stripe Billing, Paddle чи Chargebee зберігають картки, списують кошти, формують рахунки й працюють з податками. Ваш застосунок слухає їхні вебхуки й вирішує, що дозволено кожному клієнтові: який тариф, скільки місць, які ліміти, що відбувається під час пробного періоду чи після невдалого платежу.
Ми вже будували продукти з великою кількістю платежів. Ritoria, платформа серійної художньої літератури, мала внутрішню валюту, яку купували через Stripe, PayPal або Braintree й витрачали на розділи, подарунки й донати, з реєстром транзакцій, реферальними винагородами й виплатами авторам та дизайнерам обкладинок. Уроки з такої роботи: вести реєстр кожного руху коштів, робити обробку вебхуків ідемпотентною й ніколи не ставити доступ користувача в залежність від того, чи вчасно надійде один вебхук.
Що має бути в адмін-панелі SaaS?
Адмін-панель SaaS має давати вашій команді змогу відповісти на запитання клієнта без дзвінка розробникові. Тобто знайти будь-якого клієнта, побачити його тариф і використання, змінити налаштування, повернути кошти й побачити те, що бачить він.
Для ранніх продуктів ми генеруємо адмінку з моделі даних (у Symfony добре працює EasyAdmin), і це дає робочий бек-офіс за кілька днів. Бек-офіс Ritoria виріс до 38 розділів, що охоплювали рядки контенту, банери, жанри, FAQ, SEO-тексти й кожну сутність у системі, без окремого проєкту власної адмінки. Коли продукт росте, ми додаємо те, що окупається найшвидше: вхід від імені клієнта з журналом аудиту, feature flags для кожного тенанта й дашборди активації та відтоку.
Як спланувати дорожню карту SaaS від MVP до масштабування?
Дорожню карту SaaS варто впорядковувати за тим, що блокує дохід, а не за тим, що найцікавіше розробляти. Зазвичай ми плануємо три етапи:
- SaaS MVP (10-14 тижнів): один ключовий сценарій, реєстрація, один тариф, Stripe Checkout, згенерована адмінка. Мета: перші клієнти, що платять. Див. розробка MVP.
- Готовність до продажів бізнесу (наступні 3-5 місяців): команди й ролі, кілька тарифів, пробні періоди, SSO, публічний API й вебхуки, журнал аудиту, онбординг-листи. Мета: пройти анкету безпеки B2B-покупця.
- Масштабування: робота над продуктивністю, оплата за використання, маркетплейс інтеграцій, окремі тенанти, функції ШІ на основі даних ваших клієнтів.
Дорожня карта щомісяця переглядається з огляду на реальне використання. Функції, про які не просить жоден клієнт, що платить, опускаються нижче, хоч би як рано їх запланували.
Які SaaS-продукти ми створили?
Ми створювали SaaS і продукти за підпискою для власного портфеля й для клієнтів:
- AI Resume Master: наш власний конструктор резюме з ШІ з моделлю SaaS і рекламою, створений приблизно за три місяці, зараз має 50 000 активних користувачів на місяць.
- Ritoria: платформа на Symfony з 54 доменними сутностями, трьома платіжними провайдерами, маркетплейсом і соціальним шаром англійською та арабською, яка працювала в продакшені на AWS два з половиною роки: 292 коміти й 120 міграцій бази даних.
- Календар спортивних подій: freemium-платформа з B2B-ліцензуванням для британської спортивно-технологічної компанії, з API й вбудовуваними віджетами для платформ-партнерів і рушієм парсингу, що об'єднує сотні зовнішніх календарів.
Скільки коштує розробка SaaS на замовлення?
Вартість розробки SaaS на замовлення залежить від глибини мультитенантності, складності білінгу, кількості інтеграцій і вимог до відповідності нормам. SaaS MVP зазвичай займає 10-16 тижнів, продукт, готовий до B2B, 4-8 місяців, а подальша розробка йде за щомісячним бюджетом залежно від розміру команди.
Фіксовану ціну на кожен етап ми даємо після короткої розмови для оцінки обсягу. У нас SaaS-продукт коштує від 10 000 USD; наш посібник про вартість розробки MVP розбирає перший реліз. Щодо вибору стеку наше порівняння Symfony чи Laravel для SaaS пояснює, чому для довговічних продуктів ми за замовчуванням обираємо Symfony.
Коли не варто розробляти власний SaaS?
Не варто розробляти власний SaaS, коли наявний продукт покриває більшість ваших потреб, а ваша перевага не в самому програмному забезпеченні. Якщо вам потрібні внутрішня CRM, help desk чи трекер проєктів для власної команди, купити готовий інструмент зазвичай дешевше. Розробка SaaS на замовлення окупається, коли програмне забезпечення - це те, що ви продаєте, коли ваш процес настільки специфічний, що готові інструменти змушують до дорогих обхідних рішень, або коли вам потрібно на довгий термін володіти моделлю даних та інтеграціями. Корисна перевірка: якщо конкурент може скопіювати вашу пропозицію, купивши ту саму підписку, програмне забезпечення не є вашою конкурентною перевагою, і розробка його такою не зробить.
Як ми працюємо над SaaS-проєктами
Ми починаємо з короткого етапу оцінки обсягу: тенанти, ролі, тарифи, інтеграції й перший реліз, описані письмово й оцінені. Далі працюємо етапами зі щотижневим демо, код лежить у ваших репозиторіях, інфраструктура у ваших хмарних акаунтах. За архітектуру відповідають senior-інженери, які переглядають кожну зміну, а всередині команди ми використовуємо ШІ-агентів для написання коду, щоб пришвидшити розробку. Багато клієнтів після запуску залишаються з нами як з виділеною командою з розробки на Symfony.
Розкажіть, що робить ваш продукт і хто за нього платить, і ми запропонуємо перший реліз. Запишіться на консультацію щодо SaaS.