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

жиза?
жиза?

У одного панель выглядит так, будто её делали под Windows XP. У другого скидка внезапно оказывается переплатой. У третьего тарифы обновляются так часто, что не успеваешь привыкнуть — сегодня одни конфиги, завтра уже другие. Плюс у каждого свой биллинг: где-то списания раз в месяц, где-то раз в сутки, а где-то вообще почасово.

И чем больше проектов, тем больше это превращается в рутину. А когда что-то становится рутиной, программист обычно думает: «А нельзя ли это автоматизировать?»

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

Как родилась идея?

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

Получилось неожиданно удобно: вместо десятка вкладок — аккуратная сводка в одном месте. Я пользовался этим сам, экономив время, нервы, и, самое главное, деньги, ведь знал у кого выгоднее всего брать. Позднее я случайно поделился ссылкой на табличку в одном тематическом чатике. Оказалось, что на неё есть спрос, и я не один с такой проблемой.

В этот момент стало ясно: одной табличкой дело не ограничится, можно сделать полноценный сервис с централизованным биллингом и возможностью заказать виртуалку у любого провайдера в одном месте.

Конечно, кто-то может возмутиться: «Есть же сервисы сравнения тарифов, да и скидки дают!» Но готовые решения не закрывали главную проблему. В них не было централизованного биллинга: даже если данные собирались, арендовать всё равно приходилось у каждого провайдера отдельно. Да и интерфейсы там устаревшие, данные не всегда актуальны, а реальные тарифы приходилось перепроверять вручную. 

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

Перед тем как бросаться в полноценную разработку, я собрал команду и мы сформулировали несколько гипотез. Ведь могло оказаться, что спроса нет и большинству удобно как есть. Действительно, у многих пользователей есть один «любимый» провайдер, и им незачем что-то менять. 

Но я решил мыслить как французский градостроитель Осман, который когда-то перестроил весь Париж. Сначала это было жутко непривычно, а потом стало удобнее для всех. В моём случае даже сносить ничего не требовалось — только построить новое.

Были и сомнения: сможем ли договориться с провайдерами? Не все компании рады агрегаторам, особенно если речь идёт о ценовой конкуренции. Сложности добавляла и интеграция: у кого-то API своё, у кого-то вообще его нет, кто-то до сих пор живёт на SOAP-протоколе из 2009 года. 

Да, есть BillManager как универсальный вариант, но его используют далеко не все. Сложнее всего было с теми, у кого своя кастомная панель, как у Timeweb. Под таких было необходимо разрабатывать отдельные связки. Ну и финансовые риски: у каждого партнёра свои правила списаний, и было непонятно, как всё это свести в единый прозрачный биллинг. 

Я даже консультировался с советником по финансам (ChatGPT), он уверенно заявил, что шансов окупиться мало. Но я посчитал, что идея сильнее проблем.

Чтобы система не развалилась при первом же заказе, мы собрали MVP: фронт на Next.js, бэкенд на FastAPI, слой Providers API — наш переводчик между системой и API хостеров, база на PostgreSQL с Redis, а для асинхронщины — RabbitMQ. Архитектуру сделали модульной, чтобы можно было спокойно подключать новых провайдеров.

схема работы сервиса
схема работы сервиса

Первые тесты показали самое главное: боль всё-таки реальная, идея работает, технически, конечно, и правда сложно, но решаемо. И для меня это стало подтверждением: из «таблички для себя» может вырасти сервис, который реально облегчает жизнь другим.

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

Большинство хостеров помимо рефералок предлагают партнёрку: они дают скидку на свои услуги, а дальше можно продавать по обычной цене и забирать разницу. Это не «серая перепродажа», а нормальная модель, основанная на взаимовыгодном сотрудничестве. У неё сразу несколько плюсов: я могу выставлять цены такие же, как у самого провайдера, могу заработать больше, чем на рефералках, и при этом не нарушаю законов или правил хостеров.

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

Как и полагается серьёзному стартапу, мы хорошо подготовились к презентации (нет) и радостно отправились на встречу. Без должной подготовки мы, конечно же, запутались в объяснениях и получили отказ. Чувство было, будто мы пришли на вечеринку, но нас тут же выставили за дверь.

Зато это стало хорошим уроком. Мы пересобрали презентацию, упростили подачу и на следующей встрече реакция оказалась прямо противоположной: нас выслушали, загорелись и даже предложили помощь. В этот момент стало окончательно ясно: идея рабочая, просто её нужно правильно подать.

И это только начало. Впереди были десятки новых задач, сложные интеграции, споры, переговоры и бесконечные баги, о чём я ещё расскажу в следующих статьях. Но уже тогда стало понятно, что путь выбран правильно: хаос можно превратить в порядок, а рутину в удобный сервис. И ради этого стоило взяться за дело.

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

Комментарии (2)


  1. MEGA_Nexus
    09.10.2025 19:48

    Первые тесты показали самое главное: боль всё-таки реальная, идея работает, технически, конечно, и правда сложно, но решаемо. И для меня это стало подтверждением: из «таблички для себя» может вырасти сервис, который реально облегчает жизнь другим.

    Тут не совсем верно. Если вы будете помогать клиентам с выбором нужных ресурсов, то вы будете лишним посредником в звене "клиент - вы - хостер". Провайдер изменил свой биллинг или обновил систему заказа ресурсов - у вас всё отвалилось и клиенту придётся напрямую обращаться не к вам, а к родительскому хостингу, где реально находятся его ресурсы.

    Намного выгоднее, если клиенты будут обращаться к вам, а вы там уже сами решаете, где и у кого его разместить, т.е. клиент не будет знать, что у вас там в бекэнде находится. В этом случае вы будете единой точкой у клиента, а для хостеров станете партнёром, поэтому все свои обновления биллингов они будут согласовывать с вами, чтобы у вас там ничего не отвалилось. Иными словами, вы будете как виртуальный провайдер услуг (аналог MVNO - Mobile Virtual Network Operator).


  1. MEGA_Nexus
    09.10.2025 19:48

    В качестве альтернативного варианта вы можете просто сделать конфигуратор или список с лучшими конфигурациями, где будут ваши реферальные ссылки. Клиенты, переходя с них будут закупать ресурсы у хостингов, а хостинги будут платить вам некую сумму за привлечение клиента по вашей рефералке. Это самая простая модель и с неё можно начать, чтобы получить первоначальный капитал для вашей основной идеи.