Comments 34
Как будто бы нету самого главного - анализа, почему не полетело.
Для этого дисклеймер, что это техническая статья. А не полетело оно по бизнесовым причинам.
Но если вкратце, оказалось, что этот проект не очень хорошо ложится в концепцию венчурных инвестиций. Даже при занятии 100% рынка миллионов пользователей и миллиардных капитализаций бы не было, а значит, это не венчур. Поэтому в какой-то момент мы потеряли возможность привлекать новые инвестиции, а карманных денег на захват рынка нам не хватило.
Если прочитаете мою статью с похожим приложением, то монетизация тут только если продаться потом конторе по сбыту штанг или аренды спорт залов. И желательно перед этим 10 лет пропаганды от правительства.
Не думали продать свои наработки какой-нибудь крупной сети фитнес-клубов?
Иностранные блогеры пользуются каким-то подобным приложением(видела у двоих на ютьюбе). Думаю, что сама идея приложения не очень актуальная и удобная, это этакое youdo или фриланс биржи, а фитнес программы это долгосрок и личные оффлайн действия(в онлайне это получается только для люксового сегмента)
Вот, как будто бы, да, блоггеры это хорошая тема для пивота.
Есть относительно раскрутившиеся в соцсетях фитнес-тренеры, которые хотят как-то масштабировать себя. И видят выход в том, чтобы однажды создать свое фитнес приложение, и раскрутить его своим личным брендом (нагнать бесплатный траф со своих соцсетей). Понятно, что с их пониманием, как делать ИТ проекты это часто несбыточная мечта.
Выглядит так, что, если делать не маркетплейс, где как клиентская, так и тренерская базы - собственность владельца приложения, а нечто вроде конструктора личных приложений одного тренера, с помощью которого он автоматизирует взаимодействие с его имеющимися клиентами, и, принципиально важно, не видит риска потерять этих клиентов в пользу другого тренера на платформе, то может взлететь.
Условно, требовать на онбординге реферальный код, и, в зависимости от него, пускать в личный воркспейс тренера, и показывать только одного тренера. Если атлет хочет тренироваться у N тренеров сразу, ок, логинишься в N разных воркспейсов, и переключаешься между ними, как между аккаунтами электронной почты в апке Gmail, или аккаунтами в ТГ.
Примерно, как slack, где скачиваешь мессенджер, который установлен у миллионов людей, но общаться можешь только с коллегами. Или, как yclients, через который записываешься в барбершоп, но который при этом не пытается стать маркетплейсом барбершопов.
Кажется, onlyfans похожую позицию тоже занял. У них позиционирование примерно такое "мы платформа для монетизации популярности, а не ее получения. Если ты модель, то приходи со своими дро***ми, и мы поможем их доить"
Мне очень интересно про составляющую инвестиций!)
Потому что никому не нужно. Типичный пожиратель времени под видом "удобного сервиса". Жили, пока инвестор за красивую разработку денег давал. Но клиент платить не стал, и всё кончилось.
С точки зрения разработчика, всё отлично. Писал, зарплата шла, движухи, митапы, созвоны, идеи, "мы там на гитхабе, мы там кубернетисах". Когда инвестор расчухал, что гитхабы и куберенетисы денег ему не приносят, платить перестал. Всё просто
"я рекомендую каждому при возможности попробовать сделать что-то своё. Причём не как пет-проект в одиночку, а именно как бизнес " - да, а чего не поделать-то, если за это кто-то платит, а ты за эти деньги "повышаешь скилы" ну и кушаешь хорошо
Как вы интересно всё разложили. Мне зарплата не шла, я ради опыта делал) И у нас было (и всё ещё остаётся) какое-то (небольшое) количество платящих пользователей, которые всем довольны, так что «никому не нужно» это смелое обобщение. В США вроде даже успешный конкурент с такой же моделью нашёлся.
Хорошо, лично вы работали бесплатно, получали скилы и удовольствие от работы, и глаза горели, и вот это всё... Но вот инвестор ваш получил убытки. Он заплатил за ваши горящие глаза. "Какое-то небольшое количество платящих пользователей" - сколько стоил вашему инвестору каждый такой пользователь? Вы пытались сделать узкоспециализированную соцсеть с монетизацией, и у вас предсказуемо не получилось. Технически, наверное, все выглядело офигенно, красивые модные слова, вероятно, красочные графики-презентации, вот это вот всё. Фактически, вот эти все реферральные коды, онбоардинги, все вот эти красивые слова - это всё лишь усложняет жизнь, а не облегчает. Классический изначально плохой UX. По факту, ненужная прокладка. Есть большие соцсети, в них есть вполне себе группы, объединения, паблики - вот это вот всё. И там есть вот эти все тренеры и прочие. Крупным-популярным тренерам вы неинтересны, мелкие слишком, занимающимся вы тоже не особо нужны - мелкие слишком. Денег вам платить за то, что вы сведете тренеров и занимающихся? А нафига? Опять же, есть крупные соцсети, там всего просто овермного, индивидуальные занятия? Это дорого, если брать крупных известных тренеров, а неизвестных или менее известных кругом полно. Да и смысл этих он-лайн занятий? Эго потешить?
Инвестор не платит за горящие глаза, у него своя голова на плечах и гораздо больший опыт оценки перспективности бизнесов, чем у нас.
Я, как пользователь (обычный, не спортсмен и не профиссионал, а просто человек с зарядкой по утрам), хотел бы не в соц.сетях рыться в поисках тренера среди кучи инфоцыган, и не тестировать их, и не рассказывать им, что мне необходимо. А зайти в приложение, заплатив условные 10 баксов за подписку, ответить на пару вопросов бота, посмотрев превью онлайн тренировок с тренером, у которого хорошие отзывы, среди в целом таких же пользователей как я - выбрать себе программу:)
Поэтому сама идея сузить аудиторию и предоставить ей то, что она хочет - хороша, как и модель "Uber" - тоже весьма популярна. Причин почему не взлетело может быть масса (от отсутствия статьи на маркетинг, до не очень качественной реализации). Если инвестировать только в 100% успешные проекты - то никогда бы не случилось прорывов и открытий:)
Спасибо токсичный кэп) На самом деле мой посыл примерно про то и был, что поднимать что-то самому полезно, но если поднимать с точки зрения "мы тут все так круто сделали на кубернетесах", то не очень, потому как пользователям и клиентам это все не оч интересно, и пользы от такого креатива - разве что самому техскилуху прокачать.
Это полезный опыт. Без ошибок рост невозможен. Если конечно делать из них правильные выводы.
Когда говорят про какой-то успешный стартап, мне всегда интересно - а сколько неудачных попыток было до этого?
Ну и создание именно целого продукта - формирует особый, целостный тип мышления.
Насчет монетизации. Возможно, на первый взгляд, незначительное изменение схемы монетизации и сценария использования - кардинально поменяет перспективы прибыли и еще много чего другого.
Тоже сейчас занимаюсь фулл-стек разработкой своего проекта, 2 предыдущих попытки были неудачные, вторая (я о ней сделал публикацию) - вообще дурацкая, но и она даром не прошла - добавила понимания какие технические решения являются удачными, а какие нет, а главное - какие маркетинговые схемы вообще не имеют шансов на взлет.
Пост какого хвастовства, где 90% - вот смотрите какой я молодец, а 10% - "могло быть и лучше".
Я бы озаглавил пост: "Мне было лень разбираться в нейминге переменных и базах данных...".
Ожидал увидеть раздел: "Что пошло не по плану".
Я вижу три технических ошибки.
Первая - это то что изначально не выбралась реляционная БД. Тот же постгрес закрыл бы весь спектр задач, хранение данных(транзакции, join, group и прочие), организация очереди(простые очереди можно держать в базе), машина состояний(enum + constraint), pubsub(для внутренних событий), ну и хранение сырых(или структурированных) данных от Stripe(вместо использования для этого ClickHouse).
Вторая - это кубернетес. Он избыточен для вашего приложения, и для всего добра хватило одной машины в DO или хетснере, и деплой бы был не сильно сложнее (выполнение всех нужных команд на сервере напрямую из GitHub actions или кнопками в jenkins). Да и скриптовые языки прям больно по деньгам запускать в кубе.
Третья - разделение на клиентов и тренеров. В базе была бы одна сущность users, где было бы что-то типа role: athlete|trainer|both (both на случай что какой-то тренер сам у кого-то занимается), и одно приложение, которое бы исходя из role скрывало бы ненужные блоки. Почему вместе, да потому что эти две роли выполняют одну общую задачу. Отдельно приложение надо делать например для владельцев фитнес клубов, так как их роль и задачи в системе никак не пересекаются с athlete и trainer.
Если резюмировать это все, то вы сами себе усложнили жизнь. И просто повезло что не втянули кролика или кафку.
Интересно почитать вторую часть про бизнес составляющую.
Насчёт кубернетиса вы, возможно, правы, но я не соглашусь, что он как-то усложнил мне жизнь. Мне с kubectl легко и удобно. А по деньгам на наших нагрузках там нет принципиальной разницы, было бы $10 вместо $100 — это всё ещё копейки по сравнению с тем же маркетингом.
Насчёт сущностей — я всё ещё считаю, что разделить их было верным решением. У них много непересекающихся данных (у атлетов — анкета, биллинг и всё такое, у тренеров — публичный профиль и условия контракта) и не хотелось бы, чтобы они и там, и там были optional. К тому же, получится, что в коде постоянно фигурирует два разных «юзера» и их очень легко перепутать.
Насчёт приложений. В моём представлении поддерживать два специализированных приложения проще, чем одно универсальное. Кроме того, в текущем варианте мы делали тренерские фичи на более простом React Native, который мог редактировать даже я, а клиентские — на красивых нативных компонентах. Если бы я начинал заново, я бы оставил так же.
Насчёт кубернетиса вы, возможно, правы, но я не соглашусь, что он как-то усложнил мне жизнь. Мне с kubectl легко и удобно. А по деньгам на наших нагрузках там нет принципиальной разницы, было бы $10 вместо $100 — это всё ещё копейки по сравнению с тем же маркетингом.
Да на моей практике разница на порядок, и если 100$ не так драматично как 10$, то 5000$ уже не так приятно как 500$. И мой посыл был в том что куб не решает никакой вашей проблемы, он просто есть и все.
Насчёт сущностей — я всё ещё считаю, что разделить их было верным решением. У них много непересекающихся данных (у атлетов — анкета, биллинг и всё такое, у тренеров — публичный профиль и условия контракта) и не хотелось бы, чтобы они и там, и там были optional. К тому же, получится, что в коде постоянно фигурирует два разных «юзера» и их очень легко перепутать.
В вашей схеме все хорошо до поры до времени, пока тренер сам не захочет заниматься, или использовать какие-то функции доступные только для атлетов (например какой-то контроль веса или что-то типа такого). Анкеты и профили должны быть как у атлета так и у тренера, ну просто потому что им надо как-то сматчиться между собой и эта информация будет полезна обоим (да профиль у тренера открыт, а у атлета закрыт по умолчанию, но у атлета должна быть возможность открыть свой профиль для других). Про биллинг это вообще странно, у тренера как минимум должна быть возможность вывода заработанных денег, ну и депозита для покупки чего-то (платного продвижения, каких-то дополнительных функций и т.д.). Про optional это что-то из nosql мира, в реляционных бд оперируют связями. Попробуйте придумать схему для реляционный бд для своего приложения и увидите что общего намного больше у этих двух ролей и нет смысла их разделять.
Если тренер захочет заниматься, он зайдёт в приложение для атлетов и ему создастся сущность «атлет». Я не понимаю, о какой проблеме вы говорите.
Автоматический вывод средств мы не делали, отправляли расчёты руками (стартап же), но даже если бы сделали, списание раз в месяц и ин-апп кошелёк с выводом средств это две фундаментально разные, практически не пересекающиеся функциональности.
В реляционной БД будет всё то же самое. TrainerProfile, AthleteProfile, оба связаны 1-1 с AuthUser.
Хм, писать фронт в 2025ом на ReactNative и Swift? Проще уж взять один общий Flutter и уменьшить стоимость разработки фронта процентов на 30, еще и сразу получив рынок андроида.
С технической точки зрения наблюдается некоторая избыточность. Все таки прикручивать сторонние механизмы удобно, когда их полезный функционал становится пропорционален такой системе. В остальном проще писать свое. Да, велосипед, но его всегда можно докрутить под текущие нужды.
Пролёт с БД, конечно, весьма существенный. Как уже писали, постгрес решил бы все проблемы. Сам вообще использую firebird для своего проекта.
Нейминги - сам мучаюсь. Так как прогаю на разных языках, порой сам не могу определиться как мне удобнее. Раньше просто подстраивался под проект. Но стараюсь избегать общеупотребимые сущности вроде user.
Тоже пилю свой проект, но в одно лицо. Проект давно в проде и пока не устаканился, т.к. бизнес ищет правильные шаги на ощупь. В коде бардак и анархия, но это мой бардак и моя анархия. Тем более что проект работает и его надо развивать. Как правильно делать знаю и по-тихоньку продумываю архитектуру под рефакторинг. Но зато жутко интересно. В отличие от кручения очередного болтика на галерах большого ИТ. Жена как раз руководитель тестирования на такой галерее. Вроде куча умных людей пилят erp систему, но там по факту все хуже чем у меня с моим бардаком. Потому что никому нет дела до архитектуры и всех процессов в целом. Это печалька.
В коде бардак и анархия, но это мой бардак и моя анархия
ИИ не помогает чуть упорядочить?;)
Я как-то давал файлы с откровенным говнокодом, написанным для тестирования идеи, чату гпт о1 с просьбами отрефакторить, добавить валидаторов входных данных, логгирования. Очень доволен остался. Хотя, понятно, что это в рамках файла, не проекта
Через несколько итераций в этой роли пришел к тому, что в этой фазе проекта любой модуль, написанный по-людски и мало-мальски вылизанный - мощный лок, который затруднит разворот проекта на 180 при необходимости. Так же инфра в посте - оверкилл.
Сам первые проекта три топил за best practices.
Спасибо за крутую статью 🙏
Почему-то к тому времнни как я добрался до своего проекта, я отказался от докера
Тесты чет не написал, ci/cd тоже не прикрутил
Но самый крутой опыт, это перейти на другую сторону. Из найма в свой проект. Тогда сразу становится понятно, что все мои умные фразы, "а давайте развернем лучше это" в найме это одно
И совсем другое в своем проекте, где тяп ляп и в продакшн. Куда важнее просто чтобы работало и приносило деньги
Мой внутренний перфекционист реально страдает от такого, но тут всегда выбираешь баланс между убить кучу времени на мини фичу или сделать чтобы работало и улучшить продукт уже сейчас
Стоило того?
100% стоило, этот опыт сто раз окупится, а получить его в больших компаниях не получится, по указанным причинам.
Супер крутая статья, Тигран, спасибо!
Есть несколько вопросов!
какую проблему решали обзерверы? Чем именно это лучше чем просто консервативные доменные классы с конструктором инклюдящие в себя зависимые классы? Циклов же можно избежать просто правильно выполняя импорты, для небольшой кодобазы это несложно.
Отказываясь от celery, вы изначально понимали, что код воркеров будет мега-простой и надежный? Насколько я знаю, celery не требует maintenance скилла, пару импортов и go brr (как стейт его вроде можно натравить чуть ли не на любую базу, но мб монга исключение). Интересно, как именно принялось это решение
Почему бы тесты не упростить до тупо http запросов? Зачем пляски с pydantic’ом и отедльными wrapper’ами, если можно просто стрелять http запросами (вся инфра для этого уже есть), отправляя то, что хотите проверить, и проверяя что получаете то, что ожидаете?
Коммент не вопрос: очень еще было бы интересно узнать в итоге косты всего этого: сколько стоил k8s, сколько базы, managed ли базы, сколько s3, сколько сеть. Было бы супер полезно для оценки стоимости инфраструктуры похожих небольших проектов.
Энивей, спасибо!
Your feedback is always a gift 💝
В питоне с dependency injection и type hints нельзя. Если объект А зависит от Б, Б — от В, а В — от А, и они в разных модулях, то всё, не получится объявить ни один из классов, не импортнув два других.
Ну и даже если бы можно было, я считаю, что лучше уж обзёрверы, чем порядок импортов, за которым нужно следить... Там в жирных компонентах у меня и по сорок импортов бывало.
Celery не требует maintenance скилла, но RabbitMQ/Redis требуют, а ещё они требуют CPU и памяти в кубернетисе. Кроме того, ещё одна внешняя зависимость — это ещё одна проблема в тестах: надо либо везде мокать и тогда нет уверенности, как оно будет работать с настоящим Celery, или разворачивать Celery и RabbitMQ/Redis на CI.
Ещё в Celery, насколько я помню, не очень хорошая поддержка отложенных тасок (оно все отложенные таски вычитывает из очереди и держит в памяти, пока момент не настанет). Поэтому я подумал, что мне проще сделать свой Aliceq.Так это фактически и есть HTTP-запросы. Но сырой JSON в тестах печатать неудобно, да и рефакторить тоже неудобно.
Косты были минимальные, мы двумя-тремя нодами обходились и маленьким регистри, то есть всё в пределах $100 в месяц. Нагрузки мало, данных мало) MongoDB была поднятая руками на стейтфулсете дёшево и сердито.
А, да, type hint’s действительно работают не оч с циклами, тоже недавно с этим столкнулся. Понятно, спасибо! А можно было в вашем случае избежать циклов полностью? Типа если где-то появляется цикл то выносить это отельно
Эт да, redis/rabbit это может быть проблемой. Но у нас вот как бд был PG и мы её же использовали как базу для celery, полет вроде нормальный. Интересно изменилось ли бы это решение если бы вы выбрали PG изначально
Ну, при большом желании, наверное, можно, но зачем. Так может с точки зрения кода даже хуже получиться, будут гипергранулированные компоненты, из которых что-то собрать это целый квест. Ну и каждая новая зависимость рискует потребовать каскада дальнейших разбиений произвольной глубины.
Если бы у меня изначально был PG, я бы, может, и не женился бы вовсе...
Урок ценой $115 000: чему меня научила разработка продукта с нуля