Игнат | Разработка приложений

Почему мы решили делать не просто приложение с тренировками, а полноценную систему с отслеживанием тренировок, питания и восстановления? У меня самого до этого проекта было стандартное представление: чтобы быть накачанным, нужно просто много ходить в зал. От фитнеса я, честно говоря, далек, поэтому узнавал многое заново вместе с заказчиком. Оказалось, что зал это всего лишь 50% успеха или даже меньше, а основную роль играет восстановление и питание. Поэтому и решили не ограничиваться только списком упражнений, и не делать кастрированную версию полезного прилжения. Что это значит на практике? Тренировки, питание и восстановление в приложении не существуют отдельно друг от друга, а работают как единая система. Дело в том, что все эти три метрики связаны напрямую и влияют друг на друга буквально день в день. Съел клиент меньше белка, чем нужно, поспал на два часа меньше нормы, дал телу тяжёлую тренировку без нормального отдыха, каждый из этих факторов по отдельности может ничего не значить, а вот вместе они дают перетренированность, срыв в питании или потерю прогресса. Поэтому важно не просто фиксировать данные, а видеть их в моменте и в связке. Тут важный момент: мы не собираем метрики просто потому что можем. Каждая метрика собирается с конкретной целью — дать тренеру полную картину для принятия решения. Если какие-то данные не влияют на эту картину, особенно в первой итерации, мы их просто не собираем, чтобы не превращать приложение в свалку цифр, в которой никто не разберётся и не раздувать запуск. (в сборе метрик кстати очень помогает интеграция с фитнес-браслетами, расскажу отдельно) Кстати важный момент по юридической безопасности. Если вы запускаете приложение в чувствительных сферах: здоровье, финансы, юриспруденция и т.п. то особенно важно просчитать юридические риски. Так в приложении ИИ помощник не ставит диагнозы и не даёт медицинских предписаний, а только подсвечивает тренеру то, на что стоит обратить внимание. Решение всегда принимает тренер. Это и есть основной смысл продукта — не заменить тренера, а дать ему инструмент, который помогает в работе. Знания и опыт специалиста по-прежнему на первом месте.

Что сейчас делать продавцам на маркетплейсах? Комиссии растут, правила меняются, а теперь ещё к этому добавляются удары по складам. Мне захотелось на пальцах со стороны предпринимательского подхода, показать, что запустить свой независимый интернет-магазин сейчас гораздо проще, быстрее и выгоднее, чем кажется. В этом ролике рассказал всё: от того, как правильно составить ТЗ и обойти костыли старых движков, до секретов, как заставить искусственный интеллект бесплатно рекомендовать ваши товары прямо в поиске 📱Ссылка на YouTube Обещал скинуть примеры ТЗ: https://docs.google.com/document/d/1X0uMiCeOXJvjfaoXdh7mYRr0AafC0cdLyD1zxth4pWI/edit?usp=sharing https://docs.google.com/document/d/1cBcDXIb9x_YZL1_32HpwkwEYvyTTsYSiF-SZkIZA4sk/edit?usp=sharing https://docs.google.com/document/d/1nCBR9zvdrqVp0W_ma7n89Ma1HrpmK2ynZ0ks2hR-wLI/edit?usp=sharing

