На чем написать SaaS-сервис

kirilljsx

Введение: SaaS — это не про «код», а про «кто платит»

На самом деле это довольно таки частый мозговой штурм когда идея плавно переходит к разработке и возникает вопрос, так на чем же мы будем писать проект? Я и сам иногда сталкиваюсь с таким вопрос, ну что берем Next js или же попробуем что-то из разрядов вон?

На самом деле выбор той или иной технологии решает много будущих задач, но не как не текущих. Написать сервис здесь и сейчас можно на любом языке и фреймворке. Однако стоит учесть если сервис окажется востребованным то придется его масштабировать по этому лучше заранее поразмыслить.

Подмечу, что это не гайд по выбору конкретной технологии под тот или иной сервис, а лишь рассуждение и подсказки для самых маленьких!

Шаг 0: Сначала бизнес-логика, потом технология

Пойдем поэтапно, главное проблема начинающих они смотря на большие компании и “О я тоже буду писать на react ведь так делает яндекс.”
Технологии это лишь инструмент, а не конечная цель.

Прежде всего стоит задать самому себе вопрос, какой у меня MVP?

Если это простой трекер задач - то не надо городить микросервисов на Kubernetes.
Какая у меня команда? Все знаю python, но никто не шарить за rust. Не надо делать это ради тренда.
Что будем важнее скорость или масштаб? Для стартапа конечно критична скорость и выход на рынок, для компаний же - отказоустойчивость.

В качестве примера возьмем известные компании разработавшие трекеры задач:

Trello начали с Ruby on Rails — быстро собрать MVP.
Slack выбрали React Native для кроссплатформенности, но позже частично переписал под натив (потому что «быстро» иногда бьет по UX).

Кстати! React Native и подобные вещи - не всегда хорошо, если проект масштабируется лучше заранее подумать о разработке под ios и android отдельно. (Но раз мы говорим про saas, можно просто вставить туда web Да, это п*здец, но может сработать.)

Думать, думать и еще раз думать, а не брать трендовые и хайповые язык как сейчас происходит с crystal который форсят на хабре.

Бэкенд наше все

1. Python + Django/Flask
Когда же стоит взять питон?

Если нужен быстрый MVP (Django «батарейки в комплекте»: аутентификация, админка, ORM и прочие плюшки).
Сервис связан с аналитикой или ML (библиотеки типа Pandas, TensorFlow).

Плюсы: Простота, огромное коммьюнити, дешевые разработчики.
Минусы: Медленнее Node.js/Go при высоких нагрузках.
А кто так делал?: Instagram и Pinterest стартовали на Django.

2. Node.js + Express/NestJS
То что я люблю . Когда же лучше взять:

Реалтайм-функции (чаты, совместный редактор).
Команда знает JavaScript (единый язык для фронтенда и бэкенда - идеальная связка).

Плюсы: Высокая производительность для I/O-нагрузок, легко масштабируется.
Минусы: Callback hell без правильной архитектуры.
Ну и кто же использует: Netflix и LinkedIn используют Node.js для API.

Кстати отдельно хочу подметить что многие для старта берут express и на нем же остаются, но я бы рекомендовал попробовать еще fastify и лучше в связке с nestjs.

3. Ruby on Rails
Когда берем:

Нужен MVP за 2–3 месяца (Rails автоматизирует 80% рутины).
Сервис с классической CRUD-логикой (CRM, управление проектами).

Плюсы: «Convention over configuration» — меньше кода, быстрее старт.
Минусы: Медленнее Python/Node при сложных вычислениях.
Кто юзал?: Shopify и Airbnb начинали на Rails.

4. Go или Java (Spring)
Если нужна большая многопоточность и распределение ресурсов:

Ожидаете 100K+ пользователей с первого дня.
Нужна максимальная отказоустойчивость (финтех, enterprise).

Плюсы: Высокая производительность, строгая типизация.
Минусы: Долгая разработка, дорогие разработчики.
Кто использует: Zoom использует Go для серверной части.

Фронтенд - красиво и быстро

Интерфейсы и все что мы любим:

React — стандарт де-факто (Next.js для SEO, если нужен маркетинговый блог в составе SaaS).
Vue.js — проще для новичков, но меньше готовых решений. Возможно еще стоит посмотреть в сторону Nuxt.
Svelte — для тех, кто ненавидит виртуальный DOM (меньше кода, выше скорость), отличной подойдет для веб компонентов.
Angular — если требуется максимально все типизировать и держаться строгости.

Мобильное приложение:

React Native — если команда знает JS (как у Tesla и Bloomberg).
Electron js — отличная альтернатива React Native, кстати VS Code сделан на нем.
Flutter — если важна производительность и кастомизация (использует Google Pay).
Натив (Swift/Kotlin) — только если ваш SaaS — это игра или соцсеть с тяжелой графикой.

Лайфхак: Для MVP хватит PWA (прогрессивное веб-приложение). Так делал Spotify до релиза нативных приложений и я кстати тоже так делаю

Где хранить данные, чтобы не сгорело

Базы данных

PostgreSQL — универсальный выбор для SaaS (поддерживает JSON, геоданные, масштабируется) и еще очень много фич под капотом.
MongoDB — если данные гибкие (например, кастомные поля в CRM).
Redis — для кэширования и очередей (обязателен при нагрузке).

Облако

AWS — сложнее, но мощнее (EC2, RDS, S3).
Vercel/Netlify — для статических фронтендов (дешево и быстро, но возможно не работает в РФ).
Railway.app — стартап-френдли (развертывает бэкенд за 5 минут).

Вообще развернуть базу довольно просто, недавно начал перетягивать проекты на TimeWeb - очень сильно обновились и предлагают кучу полезного в пару кликов

Не реклама если что))

Поговорим об ошибках

Не переусложняйте архитектуру — микросервисы для того же MVP для 100 пользователей.
Сложность продукта: разработка избыточного или перегруженного функциями продукта, что усложняет его использование
Отсутствие плана монетизации — бесплатный SaaS с 10K пользователей обанкротится быстрее, чем платный с 100.
Игнорирование исследования рынка, когда продукт создают без понимания реального спроса и потребностей
Недооценка важности UX/UI и пользовательского онбординга (Но это не всегда важно, ниже приведу цитату одной из ИТ компаний)

Цитата от основателя Calendly:
«Мы год потратили на идеальный дизайн, но пользователи ценили только одно: чтобы планирование занимало 2 клика. Все остальное — шум».

Технологии — это средство, а не смысл

SaaS-стартап умрет не из-за выбора Ruby вместо Python, а из-за того, что не решит реальную проблему. Лучший стек — тот, который:

Позволит запустить MVP за 3–6 месяцев.
Сможет поддерживать команда.
Будет легко масштабироваться, когда придут клиенты.

На последок: не пытайтесь найти идеальный стек технологий, возьмите то что знаете и потихоньку добавляйте новые технологии и смотрите в сторону пользователей. Старайтесь как можно больше получить обратной связи и тогда вы быстро поймете чего не хватает в вашем проекте.

Алекс44

Вот я как раз сейчас выбираю стек для SaaS-проекта в сфере образования. Команда у нас маленькая, все знают Python, но боюсь, что Django не потянет будущие нагрузки если пойдет рост. Может, сразу учить Go? Или это преждевременная оптимизация?

Wowk

Я бы на твоем месте стартовал на Django — он идеален для быстрого MVP. Когда упрешься в лимиты производительности (если упрешься!), тогда и будешь переписывать критические модули на Go. Сейчас главное — проверить гипотезу, а не строить супермасштабируемую систему с первого дня.

Василий

А мы в прошлом году запустили трекер задач на Node.js + Express. Сейчас уже 50к пользователей — начинаются проблемы с производительностью. Приходится переезжать на NestJS и добавлять Redis. Советую сразу закладывать архитектуру под рост, чтобы не переписывать всё потом.

Ванек

Вась, полностью согласен. Мы тоже начинали с монолита на Rails, а когда выросли — оказалось, что проще нанять команду под Go и переписать ядро, чем пытаться оптимизировать старый код. Но для старта Rails был идеален — за месяц сделали рабочий прототип.