
Привет! Меня зовут Алексей, и я занимаюсь разработкой мобильных и веб-приложений на заказ, а также создаю корпоративные системы, панели управления, мессенджеры и другие инструменты для автоматизации бизнес-процессов и задач бизнеса. Вместе с моей небольшой студией AK-DEVS мы превращаем идеи в работающие цифровые продукты.
Публикую свои мысли и инсайты на тему разработки и бизнеса в моем ТГ-канале
Подписывайтесь, кстати
![]()
Сегодня поговорим о граблях, на которые наступает каждый второй стартапер или владелец уже действующего бизнеса. Нет, не про то, как нанимать друзей или доверять партнёрам без договора — это тема для отдельной драмы Сегодня разберем, как не прос... просадить весь бюджет на серверах, когда ваш стартап наконец-то начал взлетать.
Каждый амбициозный предприниматель мечтает о росте своего бизнеса. Но есть подводный камень, о который спотыкаются даже опытные бизнесмены — выбор серверной инфраструктуры. Неправильное решение может привести либо к потере клиентов из-за медленной работы сервиса, либо к неоправданно высоким расходам на слишком мощное оборудование.
Почему это важно, или Истории из жизни
История первая: "Облачный" сюрприз
Представьте ситуацию: вы запустили крутой проект, который неожиданно начал расти. Клиенты идут, деньги капают, вы уже мысленно паркуете 223 у офиса... И тут бац! Сайт падает под нагрузкой, а техдир в панике пишет в слак: "Нам срочно нужно в облака!". Через месяц вы смотрите на счет от Amazon и понимаете, что придется продать почку. Знакомо?
История вторая: "Как в Netflix!"
Или другая ситуация: вы, начитавшись модных статей про облака и микросервисы, сразу заряжаете проект на AWS. "Как в Netflix!" - говорите вы команде. А через полгода плачете, глядя на счета за сервера, которые используются на 10% своей мощности. Спойлер: Netflix можно, а вам пока нет.
История третья: "Firebase за 100k USD в месяц"
А вот вам реальный кейс из жизни, от которого я тоже охре... удивился.
На Новогодних праздниках ко мне записался на консультацию фаундер одного из стартапов с просьбой переработать уже существующее приложение и показал счет от Google Cloud за Firebase, Storage и еще несколько сервисов от Google на 100k+ USD/месяц.
И это при всего 78 000 MAU (активных пользователей в месяц)!
В чем была проблема? Основные расходы были на облачную бд Google Cloud - Firestore, из-за небольшой ошибки в архитектуре приложения при обновлении списка чатов у пользователя в мессенджере внутри приложения - выполнялось по 50 000 запросов за один раз, у каждого пользователя!
В итоге количество операций чтения в Firestore доходило до 2 МИЛЛИАРДОВ в день, КАРЛ! А количество операций записи в бд — до 1 миллиарда/дейли