Про реферальную программу Все хотят её видеть в приложении, все думают, что это волшебная таблетка. Что все пользователи обязательно прочтут все условия и все запомнят. И конечно же при каждом удобном случае будут использовать реферальную ссылку. На деле внимание пользователя сильно ограничено. Рефералку никто целенаправленно искать не будет, никто не будет заморачиваться и помнить, что она лежит в дальнем углу настроек. Заказчики обычно переоценивают то, насколько досконально пользователь изучает продукт, просчитывает выгоды и вот это всё. Это довольно сомнительные ожидания. Так зачем мы вообще это сделали? Всё просто: это приложение будет продвигаться рекламой у блогеров-инфлюенсеров. В Инстаграме огромное количество блогеров, рассказывающих, как правильно накачаться. И их смотрят в том числе частные тренеры без своего блога, которым это будет полезно. Мы делаем рефералку не под расчёт на сарафанное радио — типа "я пользуюсь, рассказал другу Серёге". Мы делаем её под то, чтобы платить блогеру за рекламу плюс давать рефералку, с которой он будет постоянно получать деньги. На каком-то этапе доход блогера с рефералки перекроет наши расходы на рекламу — и тогда мы просто подписываем его на постоянное сотрудничество. Так рекламировалась биржа Bybit. Когда они выходили на рынок, подписали блогеров, которые плотно рассказывали про крипту, дали им рефералки. Блогеры начали в видео говорить: "давай, давай, залетай по моей рефералке, вот Bybit, всё нормально, проверено". Пошла куча людей. Эти блогеры получали процент не разово, а постоянно — с каждой комиссии, с каждой сделки своей аудитории. Причём блогеры, которые рассказывали именно про трейдинг, у которых аудитория целыми днями "дрочит свечки" с огромными оборотами, зарабатывали больше всех: полпроцента с таких оборотов превращались в огромные деньги. Вот по такой же логике мы и потратили ресурсы на разработку рефералки. А не с надеждой на сарафан

Сейчас ИИ не внедрили только в приложение «Фонарик», поэтому в приложении для тренеров нашлось место ИИ-интеграциям. Главный принцип, которого старались придерживаться, — делать ИИ функцией, вспомогательным функционалом, а не завязывать на нём работу приложения. Что сделали? - Умные подсказки для рационов питания. Чтобы составить 1 рацион, тренеру нужно рассчитать калорийность, не забыть про соотношение белков, жиров и углеводов, так ещё и учесть индивидуальные непереносимости, предпочтения и бюджет человека. Такая комплексная задача отлично подошла под ИИ-автоматизацию. Одна эта фишка экономит до 5 часов в неделю тренерам. - Вторым внедрением стали умные подсказки. Когда тренер работает с парочкой человек, легко удержать всё в голове про каждого из них. Но когда их количество переваливает за десяток, то легко можно упустить или забыть что-то. Мы оцифровали опыт десятков тренеров и медицинских экспертов, чтобы система сама подсвечивала параметры, на которые стоит обратить внимание. (Например, если после вчерашней силовой тренировки с увеличением веса у человека утром резкие скачки давления и плохой аппетит, то система сама подскажет, что у человека риск перетренированности и надо снижать нагрузку.) В итоге у тренера освобождаются часы, которые раньше уходили на рутинные расчёты, а внимание переключается туда, где действительно нужен человеческий опыт. И всё это укладывается для заказчика в 20% от цены подписки пользователя. Всё из-за правильной работе с данными и оптимизации работы с ИИ. Про это рассказывал в недавнем видео на канале 📱 Если нужна консультация по внедрению ИИ, то заполните заявку на сайте - ССЫЛКА

Расскажу про один из новых проектов, который мы сейчас разрабатываем (может, и вас наведёт на мысли о своём приложении). Если зайти в любой магазин приложений в раздел фитнес, там будут сотни приложений для спортсменов и тех, кто хочет начать заниматься. И практически ни одного приложения для тренеров. Все разработчики и стартаперы, когда слышат слово «фитнес», надевают туннельные очки и идут делать очередное приложение со списком упражнений для клиентов. А аудитория тренеров не менее перспективная, со своими проблемами, которые мы и решаем в новом проекте. Как обычно тренера ведут своих подопечных? Все данные либо в голове, либо в лучшем случае excel-табличка, либо по старинке тетрадь в клеточку. А если тренеру ещё нужно следить за питанием, то либо на составление рациона уходит куча времени, либо все ученики получают плюс-минус одну и ту же диету с минорными изменениями, просто потому что разрабатывать индивидуальный план под каждого физически некогда. В итоге всё это менее эффективно сразу по двум причинам. Во-первых, огромное количество времени уходит на рутину вместо реальной работы с человеком. Во-вторых, тренеру физически сложно уследить больше чем за 5 учениками одновременно, а значит и расти в доходе тяжело. Чтобы решить эти проблемы, мы сделали: -Умную и, главное, удобную CRM систему, где тренер отслеживает не банальное «сколько кг пожал», а получает полную картину: тренировки, питание, восстановление. Всё в одном месте, а не разбросано по головам, табличкам и мессенджерам. -ИИ помощника с важной особенностью: он работает не по общим шаблонам из интернета, а по конкретной базе знаний самого тренера. То есть советы ученикам строятся на его собственной методике, а не на усреднённых рекомендациях. -Большую базу проверенных упражнений и рационов, которую собирали не абы как, а вручную вместе с практикующим тренером, который лично проверял каждую позицию. Это экономит тренеру до 2 часов в день на рутинных задачах. -Систему индексов, по которой можно за секунды понять, что происходит с учеником: как он тренируется, ест и восстанавливается, а не гадать по отрывочным данным. -И геймификацию с максимально простым интерфейсом для подопечных, чтобы им самим было интересно вести дневник и не хотелось всё бросить через неделю. Это если вкратце что планируем осуществить, чуть подробнее про все нюансы и интересные особенности проекта расскажу в скором времени.

