Всем привет,
Появилась идея реализовать небольшой облачный сервис, но пока отсутствует понимание как правильно поступить с раскруткой, получением средств, лицензированием и хостингом, в связи с чем прошу совета у местных шароварщиков.
Сервис будет представлять собой небольшую учетную систему, которая может быть интересна мелкому и среднему бизнесу, в основном заграница, но РФ не исключается. По технологии это веб, ASP.NET Core (т.к. кое-какие наработки уже имеются; кроме того по ряду причин не хочется завязываться на Windows) + что-то для хранения данных. По оплате — планируется брать с клиентов помесячную оплату в зависимости от числа заявленных учетных записей (возможно, будет несколько вариантов: 1-10, 11-50, 51-100 и т.д.; или какая-то фиксированная сумма за одну учетную запись). Возможно, будет бесплатная версия для совсем мелких клиентов.
Администрировать это дело в первое время планируется своими силами, поэтому будет удобнее (привычнее) всего хостинг на виртуальной машине под Windows Server, с IIS и т.п. На первое время там же хотелось бы разместить и сайт.
А далее возникают вопросы:
1) Как сейчас работают такие хостинги? Дается доступ по RDP и дальше уже на машину необходимое ПО ставится самостоятельно? Или дается "панель управления" (сталкивался с этим лет 10 назад, когда изучал как захостить простой сайтик, не знаю как сейчас обстоят дела; тогда выглядело довольно неудобно...)? Если RDP, то как-то контролируется что туда ставится, допустим, пиратское ПО — я просто из любопытства интересуюсь? Что с надежностью? Там планируется хранить данные клиентов, бэкапы конечно будут, но не может ли произойти полная потеря всего? Кто сталкивался с таким, расскажите, пожалуйста, как выходили из ситуации, какую профилактику делали?
2) Нужен SSL-сертификат. Технически — исключительно для шифрования канала. Но с точки зрения клиентов — достаточно ли сертификата на домен (DV) или нужен сертификат на организацию (OV)? А может быть, можно прожить и без сертификата — но очень смущает все бОльшая ругань браузеров на поле-пароль + сертификат, например. В принципе, характер хранимых данных не сильно секретный предполагается, но не хотелось бы отпугнуть потенциальных клиентов.
3) Про домен вроде вопросов нет, но как раскрутить? Имеет ли смысл покупать всякие AdWords, большой от них толк? (напоминаю, сервис для бизнеса, не для физических лиц точно, и относительно нишевый). Или лучше сосредоточиться на упоминании на профильных ресурсах?
4) Прием платежей. Пока самая непонятная тема. Я так понял, регистраторы — это больше про десктоп, ключи и возврат средств. А что для веба более подходит — агрегаторы платежей? По-простому, на сайте хочется иметь кнопку "купить", поле для ввода номера корпоративной кредитки и чтобы уведомление о покупке приходило куда-то (куда?) (а в ответ создаются логины\пароли и отправляются клиенту), а также возможность автоплатежей (раз в месяц); не связываясь с техническими моментами обработки платежей, антифраудами и т.п., желательно — не связываясь с валютным контролем.
5) В контексте этого, как лучше организовать это юридически (РФ)? Вроде напрашивается ООО, но пока неизвестны перспективы — такой шаг выглядит преждевременным. ИП проще, но не будет ли тут проблем с агрегаторами платежей, не говоря уже про OV-SSL (его тоже надо регистрировать, платить налоги)? Или вообще начать как физическое лицо и потом думать (не будет ли подозрительно для банков регулярные платежи за тот же хостинг + получение средств, пусть и небольших)? Или есть смысл пожертвовать первыми покупками вообще, чтобы понять, заинтересуется ли кто-то?
K>1)
это можно на linux сделать K>2) Нужен SSL-сертификат.
letsencrypt K>3) как раскрутить?
Есть сервисы по раскрутке, можно руками K>4) Прием платежей.
payoneer K>5) В контексте этого, как лучше организовать это юридически (РФ)? K>Или вообще начать как физическое лицо
здравая идея K>и потом думать
Не важно, как деньги поступают, важно как с них уплачиваются налоги
Здравствуйте, Эйнсток Файр, Вы писали:
K>>3) как раскрутить? ЭФ>Есть сервисы по раскрутке, можно руками
Это рубрика "вредные советы"?
K>>4) Прием платежей. ЭФ>payoneer
Payoneer не для того. Необходимого функционала для подписок не имеет.
Здравствуйте, kiyu, Вы писали:
K>1) Как сейчас работают такие хостинги? Дается доступ по RDP и дальше уже на машину необходимое ПО ставится самостоятельно? Или дается "панель управления" (сталкивался с этим лет 10 назад, когда изучал как захостить простой сайтик, не знаю как сейчас обстоят дела; тогда выглядело довольно неудобно...)?
Возможны оба варианта.
Поскольку говоришь про .NET, то в студии сейчас есть кнопка, активно продвигаемая мелко-мягкими, "запаблиишь в интернете", она может всё за тебя сделать —
создать сайт (на azure), создать базу, задеплоить туда солюшен, и т.д.
K>Если RDP, то как-то контролируется что туда ставится, допустим, пиратское ПО — я просто из любопытства интересуюсь?
Всем пофик
K>Что с надежностью? Там планируется хранить данные клиентов, бэкапы конечно будут, но не может ли произойти полная потеря всего? Кто сталкивался с таким, расскажите, пожалуйста, как выходили из ситуации, какую профилактику делали?
Пропиши в лицензионном соглашении, если опасаешься.
Лучше всего ограничить свою материальную ответственность размером выплат клиента (чтобы клиенты случайно не отсудили твоую квартиру за потерю их данных)
K>2) Нужен SSL-сертификат. Технически — исключительно для шифрования канала. Но с точки зрения клиентов — достаточно ли сертификата на домен (DV) или нужен сертификат на организацию (OV)? А может быть, можно прожить и без сертификата — но очень смущает все бОльшая ругань браузеров на поле-пароль + сертификат, например. В принципе, характер хранимых данных не сильно секретный предполагается, но не хотелось бы отпугнуть потенциальных клиентов.
Если сайт на дефолтном домене azure например, или используешь letsencrypt, то SSL забесплатно.
Вообще с сертификатом SSL никаких проблем нет, его дадут где угодно. Проблемы (нотариусы и т.п.) возможны с сертификатом для подписывания кода (который тебе не нужен)
K>3) Про домен вроде вопросов нет, но как раскрутить? Имеет ли смысл покупать всякие AdWords, большой от них толк? (напоминаю, сервис для бизнеса, не для физических лиц точно, и относительно нишевый). Или лучше сосредоточиться на упоминании на профильных ресурсах?
Знал бы прикуп, жил бы в Сочи. Написать что-то — не проблема, проблема — продать.
K>4) Прием платежей. Пока самая непонятная тема. Я так понял, регистраторы — это больше про десктоп, ключи и возврат средств. А что для веба более подходит — агрегаторы платежей? По-простому, на сайте хочется иметь кнопку "купить", поле для ввода номера корпоративной кредитки и чтобы уведомление о покупке приходило куда-то (куда?) (а в ответ создаются логины\пароли и отправляются клиенту), а также возможность автоплатежей (раз в месяц); не связываясь с техническими моментами обработки платежей, антифраудами и т.п., желательно — не связываясь с валютным контролем.
У большинства регистраторов сейчас есть вариант "подписки" (кроме обычных лиценизий) со всеми фичами.
Если клинет подписывается, с его карты ежемесячно регистратор будет снимать бабло и переводить тебе на счет.
А так, можешь хоть себе на PayPal принимать (в этом случае поддержка неадекватных клиентов, взымание и выплата НДС/VAT/Что-там-вместо-VAT-в-Новой-Зеландии, а также фрод-чек — твоя забота).
Некоторые платежи я тупо приниимаю на свой банковский счет (клиету выписывается счет, он его оплачивает).
Понятно что это это долго (месяц-два), и это не имеет смысла делать для штучных покупок лицензий, я делаю примерно от сумм в ~1к
K>5) В контексте этого, как лучше организовать это юридически (РФ)? Вроде напрашивается ООО, но пока неизвестны перспективы — такой шаг выглядит преждевременным. ИП проще, но не будет ли тут проблем с агрегаторами платежей, не говоря уже про OV-SSL (его тоже надо регистрировать, платить налоги)? Или вообще начать как физическое лицо и потом думать (не будет ли подозрительно для банков регулярные платежи за тот же хостинг + получение средств, пусть и небольших)? Или есть смысл пожертвовать первыми покупками вообще, чтобы понять, заинтересуется ли кто-то?
Сначала получи хоть что-то (как физик), потом думать будешь.
K>1) Как сейчас работают такие хостинги? Дается доступ по RDP и дальше уже на машину необходимое ПО ставится самостоятельно? Или дается "панель управления" (сталкивался с этим лет 10 назад, когда изучал как захостить простой сайтик, не знаю как сейчас обстоят дела; тогда выглядело довольно неудобно...)? Если RDP, то как-то контролируется что туда ставится, допустим, пиратское ПО — я просто из любопытства интересуюсь? Что с надежностью? Там планируется хранить данные клиентов, бэкапы конечно будут, но не может ли произойти полная потеря всего? Кто сталкивался с таким, расскажите, пожалуйста, как выходили из ситуации, какую профилактику делали?
обычный dedicated сервер со всеми вытекающими
за деньги дадут с блэкджеком и бэкапами
за все установленное на сервер и за весь контент, генерируемый сервером, отвечает арендатор, т.е. вы
вобщем это тоже самое что поставить компьютер у себя дома. здесь он будет стоять в ДЦ и возможно виртуальный
K>2) Нужен SSL-сертификат. Технически — исключительно для шифрования канала. Но с точки зрения клиентов — достаточно ли сертификата на домен (DV) или нужен сертификат на организацию (OV)? А может быть, можно прожить и без сертификата — но очень смущает все бОльшая ругань браузеров на поле-пароль + сертификат, например. В принципе, характер хранимых данных не сильно секретный предполагается, но не хотелось бы отпугнуть потенциальных клиентов.
Без сертификата сейчас только говносайты и маргиналы. Простите если кого обидел. Но сайт без сертификата вызывает в 2018 году в лучшем случае недоверие.
K>3) Про домен вроде вопросов нет, но как раскрутить? Имеет ли смысл покупать всякие AdWords, большой от них толк? (напоминаю, сервис для бизнеса, не для физических лиц точно, и относительно нишевый). Или лучше сосредоточиться на упоминании на профильных ресурсах?
контентом раскрутить
честно и доступно писать что ваш сервис делает как работает и его обязательно найдут
K>4) Прием платежей. Пока самая непонятная тема. Я так понял, регистраторы — это больше про десктоп, ключи и возврат средств. А что для веба более подходит — агрегаторы платежей? По-простому, на сайте хочется иметь кнопку "купить", поле для ввода номера корпоративной кредитки и чтобы уведомление о покупке приходило куда-то (куда?) (а в ответ создаются логины\пароли и отправляются клиенту), а также возможность автоплатежей (раз в месяц); не связываясь с техническими моментами обработки платежей, антифраудами и т.п., желательно — не связываясь с валютным контролем.
avangate умеет (2checkout)
K>желательно — не связываясь с валютным контролем
Недавно перечитывал на хабре занимательную статью. Там товарищ чтобы не связываться с валютным контролем открыл ООО в Латвии, начал платить соц налоги, дивиденды, платить латвийским бухгалтерам, юристам, виртуальным офисам, аудиторам, и т.д, и т.п, и все это на фрилансерский свой заработок с апворка...
По сравнению со всем этим гемороем, валютный контроль не тянет даже на 1/20.
Ведь что такое по сути валютный контроль — это требование предоставить договор с понятными условиями оплаты и поставки услуг и исполнять этот договор с обоих сторон.
Такой договор можно на салфетке написать.
K>5) В контексте этого, как лучше организовать это юридически (РФ)? Вроде напрашивается ООО, но пока неизвестны перспективы — такой шаг выглядит преждевременным. ИП проще, но не будет ли тут проблем с агрегаторами платежей, не говоря уже про OV-SSL (его тоже надо регистрировать, платить налоги)? Или вообще начать как физическое лицо и потом думать (не будет ли подозрительно для банков регулярные платежи за тот же хостинг + получение средств, пусть и небольших)? Или есть смысл пожертвовать первыми покупками вообще, чтобы понять, заинтересуется ли кто-то?
Никак. Регистратора надо на физ. лицо. Простенький https letsencrypt без всяких (OV).
У регистратора выставить порог $2000 с которого тот начнет перечислять деньги.
Все.
Если вы параноик — это еще не значит, что за вами никто не следит
K>Появилась идея реализовать небольшой облачный сервис, но пока отсутствует понимание как правильно поступить с раскруткой, получением средств, лицензированием и хостингом, в связи с чем прошу совета у местных шароварщиков.
По сложности и непредсказуемости 99% — это раскрутка. Разработка и все остальные вопросы — 1%.
При этом с вероятностью 99% данный сервис просто никому не нужен в таком виде за такие деньги и вообще его нельзя внедрить.
Вот такая статистика по приведенным вводным данным.
Теперь скажу тебе как надо.
Создай сайт с описанием сервиса. Запроси тут порку сайта.
После этого попробуй продать то, что на сайте.
Если будет хотя бы 5 клиентов, напиши сюда опять, задумаемся о разработке, хостинге,сертификатах и приеме денег.
ЗЫ Хотя, по-хорошему, и сайт нельзя создавать на первом этапе проекта. Но это уже будет совсем сложно. Но если готов к такому, я скажу, с чего начать )
Здравствуйте, maks__, Вы писали:
__>Теперь скажу тебе как надо. __>Создай сайт с описанием сервиса. Запроси тут порку сайта. __>После этого попробуй продать то, что на сайте. __>Если будет хотя бы 5 клиентов, напиши сюда опять, задумаемся о разработке, хостинге,сертификатах и приеме денег.
__>ЗЫ Хотя, по-хорошему, и сайт нельзя создавать на первом этапе проекта. Но это уже будет совсем сложно. Но если готов к такому, я скажу, с чего начать )
как вы считаете а с идей программы как лучше начинать ?
__>>Теперь скажу тебе как надо. __>>Создай сайт с описанием сервиса. Запроси тут порку сайта. __>>После этого попробуй продать то, что на сайте. __>>Если будет хотя бы 5 клиентов, напиши сюда опять, задумаемся о разработке, хостинге,сертификатах и приеме денег.
__>>ЗЫ Хотя, по-хорошему, и сайт нельзя создавать на первом этапе проекта. Но это уже будет совсем сложно. Но если готов к такому, я скажу, с чего начать )
S>как вы считаете а с идей программы как лучше начинать ?
Для успеха проекта нужно иметь какое-то преимущество перед другими участниками рынка.
Идея должна быть в той области, где у вас есть преимущество: связи, опыт работы в области, наработки, выход на покупателей, дешевый канал сбыта, дешевые программисты и т.п.
Здравствуйте, kiyu, Вы писали:
K>4) Прием платежей. Пока самая непонятная тема. Я так понял, регистраторы — это больше про десктоп, ключи и возврат средств. А что для веба более подходит — агрегаторы платежей? По-простому, на сайте хочется иметь кнопку "купить", поле для ввода номера корпоративной кредитки и чтобы уведомление о покупке приходило куда-то (куда?) (а в ответ создаются логины\пароли и отправляются клиенту), а также возможность автоплатежей (раз в месяц); не связываясь с техническими моментами обработки платежей, антифраудами и т.п., желательно — не связываясь с валютным контролем.
BrainTree.com и CloudPayments.ru — первые платежные решения, с которых вам стоит начать изучение. От их юридических требований и пляшите. (Валютный контроль — меньшее из зол при работе с такими агрегаторами.)
Здравствуйте, bnk, Вы писали:
K>>Что с надежностью? bnk>Пропиши в лицензионном соглашении, если опасаешься. bnk>Лучше всего ограничить свою материальную ответственность размером выплат клиента (чтобы клиенты случайно не отсудили твоую квартиру за потерю их данных)
Это само собой, да.
Просто при хранении всего в одном месте в случае полной потери данных — проблемы будут у всех клиентов сразу. Но, наверное, об этом рано думать.
K>>Прием платежей. bnk>У большинства регистраторов сейчас есть вариант "подписки" (кроме обычных лиценизий) со всеми фичами. bnk>Если клинет подписывается, с его карты ежемесячно регистратор будет снимать бабло и переводить тебе на счет.
А как это выглядит для клиента? Оплата, и потом он ждет когда я с ним свяжусь чтобы передать логины\пароли? Чтобы подключить клиента мне нужно будет сделать ряд телодвижений (завести хранилище, какую-то конфигурацию, в т.ч. ограничение на число пользователей — такого рода вещи). Можно, конечно, первое время вручную все это делать, но хотелось, бы чтобы клиент нажал "купить N учетных записей" и автоматически все создалось — вопрос, как получить данные о платеже (кто заплатил, сколько) от регистратора программно?.
bnk>А так, можешь хоть себе на PayPal принимать (в этом случае поддержка неадекватных клиентов, взымание и выплата НДС/VAT/Что-там-вместо-VAT-в-Новой-Зеландии, а также фрод-чек — твоя забота).
С PayPal более-менее ясно, но забот как раз не хотелось бы.
Здравствуйте, c3p0, Вы писали:
K>>3) Про домен вроде вопросов нет, но как раскрутить? C>контентом раскрутить C>честно и доступно писать что ваш сервис делает как работает и его обязательно найдут
За последние годы у меня почему-то создалось впечатление, что просто описать все и найдут — не очень работает. Возможно, я ошибаюсь... В любом случае, сайт, толковое описание — планируются.
C>Ведь что такое по сути валютный контроль — это требование предоставить договор с понятными условиями оплаты и поставки услуг и исполнять этот договор с обоих сторон. C>Такой договор можно на салфетке написать.
Я так понимаю, в моем случае договор нужен между мной и регистратором?
Здравствуйте, maks__, Вы писали:
__>Теперь скажу тебе как надо. __>Создай сайт с описанием сервиса. Запроси тут порку сайта. __>После этого попробуй продать то, что на сайте. __>Если будет хотя бы 5 клиентов, напиши сюда опять, задумаемся о разработке, хостинге,сертификатах и приеме денег.
Не очень понял, как предлагается найти 5 клиентов, готовых купить что-то еще до того как оно разработано?
__>ЗЫ Хотя, по-хорошему, и сайт нельзя создавать на первом этапе проекта. Но это уже будет совсем сложно. Но если готов к такому, я скажу, с чего начать )
Без сайта не готов (да и в создании сайта я не вижу каких-то проблем), но т.к. сайта у меня сейчас все равно нет — интересно будет узнать с чего начать без сайта.
Здравствуйте, kiyu, Вы писали:
K>Просто при хранении всего в одном месте в случае полной потери данных — проблемы будут у всех клиентов сразу. Но, наверное, об этом рано думать.
Ну обычно ежедневный бэкап всего идет в комплекте с хостингом.
K>>>Прием платежей. bnk>>У большинства регистраторов сейчас есть вариант "подписки" (кроме обычных лиценизий) со всеми фичами. bnk>>Если клинет подписывается, с его карты ежемесячно регистратор будет снимать бабло и переводить тебе на счет. K>А как это выглядит для клиента? Оплата, и потом он ждет когда я с ним свяжусь чтобы передать логины\пароли? Чтобы подключить клиента мне нужно будет сделать ряд телодвижений (завести хранилище, какую-то конфигурацию, в т.ч. ограничение на число пользователей — такого рода вещи). Можно, конечно, первое время вручную все это делать, но хотелось, бы чтобы клиент нажал "купить N учетных записей" и автоматически все создалось — вопрос, как получить данные о платеже (кто заплатил, сколько) от регистратора программно?.
У регистратора как правило есть API для вендора, т.е. при поступлении заказа, создании подписки, удалении подписки, и т.п. они могут вызывать тебя (твой сайт), передавая все данные (как правило, POST-запросом на твой сайт).
Это все настраивается в панельке вендора. Тебе нужно просто поставить чекбоксы какие на какие события нужно вызывать твой сервис, указать URL-ы и параметры которые ему нужно передеавать. Ну и реализовать сами обработчики на твоем сайте, понятно (чтобы они по запросу заводили хранилище, конфигурацию или что там надо). Пример PPG (IPN, Instant Payment Notification):
C>>честно и доступно писать что ваш сервис делает как работает и его обязательно найдут K>За последние годы у меня почему-то создалось впечатление, что просто описать все и найдут — не очень работает. Возможно, я ошибаюсь... В любом случае, сайт, толковое описание — планируются.
Если на сайте три странички с описанием, то да, не найдут.
Если 1000 страниц, то найдут обязательно.
документация
блог
FAQ
случаи использования
и т.д.
если ваш софт действительно имеет ценность для пользователя, а контент написан для людей,то его будут читать и поднимется в поисковиках за счет поведенческого фактора.
если унылое описание на 3 html страницы, то да, не очень работает
>Я так понимаю, в моем случае договор нужен между мной и регистратором?
Регистратор обычно дает оферту. Она и есть договор.
>Не очень понял, как предлагается найти 5 клиентов, готовых купить что-то еще до того как оно разработано?
Самый простой способ — нати таких клиентов, которые готовы это заказать как custom software development с неисключительными правами.
Если вы параноик — это еще не значит, что за вами никто не следит
__>>Теперь скажу тебе как надо. __>>Создай сайт с описанием сервиса. Запроси тут порку сайта. __>>После этого попробуй продать то, что на сайте. __>>Если будет хотя бы 5 клиентов, напиши сюда опять, задумаемся о разработке, хостинге,сертификатах и приеме денег. K>Не очень понял, как предлагается найти 5 клиентов, готовых купить что-то еще до того как оно разработано?
Надо понять, что поиск клиентов никак не связан с тем, разработан продукт или нет.
__>>ЗЫ Хотя, по-хорошему, и сайт нельзя создавать на первом этапе проекта. Но это уже будет совсем сложно. Но если готов к такому, я скажу, с чего начать ) K>Без сайта не готов (да и в создании сайта я не вижу каких-то проблем), но т.к. сайта у меня сейчас все равно нет — интересно будет узнать с чего начать без сайта.
С процесса под названием Customer Development: проблемное интервью, решенческое интервью. На ютубе есть лекции на эту тему.
Потом надо сделать продажи, добиться того, что клиент готов внести предоплату. Если продажи будут, начинать делать продукт.
K>Всем привет, K>Появилась идея реализовать небольшой облачный сервис..
Еще раз всем привет,
По прошествии 8 месяцев, ситуация с начатой темой следующая:
Облачный сервис — учетная система для проектов, задач и затрат — частично разработан, сайт — тоже, все выложено где-то месяц назад в Интернет, тут: https://yuboki.com
Из первоначальных вопросов все решено (в том числе благодаря советам отсюда), кроме раскрутки. Поэтому я снова хочу спросить совета у местных бывалых...
1) Есть ли смысл в SEO сайта в настоящее время? Когда-то это было актуально, но, может быть, google и другие bot-ы с тех пор поумнели и их возможности анализа содержимого улучшились? В первую очередь, я имею ввиду meta-теги, h1\h2\h3-теги, карты сайта, robots.txt и т.п. вещи. Есть ли смысл пытаться написать кучу страниц контента в надежде на лучшую индексацию поисковиками?
2) Ниша высококонкурентная, есть ли вообще смысл пытаться влезть на первые страницы google(без покупки рекламы у него же)? Есть ли смысл в рекламе, Adwords и т.п.?
3) Видел очень много "каталогов SaaS", стоит ли попробовать зарегистрироваться там?
4) Стоит ли попробовать написать о продукте в Wiki?
5) Идея с профильными форумами — актуально ли это? Или лучше ориентироваться на соцсети, а форумы умирают?
Ну и, конечно, интересен свежий взгляд на сайт со стороны
Здравствуйте, kiyu, Вы писали:
K>1) Как сейчас работают такие хостинги? Дается доступ по RDP и дальше уже на машину необходимое ПО ставится самостоятельно? Или дается "панель управления" (сталкивался с этим лет 10 назад, когда изучал как захостить простой сайтик, не знаю как сейчас обстоят дела; тогда выглядело довольно неудобно...)? Если RDP, то как-то контролируется что туда ставится, допустим, пиратское ПО — я просто из любопытства интересуюсь? Что с надежностью? Там планируется хранить данные клиентов, бэкапы конечно будут, но не может ли произойти полная потеря всего? Кто сталкивался с таким, расскажите, пожалуйста, как выходили из ситуации, какую профилактику делали?
Если покупаешь чистый хостинг, дадут VNC. Вставишь ISO, установишь венду, настроишь RDP и соединяйся уже по RDP. Если покупаешь специальный Windows хостинг, то дадут RDP, но это будет стоить значительно дороже из-за лицензии. Не думаю, что кто-то будет сканировать твои образы на предмет пиратского ПО, это никому не надо. Я пиратскую венду крутил на vultr, проблем не было. Гарантированной надёжности нет, всё может полететь в любой момент, никто за тебя бэкапы делать не будет. Просто имей план восстановления.
K>2) Нужен SSL-сертификат. Технически — исключительно для шифрования канала. Но с точки зрения клиентов — достаточно ли сертификата на домен (DV) или нужен сертификат на организацию (OV)? А может быть, можно прожить и без сертификата — но очень смущает все бОльшая ругань браузеров на поле-пароль + сертификат, например. В принципе, характер хранимых данных не сильно секретный предполагается, но не хотелось бы отпугнуть потенциальных клиентов.
Letsencrypt — DV-сертификат на халяву. Не знаю, зачем тебе OV, ты же не банк. Даже у гугла DV.
K>4) Прием платежей. Пока самая непонятная тема. Я так понял, регистраторы — это больше про десктоп, ключи и возврат средств. А что для веба более подходит — агрегаторы платежей? По-простому, на сайте хочется иметь кнопку "купить", поле для ввода номера корпоративной кредитки и чтобы уведомление о покупке приходило куда-то (куда?) (а в ответ создаются логины\пароли и отправляются клиенту), а также возможность автоплатежей (раз в месяц); не связываясь с техническими моментами обработки платежей, антифраудами и т.п., желательно — не связываясь с валютным контролем.
Здравствуйте, kiyu, Вы писали:
K>Ну и, конечно, интересен свежий взгляд на сайт со стороны
1. Многие кнопки вкривь, вкось.
2. Приложение так и не удалось запустить.
3. Нет адаптивного дизайна, на планшете, телефоне все криво, косо.
4. Не очевидно и не нашел где оплачивать и как.
Что с надежностью? Там планируется хранить данные клиентов, бэкапы конечно будут, но не может ли произойти полная потеря всего? Кто сталкивался с таким, расскажите, пожалуйста, как выходили из ситуации, какую профилактику делали? 
