Начинаешь с «просто закинуть документ в нейронку», потом добавляешь историю разборов, пользователей, платежи, уведомления, админку, аналитику — и в какой-то момент обнаруживаешь, что незаметно написал CRM.
Поэтому тут для меня как раз важно вовремя остановиться и не превращать узкий сервис с одной понятной функцией в комбайн «для всего».
Вот тут вообще не спорю. Более того, для меня это, пожалуй, самая интересная часть всего эксперимента.
Код я так или иначе напишу. А вот найти людей, которым продукт действительно нужен, объяснить им его ценность, довести до первой оплаты, понять стоимость привлечения и потом добиться повторных покупок - совсем другая задача.
Поэтому и решил писать о проекте ещё в процессе разработки, а не сначала несколько месяцев делать продукт в вакууме, а потом внезапно обнаружить, что продавать его некому.
Так что в моём случае эксперимент скорее не «смогу ли я навайбкодить SaaS», а «смогу ли я его кому-нибудь продать». :)
А вот вам, судя по описанию, моя надстройка действительно может быть не нужна :)
Вы уже знаете, что документ можно отдать нейросети, знаете, что у неё спросить, умеете оценить полученный ответ и при необходимости задать дополнительные вопросы. Если такой сценарий полностью закрывает вашу задачу - платить отдельному сервису просто незачем.
Но я исхожу из того, что не все пользователи нейросетей работают с ними так же. Для кого-то задача выглядит не как «загрузить документ в ChatGPT, попросить проверить риски, потом уточнить спорные моменты и перепроверить ссылки на нормы», а просто как «мне дали договор, я ничего в нём не понимаю — скажите человеческим языком, что здесь написано и где меня могут подловить».
Вот этот сценарий я и пытаюсь упаковать в отдельный продукт: отправил документ - получил разбор по заранее определённой логике без необходимости самому вести диалог с универсальной нейросетью.
А насчёт ссылок на статьи - здесь я бы как раз был осторожен. LLM действительно умеют довольно убедительно работать с законодательством, но «убедительно» не всегда означает «актуально и точно». Поэтому одна из вещей, которые я рассматриваю для развития сервиса, - проверка выводов по собственной актуализируемой нормативной базе, а не просто надежда на знания модели.
Ну и главный вопрос остаётся прежним: достаточно ли людей, которым такой специализированный сценарий удобнее обычного ChatGPT и которые готовы за это платить. Это я как раз и хочу проверить, а не принимать как данность.
С большей частью, кстати, согласен. Особенно с тем, что «сделаю SaaS за 1000 ₽, найду 1000 человек и получу миллион» - это не бизнес-модель, а арифметика :)
Но я как раз не хочу идти по сценарию «полгода пилим идеальную архитектуру, потом впервые спрашиваем, нужно ли это кому-нибудь».
Поэтому и пишу о проекте публично ещё на этапе разработки. Комментарии в духе «а зачем это, если я могу закинуть документ в обычную нейросеть?» для меня сейчас полезнее ещё одной недели разработки. Они довольно быстро проверяют, насколько вообще внятно я могу ответить на вопрос, за что здесь должен платить пользователь.
С экономикой та же история. Здесь не будет классической подписки «1000 ₽ в месяц» просто потому, что для обычного человека юридические документы - не ежедневная потребность. Поэтому модель изначально строю вокруг разовых разборов и пакетов: заплатил тогда, когда понадобилось. Дальше уже надо считать стоимость привлечения, стоимость самого разбора, конверсию в оплату и повторные покупки. Если цифры не сходятся - значит, продукт не сходится, сколько бы кода в нём ни было.
Правовую часть тоже откладывать «на потом» не собираюсь. Здесь документы пользователей, потенциально персональные данные, платежи — соответственно, до публичного запуска должны быть нормально оформлены обработка данных, пользовательские условия и сама схема приёма платежей.
А вот с «очередная обёртка над ChatGPT API никому не нужна» я бы не был настолько категоричен. Огромное количество продуктов - это в той или иной степени удобная упаковка существующей технологии под конкретный сценарий. Вопрос не в наличии обёртки как таковой, а в том, даёт ли она пользователю достаточно дополнительной ценности, чтобы он был готов за неё платить.
Собственно, это и хочу проверить. Не получится найти аудиторию, сформулировать отличие и свести экономику - значит, закрою проект. Тоже вполне полезный результат.
Да, это действительно один из главных минусов отдельных SaaS.
Никому не хочется иметь 30 сервисов: один для договора, второй для резюме, третий для картинок, четвёртый ещё для чего-нибудь.
Поэтому отдельный сервис имеет смысл только тогда, когда он убирает достаточно действий по сравнению с универсальным инструментом.
В моём случае я как раз поэтому выбрал Telegram, а не стал делать ещё один сайт с регистрацией, личным кабинетом и отдельным приложением. Бот уже находится там, где пользователь и так общается: отправил ему документ - получил разбор.
А дальше вопрос исключительно продуктовый: достаточно ли удобнее такой сценарий, чтобы люди им пользовались. Это и хочу проверить.
Непосредственно над сервисом работаю один. Пока что помогает опыт преподавания и репетиторства, связанный в том числе, с анализом договоров и НПА. Плюсом есть среди знакомых профессиональные юристы по различным отраслям гражданского права, к которым можно будет обратиться за экспертизой.
У меня все намного проще получилось. Исключительно чтобы закрыть конкретную задачу, без дополнительного функционала, который есть у перечисленных вами решений.
Нигде не смог найти системные требования для развертывания модели: сколько надо минимально/средне/максимально мощностей (ядер, памяти, места на диске), чтобы решение накатить и использовать?
В статье указано ПО для взаимодействия с Реестром - Виртуальный регистратор. Но, правильно ли я понимаю, что аналогом этого ПО может стать DNSManager от ISPSystem?
Ну так у меня и прописан вариант для русской версии установки. Я не заявлял нигде, что этот код будет работать на всех локализациях Linux. Вы читайте внимательно — в первую очередь я делал это для себя. У меня русская версия Archlinux, Windows в виртуалке. На основании этого и делал. Зачем в таком случае требовать универсальности? Если её изначально не заявлено на данный момент.
Это не попытка указать на ошибки, а попытка умничать. В этом случае человек пытается выдать свой опыт за то, что делают другие. Чего делать не стоит. Обратите внимание на нормальные указания на ошибки и мою реакцию — увидите разницу. Я с радостью воспринимаю и принимаю критику, но только если это критика, а не выпендреж.
вы полагаете, что только я после установки системы оставляю папку с загрузками там, где она стоит по-умолчанию? :) а все иные пользователи сразу же начинают её перемещать в другие места? говоря многие вы оперируете достаточно размытыми понятиями. например, число пользователей Office 365 (а следовательно пользователей Windows) достигло 135 млн человек. вы можете назвать какой процент из этих людей переносит папку загрузок после установки системы?
🤷♂️
Здесь не про факт обертки, а про те задачи, которая она решает
Есть такой риск :)
Начинаешь с «просто закинуть документ в нейронку», потом добавляешь историю разборов, пользователей, платежи, уведомления, админку, аналитику — и в какой-то момент обнаруживаешь, что незаметно написал CRM.
Поэтому тут для меня как раз важно вовремя остановиться и не превращать узкий сервис с одной понятной функцией в комбайн «для всего».
Вот тут вообще не спорю. Более того, для меня это, пожалуй, самая интересная часть всего эксперимента.
Код я так или иначе напишу. А вот найти людей, которым продукт действительно нужен, объяснить им его ценность, довести до первой оплаты, понять стоимость привлечения и потом добиться повторных покупок - совсем другая задача.
Поэтому и решил писать о проекте ещё в процессе разработки, а не сначала несколько месяцев делать продукт в вакууме, а потом внезапно обнаружить, что продавать его некому.
Так что в моём случае эксперимент скорее не «смогу ли я навайбкодить SaaS», а «смогу ли я его кому-нибудь продать». :)
А вот вам, судя по описанию, моя надстройка действительно может быть не нужна :)
Вы уже знаете, что документ можно отдать нейросети, знаете, что у неё спросить, умеете оценить полученный ответ и при необходимости задать дополнительные вопросы. Если такой сценарий полностью закрывает вашу задачу - платить отдельному сервису просто незачем.
Но я исхожу из того, что не все пользователи нейросетей работают с ними так же. Для кого-то задача выглядит не как «загрузить документ в ChatGPT, попросить проверить риски, потом уточнить спорные моменты и перепроверить ссылки на нормы», а просто как «мне дали договор, я ничего в нём не понимаю — скажите человеческим языком, что здесь написано и где меня могут подловить».
Вот этот сценарий я и пытаюсь упаковать в отдельный продукт: отправил документ - получил разбор по заранее определённой логике без необходимости самому вести диалог с универсальной нейросетью.
А насчёт ссылок на статьи - здесь я бы как раз был осторожен. LLM действительно умеют довольно убедительно работать с законодательством, но «убедительно» не всегда означает «актуально и точно». Поэтому одна из вещей, которые я рассматриваю для развития сервиса, - проверка выводов по собственной актуализируемой нормативной базе, а не просто надежда на знания модели.
Ну и главный вопрос остаётся прежним: достаточно ли людей, которым такой специализированный сценарий удобнее обычного ChatGPT и которые готовы за это платить. Это я как раз и хочу проверить, а не принимать как данность.
С большей частью, кстати, согласен. Особенно с тем, что «сделаю SaaS за 1000 ₽, найду 1000 человек и получу миллион» - это не бизнес-модель, а арифметика :)
Но я как раз не хочу идти по сценарию «полгода пилим идеальную архитектуру, потом впервые спрашиваем, нужно ли это кому-нибудь».
Поэтому и пишу о проекте публично ещё на этапе разработки. Комментарии в духе «а зачем это, если я могу закинуть документ в обычную нейросеть?» для меня сейчас полезнее ещё одной недели разработки. Они довольно быстро проверяют, насколько вообще внятно я могу ответить на вопрос, за что здесь должен платить пользователь.
С экономикой та же история. Здесь не будет классической подписки «1000 ₽ в месяц» просто потому, что для обычного человека юридические документы - не ежедневная потребность. Поэтому модель изначально строю вокруг разовых разборов и пакетов: заплатил тогда, когда понадобилось. Дальше уже надо считать стоимость привлечения, стоимость самого разбора, конверсию в оплату и повторные покупки. Если цифры не сходятся - значит, продукт не сходится, сколько бы кода в нём ни было.
Правовую часть тоже откладывать «на потом» не собираюсь. Здесь документы пользователей, потенциально персональные данные, платежи — соответственно, до публичного запуска должны быть нормально оформлены обработка данных, пользовательские условия и сама схема приёма платежей.
А вот с «очередная обёртка над ChatGPT API никому не нужна» я бы не был настолько категоричен. Огромное количество продуктов - это в той или иной степени удобная упаковка существующей технологии под конкретный сценарий. Вопрос не в наличии обёртки как таковой, а в том, даёт ли она пользователю достаточно дополнительной ценности, чтобы он был готов за неё платить.
Собственно, это и хочу проверить. Не получится найти аудиторию, сформулировать отличие и свести экономику - значит, закрою проект. Тоже вполне полезный результат.
Да, это действительно один из главных минусов отдельных SaaS.
Никому не хочется иметь 30 сервисов: один для договора, второй для резюме, третий для картинок, четвёртый ещё для чего-нибудь.
Поэтому отдельный сервис имеет смысл только тогда, когда он убирает достаточно действий по сравнению с универсальным инструментом.
В моём случае я как раз поэтому выбрал Telegram, а не стал делать ещё один сайт с регистрацией, личным кабинетом и отдельным приложением. Бот уже находится там, где пользователь и так общается: отправил ему документ - получил разбор.
А дальше вопрос исключительно продуктовый: достаточно ли удобнее такой сценарий, чтобы люди им пользовались. Это и хочу проверить.
Но все равно спасибо за этот комментарий. Замечание действительно важное.
Это есть да, как на уровне бота, так и его промптов.
Непосредственно над сервисом работаю один. Пока что помогает опыт преподавания и репетиторства, связанный в том числе, с анализом договоров и НПА. Плюсом есть среди знакомых профессиональные юристы по различным отраслям гражданского права, к которым можно будет обратиться за экспертизой.
У меня все намного проще получилось. Исключительно чтобы закрыть конкретную задачу, без дополнительного функционала, который есть у перечисленных вами решений.
Нигде не смог найти системные требования для развертывания модели: сколько надо минимально/средне/максимально мощностей (ядер, памяти, места на диске), чтобы решение накатить и использовать?
В статье указано ПО для взаимодействия с Реестром - Виртуальный регистратор. Но, правильно ли я понимаю, что аналогом этого ПО может стать DNSManager от ISPSystem?
Спасибо автору за перепечатанную с Arch Wiki инструкцию (нет)
Ну так у меня и прописан вариант для русской версии установки. Я не заявлял нигде, что этот код будет работать на всех локализациях Linux. Вы читайте внимательно — в первую очередь я делал это для себя. У меня русская версия Archlinux, Windows в виртуалке. На основании этого и делал. Зачем в таком случае требовать универсальности? Если её изначально не заявлено на данный момент.
У меня Archlinux, потому я ориентировался в первую очередь на Linux-based дистрибутивы.
Это не попытка указать на ошибки, а попытка умничать. В этом случае человек пытается выдать свой опыт за то, что делают другие. Чего делать не стоит. Обратите внимание на нормальные указания на ошибки и мою реакцию — увидите разницу. Я с радостью воспринимаю и принимаю критику, но только если это критика, а не выпендреж.