🔥 Как выбрать подрядчика и не пожалеть? Новый ролик уже на канале! Каждый месяц встречаюсь с тем, что заказчики рассказывают истории, как выбрали не того подрядчика. Как всё было плохо со сроками и итоговый продукт получился не такой. А с другой стороны, вижу сотни студий и фрилансеров, которые искренне не понимают, почему адекватные клиенты с бюджетами обходят их стороной. В новом видео разобрал эту проблему с двух сторон, на основе личного опыта управления студией: - Как мы строим процессы внутри: показал изнанку нашей работы и правила, по которым мы работаем с заказчиками. - Ошибка мышления подрядчиков: почему красивые презентации не работают и за что заказчики на самом деле готовы платить. - Критерии отбора: по каким маркерам адекватный клиент за секунду отличает сильную команду от раздолбаев. 👉 Смотреть на YouTube

Ищу... дизайнера! Вы работаете на фрилансе или думаете о собственной студии? – круто, возможно нам стоит пообщаться!) В чем суть? – у нас все больше проектов и все больше работы. Нужно делать дизайн в Figma для мобильных приложений, сайтов и прочей ITшки. ВАЖНО! Про Claude Design я прекрасно знаю и ищу человека со своей головой, с видением, со стилем... способного на креатив (в общем с теми качествами, которых у ИИ нет). Работать нужно будет 1-на-1 с предпринимателями и собственниками бизнеса, поэтому ищу людей с предпринимательским майндсетом (как раз фрилансеров, которые уже работают на себя, уже продвигают свои услуги, уже ведут переговоры с клиентами). То есть это не "штат", где можно сесть на оклад, получить ДМС и тд. ЭТО СВОЙ БИЗНЕС. Если это про вас, то заполните форму и выполните тестовое задание: https://docs.google.com/forms/d/e/1FAIpQLSfpnFJ3Pd-dyYCS83sGe3uAaZj61pRLmlW7YDczGLswQ-xmEQ/viewform В поле "ссылка на резюме" напишите "С КАНАЛА" P.S. Конечно всем всегда интересен уровень оплаты. Скажу так – все зависит от проекта и от уровня ваших скиллов, но если человек способен закрывать под ключ задачи, то на оплату мы никогда не скупились. Как пример – отзывы выпускников с курса по FlutterFlow, которые получали солидные чеки сразу после обучения: https://appbusters.io/reviews/flutterflow_course