Тут должен был быть нудный текст про виды баз данных, особенности подсчета запросов и прочее душнилово, но я вас пожалею :-)
У Google ресурсов много, ему не жалко — любой каприз за ваши деньги. А обычный
В защиту сторонних разработчиков этого приложения скажу — от ошибок никто не застрахован, но фаундерам на заметку: если используете облака и любые другие опции с гибкой тарификацией — ВСЕГДА ставьте лимиты бюджетов и мониторьте расходы ежедневно хотя бы первое время.
Очень жаль потраченные деньги на разработку, но когда месячные расходы более чем в 2 раза больше стоимости разработки похожего проекта с нуля в нашей студии - вариантов кроме как переделывать приложение особо не остается
…В итоге решили вместе с уже клиентом переделать это приложение на использование Supabase — это современная платформа, построенная на основе PostgreSQL, которая отлично подходит для управления данными и упрощает работу с серверной частью. По сути, это такой удобный инструмент, который предоставляет базу данных с API “из коробки”.
Дополнительно выбрали достаточный на данный момент ), если архитектура проекта нормально оптимизирована.
Благодаря переходу на Supabase и отказу от облачных сервисов удастся:
-
сократить ежемесячные расходы более чем в 2000 раз;
-
улучшить производительность за счёт правильной настройки базы данных;
-
избавиться от скрытых переплат за “удобные” сервисы, которые в итоге оказались просто дорогими.
Это отличный пример того, как грамотная инфраструктура может сэкономить бюджет и помочь стартапу сфокусироваться на развитии, а не на погашении счетов за облачные сервисы.
Когда реально нужны облака:
-
Когда инвесторы сказали "надо" (и дали денег)
-
Когда у вас реально сотни тысяч и миллионы пользователей
-
Когда вам позарез нужны их специальные сервисы типа AI или анализа больших данных и то можно подключить их по API например
VPS/VDS: ваш лучший друг на старте
Виртуальный сервер — это как студия в спальном районе. Не так пафосно, зато своё и платежи адекватные. За $10-50 в месяц вы получаете нормальный сервер, который потянет большинство проектов на старте. И да, это не опечатка — реально от 10 баксов.
Главное преимущество — вы платите только за то, что реально нужно. Никаких сюрпризов в конце месяца, никаких скрытых платежей за "премиальный воздух в датацентре". Просто честный сервер за честные деньги.
Выделенные серверы: для тех, кто дорос
Давайте поговорим про нагрузку, или Почему RPS это не рок-группа
RPS (запросы в секунду) — это сколько раз в секунду пользователи дёргают ваш сервер. Представьте, что это очередь в популярный бар: если охранник (ваш сервер) не успевает всех впускать, у входа начинается давка, а потом драка и все разбегаются. В нашем случае — пользователи уходят к конкурентам.
Как посчитать RPS:
(Количество активных пользователей в час × Среднее количество их действий в минуту) ÷ 60 = Запросы в секунду (RPS)
Формула для расчета
Например, если у вас 1000 пользователей в час, и каждый делает примерно 5 кликов в минуту, получаем: (1000 × 5) ÷ 60 = 83 запроса в секунду.
Какой сервер вам реально нужен
Для тех, кто только запустился (до 50 RPS):
Вам хватит простого
Для растущих проектов (50-500 RPS):
Пора думать о мощном
Для серьёзных пацанов (500+ RPS):
Тут уже без мощных выделенных серверов, облаков и прочих кубернетисов - никуда. От $150 в месяц, и это только начало. Но если у вас такая нагрузка — скорее всего, вы уже можете себе это позволить
Как понять, что пора апгрейдиться
Есть несколько верных признаков:
-
Время ответа сервера стабильно превышает 200-300 мс
-
Появляются ошибки при пиковых нагрузках
-
Нагрузка на CPU держится стабильно выше 80%
-
Памяти остаётся меньше 20%
Так же если у вас Стартап - не бойтесь что сервер ляжет от нагрузки, во первых до этого нужно еще дорасти, и "переехать" на более мощный сервер не так сложно. А еще хочу поделиться, может, не самым популярным наверное мнением: если сервер лег — значит, вы реально достигли успеха! Ваш проект живет, развивается, привлекает внимание, и это отличный знак! Переезжаем на более крутой сервер и ставим перед собой новую цель — снова “положить” его, разгоняя бизнес дальше!
Подробнее про масштабирование, Kubernetes и прочие фентиплюшки — это тема для отдельной статьи
Реальные тесты на реальном железе
Как мы мучали сервер за 700 рублей
А вот вам реальный кейс из жизни: только что сданный проект приложения с backend частью на Supabase Self Hosted, крутящийся на простеньком
Чтобы не быть голословными, как и всегда при сдаче проекта, мы решили устроить нашему — мы использовали Grafana k6 для стресс-тестирования. Если вы не знаете, что это такое, представьте толпу голодных студентов, штурмующих столовку в перерыве между парами. Примерно так же k6 генерирует нагрузку на ваш сервер.
Не буду грузить вас техническими подробностями (хотя постойте, грузить — это же как раз то, чем занимается k6), но суть такая: мы постепенно увеличивали количество виртуальных пользователей, пока наш сервер не начал просить пощады.

Что мы намерили:
-
93.33 RPS (Requests Per Second, а не Рок Против Спида)
-
Время ответа 72 мс
-
0 ошибок
И всё это на достаточно сложном, комбинированном запросе к нескольким таблицам в БД — с JOIN'ами и прочими SQL-извращениями. И наш малыш справился!
Это показывает, что даже бюджетный
Ключевые факторы успеха:
-
Оптимизация базы данных
-
Правильная настройка кеширования
-
Грамотное управление соединениями
-
Отсутствие лишних сервисов, которые съедают ресурсы
Финальные мысли, или Как не облажаться
Начинайте с малого. Серьёзно. Нет ничего постыдного в том, чтобы стартовать с простого
И помните: крутой стартап, как и любой бизнес — это не тот, который сидит в самом дорогом облаке, а тот, который приносит деньги. А сэкономленные на серверах деньги лучше потратить на разработку или маркетинг. Ну или на пиво команде — тоже хороший вариант!
P.S. Тема очень обширная, тут можно целую книгу написать. Если у вас есть вопросы — задавайте в комментариях, постараюсь помочь. Есть экспертиза в Разработке/DevOps/продукте, так что обязательно что-нибудь придумаем.
Подписывайтесь на мой телеграм-канал, где я буду регулярно делится подобными кейсами из практики и техническими лайфхаками. А для тех, кому нужна персональная консультация — всегда открыт к диалогу
Главное помните: технологии должны помогать бизнесу расти, а не тянуть его на дно необоснованными расходами.
Удачи в развитии ваших проектов!
Автор: NEXT579