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

Кстати, забыл рассказать про то, как этот сервис работает для ресторанов. Для клиента понятно: приходит, сканирует 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 (прямой конкурент) остается в основном в Штатах и не заходит в ОАЭ, расскажу в следующих постах. Если вы уже пробовали создать приложение, но вы понимаете, что до рабочего бизнеса это не дотягивает, оставляйте заявку, обсудим проект. ОСТАВИТЬ ЗАЯВКУ

Как мы разбирались с системой каршеринга Обратился заказчик с желанием сделать приложение по аренде премиум авто. Простая логика p2p сервиса, где каждый человек может сдать в аренду машину, чтобы она не пылилась в гараже, а приносила прибыль. Первым техническим препятствием на пути стал дверной замок. Чтобы сервисом пользовались и те, кто сдают машины, и те, кто берут их в аренду, получение автомобиля и передача ключей должны быть в дистанционном формате. Это решает целую кучу проблем и делает сервис реально удобным. Как мы решали это? Сначала мы сразу вспомнили, что у большинства премиальных машин есть свои приложения, в которых уже есть функция разблокировки дверей (My BMW, myAudi, Porsche Connect). Но в документации официальных публичных API, которые позволяют стороннему приложению управлять дверями чужой машины, просто нет. Поэтому пришлось искать дальше. Мы нашли такую штуку как Smart Connect. Это агрегатор, который подключается напрямую к родным API производителей вроде BMW, Audi, Tesla. Владелец логинится через свой родной аккаунт бренда, разово даёт доступ, и дальше можно слать команды на разблокировку дверей. Звучит красиво, но у решения есть жёсткое ограничение. Оно работает только с машинами, у которых есть активная родная система связи и подписка от производителя. Если машина старая, без такого модуля, или бренд вообще не поддерживается, вариант отпадает полностью. В этом случае остаётся только одно: ставить отдельную железку в машину, к которой телефон подключается напрямую и с которой можно открывать и закрывать двери. Поэтому я в Грузии заказал такой "умный замок", взял тачку и два часа провозился, пытаясь разобраться, как эту штуку присобачить в машину. В итоге подключил, всё заработало. Двери открывались и закрывались через телефон. Магия не иначе Так и началась целая эпопея с этим приложением.

Новое видео на канале! (Как внедрить ИИ в бизнес) Разобрал запрос, с которым к нам в студию приходят всё чаще: «как внедрить AI в бизнес?» Сейчас большой спрос в студии идёт на внедрение ИИ. Это большие B2B-сделки, которые окупаются для бизнеса в первый месяц. Поэтому записал видео о том, что это вообще такое, какие варианты есть для встраивания в бизнес-процессы. В видео рассказываю всю базу, чтобы вопросов не оставалось. 📱Смотреть на Youtube

Сколько стоит поддержка приложения в год? ч.3 (человеческая) Тут буду говорить только за себя и про то, как у нас устроена работа со студией. После запуска мы обеспечиваем стабильную работу приложения бесплатно, без абонентской платы. И если вдруг после всех 5 стадий проверки перед публикацией что-то вдруг пошло не так, то мы в течение 3 дней всё поправим. Зачем нам это? Потому что я изначально строил студию не вокруг разовой разработки, а вокруг партнёрства. Идеальная модель для нас — войти в долю от дохода проекта, а не просто получить деньги за код и уйти. Это классический вин-вин подход: заказчик это эксперт в своей нише, знает рынок и умеет привлекать клиентов. Мы закрываем всё техническое и делаем продукт, который реально работает на бизнес.

Когда оба видят ценность друг друга — органично приходим к партнёрству и делим прибыль.

Большая часть нашего заработка идёт именно так — с доли в проектах, которые мы сами же и помогли вырастить. Поэтому бесплатная поддержка, это совместный интерес. Если приложение зарабатывает, хорошо всем)

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

Что там у китайских собратьев творится?🇨🇳 Увидел недавно новость, что Илон Маск (который Space X) и основатель китайской компании Zhipu AI прогнозируют, что Китай сможет создать модель класса Fable от Anthropic (писал про бан этой модели ТУТ) к началу 2027 года. Во-первых, задачка амбициозная и интересно посмотреть сбудутся ли эти обещания. Во-вторых, это заставило меня задуматься о китайских ИИ. Честно говоря, в моей голове когда-то давно сложилось впечатление о китайских нейронках как о слабом собрате Chat-GPT, Gemini, Claude. И так как я о них новостей особо и не слышал, кроме разве что новостей о DeepSeek, то эта позиция так и не менялась. Поэтому решил узнать, как вы относитесь к китайским ИИ и использует кто-то их в работе? Может там уже настало прекрасное светлое будущее и стоит начать приглядываться к ним.