Кстати, забыл рассказать про то, как этот сервис работает для ресторанов. Для клиента понятно: приходит, сканирует QR-код и платит. А вот как подключаются рестораны? А подключаются они либо через свои ключи доступа у RMS (iiko, r_keeper), либо ведут учет в ручном режиме. То есть там они видят, сколько денег прошло через сервис, сколько сэкономлено и какой средний чек. В общем, всю статистику по ресторану (на анимации). И в ручном режиме плюсом мы дублируем всё, что есть на стороне RMS. То есть конструктор блюд, скидок и сбор меню. А что будет, если человек сначала был, например, на iiko, а потом плюнул на всё и отказался от них? Начал вести сам всю статистику. А через месяц вообще решил пойти к r_keeper. И как это всё решить с точки зрения базы данных? Мы храним не одну общую БД, а сразу три отдельных: под RKeeper, под iiko и под ручное управление. Получается 3 отдельные базы данных со своими форматами. Отдельная головная боль это заказы и статистика. Они у ресторана сквозные и не должны обнуляться при смене РМС-ки. Комиссии, выручка, средний чек, экономия все эти цифры считаются и хранятся уже не в привязке к конкретной РМС, а на нашей стороне, в единой таблице, которая собирает данные независимо от того, через какую систему в данный момент ведётся меню. В итоге снаружи всё выглядит максимально скромно: обычное приложение с кнопками и табличками, ничего впечатляющего на демонстрации. Но за этим стоит три параллельные таблицы товаров под разные форматы данных плюс отдельный слой сквозной аналитики, который их все объединяет и не даёт истории заказов посыпаться при каждом переключении.

Последняя крупная интеграция в этом проекте — АТОЛ (облачные кассы). В чём суть? Когда человек оплатил свои, не знаю, там пельмени за 1000 рублей, они поступили к нам на счёт. Из них мы должны вычесть свои пару процентов, а остальные 950 рублей вернуть обратно ресторану. Получается как в том меме: прибыль не знаю, но обороты бешеные. И вот чтобы не платить налоги с 1000 рублей, которые прошли через сервис, а только с 50 рублей, которые мы реально получили, пришлось глубоко погружаться в налоговое законодательство и в 54-ФЗ. Также общались с ФНС, чтобы понять, что должно быть указано в чеке и что это должен быть за чек. Сейчас: Благодаря интеграции с выпиской этих онлайн-чеков и правильной отправкой их в бухгалтерию налоговой базой будут считаться эти 50 рублей, а не 1000 за пельмени и все чеки выбиваются правильно. Всё-таки к разработке приложения важно ещё подходить не только как к коду и функциям, но ещё и как к целому бизнесу. Помимо того что оно в целом должно работать, приходится решать ещё гору попутных задач, чтобы это было и удобно, и экономически эффективно, и со стороны налогов и законодательства всё было корректно (в последнее время этих изменений становится всё больше). Если подводить итоги, то получился с виду простой такой сервис, но с кучей интеграций. Это и банальные Яндекс.Карты, чтобы выбирать адрес на карте, интеграция с RMS iiko и r_keeper, интеграция с сервисом для чаевых CloudTips и АТОЛ для выписки чеков и соблюдения требований ФНС.

Почему "просто перевести чаевые официанту" - это не просто перевод На первый взгляд задача оставить чаевые кажется очень простой. Просто перевести деньги человеку. Но когда начинаешь глубже задумываться "а как это сделать?", появляется целый ряд вопросов. - Как переводить деньги. Обычным переводом? Через эквайринг ресторана? Напрямую человеку? - А юридически кто эти официанты? Штатные сотрудники, самозанятые или просто физлица? Налоги соответственно у каждого свои - Куда зачислять деньги. Нужен ли официанту личный кабинет или кидать ему прямо на карту? - Как гость выбирает именно своего официанта. Список имён после заказа, привязка к столу, QR-код? И каждый из этих вопросов тянет за собой огромный пласт логики и работы. Мы не стали изобретать велосипед и нашли уже готовый сервис, заточенный именно для решения этого вопроса. Он называется CloudTips и берёт на себя регистрацию официантов, распределение и выплаты. Цена решения: ещё один API, ещё одна техническая интеграция, ещё одна команда, с которой нужно договориться и синхронизировать процессы. Но это в разы дешевле и надёжнее, чем строить свою систему выплат физлицам. Для таких ситуаций как раз нужна профессиональная команда разработчиков. То есть да, сейчас любой может пойти к ИИ и сказать: "а сделай вот такое приложение". И там даже, наверное, будут кликаться кнопки, но настроить взаимодействие API, работать с техническими командами площадок и ещё сэкономить и в бюджет вписаться может только подкованный специалист. И если вам нужны именно технические партнёры, то готовы связаться и обсудить ваш проект - ЗАПИСАТЬСЯ НА РАЗБОР

Что было самое трудоемким в этом проекте? Мы хотели охватить все рестораны, а у них разные учетные системы: кто-то на iiko, кто-то на r_keeper, кто-то на чём-то ещё. Полностью перевести всех на свое решение нереально, никто на это не пойдет. Значит, единственный путь это разрабатывать свой продукт и интегрироваться с каждой из этих систем отдельно. Казалось бы, план простой: пишешь запрос в iiko или r_keeper, получаешь доступ к API и программируешь. Но на деле эти системы как закрытый банк. Никто не даст доступ к данным ресторанов первому встречному. Сначала нужно пройти официальный аудит у создателей системы. Мы собирали целый пакет документов: договор с клиентом, архитектуру нашего приложения, портфолио студии. Так компания проверяет, что мы не просто люди с улицы. После прохождения аудита выделяется команда, с которой вы вместе разрабатываете решение. И не всегда это гладко. Обычно это мидл+ разработчики на ставке в своей компании: доделывать что-то сверх плана им не особо хочется, а KPI по срокам у них нет, поэтому им не горит. Из-за этого сроки и бюджет разработки часто уезжают со стороны студии. Если существующего API не хватает, приходится либо городить промежуточное решение на своей стороне, либо просить команду поддержки добавить нужные параметры в API. Это общение на уровне «технарь с технарем», поэтому доверять такие интеграции фрилансерам рискованно. Советы, если решите делать приложение с интеграциями к сторонним сервисам: 1. На вашей стороне нужны действительно компетентные специалисты. 2. Сроки могут поехать из-за согласований, так что команде нужны навыки переговоров, чтобы не увязнуть в них. 3. Пропишите в договоре, кто отвечает за сроки и что будет при задержках не по вашей вине.

В новом видео рассказал как создать свою CRM систему с нуля и сделать её идеальным инструментом конкретно под ваш бизнес. Разберем все плюсы и минусы разработки кастомной CRM, чтобы вы могли понять: стоит ли переплачивать за готовые подписки (вроде Битрикс или AmoCRM) или пришло время сделать CRM систему 📱смотреть YouTube

Новый кейс для общепита Задача была простая: упростить и оцифровать заказ в ресторане. Как это выглядит сейчас? Бумажное меню уже почти везде уступило место QR коду на столике. Сканируешь, листаешь, выбираешь блюдо. За этим обычно стоит готовая платформа CMS (Content Management System), а не самописный лендинг у каждого ресторана. Вопрос риторический : часто ли это цифровое меню было удобным? (Речь не про крупные сети типа Dodo Pizza или McDonald's, а про обычные заведения.) Обычно там нет части фотографий, заказать блюдо из самого меню нельзя, оплатить тем более. Меню просто заменило бумажку на планшет, а дальше всё как раньше: ждёшь официанта, ждёшь заказ, ждёшь счёт. Те же яйца, только в профиль. Мы решили закрыть этои проблемы. Сделали приложение, где цифровое меню это не просто витрина, а полноценный интерфейс: отправляешь заказ прямо на кухню и оплачиваешь его, не отвлекая официанта. Для меня как для человека, который вечно путешествует и часто не знает языка официанта, возможность поесть без единого слова, только жестами через экран, это просто находка. Что в итоге сделали: • перевод меню на нужный язык • красивый и удобный интерфейс • заказ и оплата прямо из приложения • конструктор блюд • чаевые в один тап

Что такое RMS? Вообще расшифровывается как Restaurant Management System. Это готовое решение для автоматизации работы ресторанов. Можно сказать, что это CRM-системы, только заточенные именно под рестораны и общепит. Что для ресторана важно? Понимать, с какого столика пришел заказ, чтобы он автоматически падал на кухню, и чтобы можно было легко контролировать остатки на кухне. Эти задачи и закрывают эти автоматизированные системы. Чтобы можно было увидеть всё предприятие как большой оцифрованный кусок. В России данный рынок в основном делят два крупных конкурента: r_keeper и iiko. Работают они уже не первый десяток лет, и само собой подвинуть их с этого пьедестала задачи я не ставлю. Но в дальнейших постах расскажу немного о нашем кейсе и о том, как нам пришлось взаимодействовать с этими большими RMS платформами, интегрироваться с ними. Да и в целом расскажу, как проходит процесс, когда приложение нужно разрабатывать не в вакууме, а во взаимодействии с другими сторонними сервисами.

Как мы проверяем арендаторов и оформляем страховку Главный вопрос в аренде премиум-авто: как убедиться, что машину берёт реальный человек с настоящими правами, и как быстро оформить на него страховку? Тут мы не стали изобретать велосипед, поэтому как и в большинстве проектов использовали готовый сервис проверки документов sdk sumsub. Работает просто: 1. Пользователь снимает себя на камеру (просят покрутить головой, чтобы понять, что это живой человек, а не фото) 2. Загружает паспорт и водительские права 3. Сервис за пару минут проверяет, что документы настоящие и не поддельные Дальше эти данные автоматически уходят в страховую, и оформляется страховка. Никто вручную ничего не проверяет. Плюсы: -Не нужна команда людей, которая сидит и проверяет документы руками -Проверка занимает пару минут вместо дней -Сервис работает с документами почти из любой страны -И важный момент: мы сами не храним документы пользователей. Просто помним, когда у человека истекают права или паспорт, и вовремя просим обновить. В итоге человек один раз проходит проверку при регистрации, а дальше просто открывает машину со смарт-замка. Без бумаг и разговоров с менеджером. Такая проверка называется KYC - know your customer и уже стандарт для любых приложений с финансовыми отношениями

На примере этого приложения также хочется рассказать про кластеризацию объектов на карте. (показал в гифке) Частая задача в мобильных приложениях с картой (доставка, аренда, объекты недвижимости) — сгруппировать точки в кластеры, которые распадаются при приближении. Вариант 1: клиентская кластеризация Для этого вида есть готовые пакеты и делается это не сложно. Логика простая: приложение запрашивает данные по всем объектам сразу, они оседают в оперативной памяти телефона, и там же на клиенте происходит кластеризация. Работает нормально, если объектов мало. Но представим приложение вроде Wildberries с картой пунктов выдачи, где точек 10 тысяч. Скачивать и держать в памяти телефона весь массив, а потом на устройстве его группировать это уже перебор. Порог, после которого так делать не стоит, примерно 1000 объектов. Вариант 2: кластеризация на бэкенде Тут всё устроено сложнее: фронт отправляет не запрос "дай все объекты", а координаты видимой области карты. Бэкенд ищет в базе только объекты в этих границах и кластеризует их через расширение для PostgreSQL прямо на уровне SQL-запроса. На фронт возвращается уже готовый компактный массив: координата центра каждого кластера и число объектов в нём. При зуме или скролле карты уходит новый подзапрос с обновлёнными координатами области, и бэкенд возвращает новый массив кластеров. Гибридный подход На практике самый рабочий вариант. Пока пользователь смотрит на карту издалека и объектов в области много, кластеризация считается на бэкенде, чтобы не гонять тяжёлые данные на клиент. Как только при приближении количество объектов в видимой области падает ниже порога (например, 500), происходит переключение на клиентскую кластеризацию: дальше это чисто фронтовая работа с уже небольшим массивом, что быстрее и приятнее для пользователя. Итог: маленькое приложение с сотней меток на карте можно спокойно кластеризовать на клиенте. Как только счёт идёт на тысячи, нужен бэкенд или гибридная схема с переключением по порогу.

Вот кстати дизайн проекта по аренде машин. И немного мыслей про дизайн приложений. Этот дизайн мы сделали в Figma. И да мы тоже пользуемся Клод Дизайн, ускоряет работу. Но когда делаешь коммерческий сервис, где будут реальные люди и реальные деньги, недостаточно набросать пару экранов концепта и надеяться, что остальное как-то само довайбкодится. (иногда с таким пониманием к нам приходят устраиваться разработчики) Но в больших проектах нужно проработать все статусы, все цепочки действий, все сообщения об ошибках. Кажется мелочью: правильный пароль, неправильный, уже зарегистрирован. Но именно эти мелочи формируют пользовательский опыт. Если где-то есть непонятная ошибка или недодуманное поведение, это трение убивает даже самую крутую идею. Человек несколько раз споткнется на регистрации и просто уйдет. Именно эта ручная, методичная проработка отличает коммерческий продукт от самостоятельной поделки уровня MVP. Сейчас вижу много людей, которые все делегировали своей ИИшке и просто ждут чуда. Складывается такое ощущение, что если появятся физические роботы, эти люди вообще с дивана вставать перестанут. Работать нужно руками и головой, инструменты это ускорение, а не замена.

Немного пояснения почему именно ОАЭ и такая идея Заказчик сам уже 10 лет живет и работает в ОАЭ. У него свой сервис по прокату премиальных авто: Ламбы, Феррари, все то, с чем любят фотографироваться для запретграмма. Заказчик за годы работы в офлайн-прокате накопил серьезную экспертизу рынка: какие машины реально сдаются, как их продвигать, какие ограничения и особенности есть именно в ОАЭ. Вместо того, чтобы открыть еще одну точку проката, конкурируя с десятками таких же, он решил зайти шире и превратить эти знания в приложение. Так экспертиза масштабируется не на одну контору, а на весь рынок P2P-аренды. Аналог такой модели, P2P-аренда авто без посредников, уже существует и давно популярен в США и Канаде. Это приложение Turo. При этом на рынок ОАЭ Turo не заходит. Потому что выходить на новый рынок сложно: свои законы, свои ограничения, нужны локальные данные и юрлицо. Крупные западные компании просто не связываются с такой головной болью ради одного региона. Модель уже доказала себя на другом рынке, спрос и механика понятны. Что ещё нужно для счастья ? Эту мысль я часто продвигаю в канале: если где-то что-то классно работает, это не значит, что вы опоздали. Посмотрите, зашло ли это на ваш локальный рынок. Часто крупные игроки просто не суются в регионы с местной спецификой, и это открывает окно для тех, кто готов разобраться в деталях и сделать это первым.

Подготовил новый ролик с лайфхаками для вайбкодеров Собрал в одном видео лучшие советы от 50 вайбкодеров: как экономить токены, обходить лимиты нейросетей, правильно работать с контекстным окном и какие инструменты реально ускоряют разработку с ИИ. 📱Смотреть на YouTube

К чему был предыдущий пост? У нас новый кейс, о котором хочется рассказать подробнее. Сделали аналог Airbnb, но для аренды машин. Хотелось создать такую же отработанную схему аренды, как у Airbnb. Сдаешь хату, приезжают жильцы, замки открываются автоматически, или кто-то вешает сейф снаружи с кодом, потом приходит уборщик, и квартира снова готова к аренде. Мы сделали то же самое, но для рынка аренды автомобилей в Дубае. Вообще рынок арендных машин очень развит, что подтверждается наличием подобных аналогов приложений в других странах. И есть даже люди, которые покупают отдельно инвестиционные машины и сдают под 30% годовых в прокатные конторы. Или просто, когда у семьи есть 2 или 3 машины, то зачем машине пылиться в гараже. Что было интересного? Замки (писал выше). Часть замков подключали через онлайн-интеграцию по API, часть через устройство, которое пришлось заказывать с Алиэкспресса и тестировать руками. Штрафы. Приложение автоматически подтягивает данные из местной службы и вычитает сумму штрафа с баланса пользователя. Баланс может уйти в минус, если денег не хватило, это нормально, потом просто пополняешь. Страховка. Кто отвечает за машину, если что-то случилось в такой P2P аренде, — это вообще главный вопрос всей модели. Автоматизировали и это. На первый взгляд все просто: нажал кнопку, нашел машину на карте, забронировал. Такое сейчас любой соберет с нейронкой на коленке за вечер. Но бизнес на этом не заканчивается. Бизнес — это регуляторка, это железо, это интеграции, это погружение в то, как устроен рынок именно в этой стране. Кстати, почему тот же Turo (прямой конкурент) остается в основном в Штатах и не заходит в ОАЭ, расскажу в следующих постах. Если вы уже пробовали создать приложение, но вы понимаете, что до рабочего бизнеса это не дотягивает, оставляйте заявку, обсудим проект. ОСТАВИТЬ ЗАЯВКУ