«Американцам заходят борщик и сырники» — интервью с CTO Foodtech-стартапа из Чикаго

Запуск американского Foodtech-стартапа, выбор между Flutter, React Native, KMP и доставка еды на велосипедах силами топ-менеджмента. Рассказываю, как прошел путь от Андроид-разработчика из России до CTO компании Sizl.

Привет! Меня зовут Максим, я управляющий партнёр в KTS.

Недавно я попросил бывшего коллегу Сеню Суздальницкого, CTO Sizl, стартапа доставки еды в Чикаго, поделиться своей историей. Получилось большое интервью, в котором мы поговорили о:

Я приехал в Москву после учебы в Красноярске. Сначала работал в «Айтеко» и параллельно учил Android. Однажды прошёл интенсивный курс по Kotlin и понял, как много он привносит в андроидную жизнь.

Вскоре приятель позвал меня в KTS на должность Android-разработчика. Там я занимался приложением для строительной компании ПИК и несколькими другими проектами поменьше.

Следующим местом работы был «Рокетбанк» — стартап, основатели которого потом сделали «Кухню на районе». Когда я начал там работать, «Рокет» уже выкупили QIWI. Несмотря на это сохранился молодёжный неформальный вайб кальянов и неоновых ламп.

Для ускорения разработки приложение «Рокета» изначально создавалось на кроссплатформенном фреймворке React Native. Однако он не был полностью самодостаточным. Например, задачи вроде сложных анимаций или отображения перелистывающихся видео требовали нативной разработки.

По мере развития приложения «Рокетбанка» появилась потребность писать нативный код с бриджами React Native. Поэтому в отделе мобильной разработки стало три команды — 5 разработчиков React Native, 3 iOS-разработчика и 2 Android-разработчика. Я был в команде Android-разработчиков, писал нативную часть и связывал её с React Native частью.

Из этого опыта я вынес, что React Native — скорее инструмент унификации интерфейса, чем супер-буст в скорости разработки. Вся польза от него — в том, что интерфейс и бизнес-логика работают одинаково на iOS и Android.

Когда я только устроился в «Кухню», там ещё были ребята из оригинальной команды «Рокета». Я написал CTO «Кухни» и спросил, не ищут ли они мобильного разработчика в команду. Оказалось, что место есть.

У меня вообще было много свободы в «Кухне». Не нужно было ни за кем ходить и отчитываться. Однажды я рассказал директору, что у нас будет новое приложение для доставщиков, а он ответил: «Круто!»

На старте «Кухни» при разработке приложения ребята продолжили использовать React Native, потому что им казалось, что это классный инструмент. Но к моему приходу от него уже отказались из-за высокого коста на разработку и проблем с перфомансом.

В «Кухне» мне дали одну общую задачу — сделать работу склада лучше. Это было большое здание, которое делилось внутри на помещения поменьше: холодный склад, молочный склад и другие.

Мне показали склад и познакомили с бэкенд-разработчиком. После этого я сам решал, как именно улучшать складскую работу.

Сначала я сделал мобильное приложение для уже существующего внутреннего сервиса работников склада. Раньше сотрудники постоянно курсировали между складскими товарами и компьютером, чтобы отсканировать штрих-коды и посмотреть, что это за товар.

С мобильным приложением в одной руке у вас сканер для штрих-кодов, в другой — телефон. И вы, как быстрый ковбой на Диком Западе, сканируете ящик и сразу видите: здесь замороженная курица, которая поступила на склад 3 дня назад в объеме 20 кг. Теперь сотрудники могли проводить все операции прямо с телефона — начиная от приёмки до выдачи сырья.

Работники склада и курьеры пользовались одним сервисом, который разделялся по типу учётной записи. Через время я начал работать с той частью сервиса, которой пользовались райдеры-доставщики.

Я пытался всё сделать чуточку лучше. Например, часто курьер, доставив заказ на высотки, не мог отметить заказ как «доставленный», потому что не было интернета. Я внедрил отложенные отправки статусов доставок и улучшил трекинг локации райдеров.

Внедрить приложение для райдеров оказалось не так просто. Если, например, сотрудник склада не понимал логику приложения, он мог подойти к начальнику, которому до этого всё объяснил я.

Однако каждому курьеру отдельно невозможно всё объяснить — их слишком много. Поэтому я приравнял райдеров к внешним пользователям и старался делать их часть максимально понятной и красивой — ориентировался на дизайн-подходы «Рокета».

Sizl придумали те же ребята, которые сделали «Кухню». Если у «Кухни» была концепция домашней еды, то в Sizl такого нет. Мы готовим и доставляем Real food — это не фаст-фуд, но и не еда из ресторанов для гурманов. Качество еды немного лучше, чем если бы её приготовил дома среднестатистический человек, и готовится она из хороших, всегда свежих продуктов.

Мы хотим быть не просто историей про доставку, поэтому сейчас работаем над игровыми механиками с уже продуманными персонажами и лором.

В планах внедрение геймификации в разные взаимодействия, чтобы сделать заказ еды более увлекательным. В основе геймификации — понятная механика в стиле тамагочи. И у нас есть ощущение, что это должно хорошо сработать.

Мы запускались очень постепенно, разделив всё на этапы.

Запуск в агрегаторах. В первые пару дней мы запустились в агрегаторе и заказывали сами у себя. Этому есть сразу две причины:

Подключение промоушена в агрегаторах. Для этого нужно выбрать разные поддерживаемые агрегатором акции, например: «Закажи два, получи третье в подарок». Мы начали пробовать разные комбинации, заказов стало больше.

Запуск в приложении проходил по той же схеме: сначала заказывали сами, потом конвертировали людей из агрегаторов в пользователей приложения.

А вообще у этого подхода даже есть название — догфудинг. Это практика использования сотрудниками компании собственных продуктов и сервисов. Такой подход позволяет компаниям «держать руку на пульсе» и понимать, какой результат получает конечный клиент.

Каждая кухня обслуживает один район, в пределах которого можно доставить заказ за 30 минут. Почти всегда заказы везут на велосипедах — это удобно. Другие компании почему-то не доставляют еду на велосипедах, хотя у этого много плюсов: не нужно стоять в пробке и искать парковку. Но такая выгода есть в течение дня, когда дороги стоят. Вечером, когда нужно куда-то съездить, уже всё свободно, а на улице часто холодно. Поэтому иногда райдеры используют машины.

Мы выяснили две вещи.

У нас нет фокуса на какой-то специфической кухне, поэтому рядом с борщом у нас в меню есть и чизбургер, и хот-дог. Сейчас мы думаем добавить какие-то азиатские блюда, вроде роллов и воков.

Жить вместе удобно для прямой деятельности нашей компании. Несколько раз были ситуации, когда на кухню одновременно прилетало 5-6 заказов, а там только один курьер. Мы просто садились в две машины, доезжали до кухни и сами доставляли заказы. Или иногда на склад приходит доставка от поставщика упаковки, а складских сотрудников у нас нет. Можно быстро решить эту задачу вместе: поехать, забрать, привезти, увезти. В долгосрочной перспективе это уйдёт, но сейчас так выгодно.

Когда мы только запустились, у нас не было райдеров.

Мы ожидали, что заказов за день сначала будет немного, поэтому не хотелось тратить деньги на курьера, который бы был на фуллтайме и ничего не делал. Но на кухне всегда должен находиться ещё один человек кроме повара. Ответственный за точку мог бы доставить заказ и решить какой-нибудь вопрос. На запуске на кухне много чего происходило: например, как-то труба потекла. И мы по очереди становились этим ответственным.

Сейчас у нас несколько поваров и курьеров, но некоторые ребята из операционной команды всё ещё выезжают на кухню. Я тоже выезжаю, но уже не на дежурства, а для какой-то определенной работы: поменять жёсткий диск в системе видеонаблюдения или посмотреть, как дела с апдейтом приложения для райдеров.

У многих разработчиков, особенно в больших корпорациях, есть разрыв между тем, что делают они, и что непосредственно делает компания. Например, разработчик сидит, делает софт для курьеров, но не знает их боли. А мы все знаем, потому что во всем участвовали.

Когда стартовал приложение, решил посмотреть ситуацию с кроссплатформенными решениями. Однако ни одно из них на тот момент не подошло. И вот почему:

Почему не React Native

React Native я сразу не рассматривал. Ещё с работы над приложением «Рокета» я помнил, что рано или поздно работа с React Native выльется в три команды из нативных разработчиков и специалистов на RN.

Также у React Native есть ограничения по сложным анимациям, а для нас это критически важно, чтобы выделиться по UX среди конкурентов.

Почему не Flutter

Flutter не привлекает меня из-за отсутствия нативных интерфейсов. Весь UI, который можно сделать на Flutter — это UI Flutter.

Я хочу, чтобы пружинистый скролл на iOS работал как пружинистый скролл на iOS, а на Android — как на Android. Хочется, чтобы использование приложения было привычным для пользователя конкретной платформы. Виджеты Flutter такого не дают, и этот недостаток всегда меня в нём отталкивал.

Почему не KMP

KMP мне тоже сначала не нравился, потому что были сложности с управлением памятью. Однако скоро эту проблему решили.

Я кодил нативное приложение на Android и планировал найти в команду iOS-разработчика, который сделает нативное приложение на iOS. Во время разработки мне пришлось реализовать сложную логику заказа товаров.

Я хотел, чтобы пользователь мгновенно видел результат каждого действия в приложении. Например, когда добавляет товар в корзину, можно было показать результат: товар лежит в корзине. Но для подтверждения изменений нужно было обращаться к серверу.

Мне не нравилось заставлять пользователя ждать ответа сервера, лучше показывать результат сразу локально. А если что-то пошло не так, сервер все равно выдаст актуальную информацию, и локальное отображение скорректируется — приложение покажет корзину без борща и скажет пользователю: «Блин, борщ закончился».

С реализацией я справился, но это заняло довольно много времени. Дальше показалось глупо сидеть и реализовывать ту же самую логику для iOS. Поэтому я решил посмотреть, как можно переиспользовать то, что уже написал.

Решил, что наиболее адекватный вариант — перенести модуль с бизнес-логикой на Kotlin Multiplatform (KMP) и отдельно сделать iOS-интерфейс — найти человека на фронтенд. А потом подумал, что можно и фронтенд самому написать — современные подходы к вёрстке экранов в iOS и Android очень похожи. В общем, так никого и не нанял.

Работа с KMP требует единоразовых усилий на начальной настройке, после чего процесс разработки становится более гладким и предсказуемым.

После первичной настройки KMP у меня не возникало ситуаций, чтобы фича потребовала больше времени, чем если бы я писал ее на нативной платформе. Пришлось провести некоторое время, разбираясь в деталях, потому что документации 1,5 года назад не хватало. Сейчас такой проблемы нет.

Если бы мы выбрали нативную разработку, каждая условная задача на создание экрана или фичи была бы разделена на четыре:

Время на задачу по логике на KMP сопоставимо со временем на эту же задачу на нативном iOS, поэтому это время просто экономится.

О будущем и целях думать сложно, могу сказать только о настоящем. Сейчас получается так, что я пишу и на iOS, и на Android, что-то умею по бэкенду, что-то по DevOps. Эта штука с превращением в T-shaped специалиста как будто реально работает. На практике это очень удобно.

Сейчас я задумываюсь, что было бы, если бы я, наоборот, сконцентрировался на чём-то одном. Если бы я остановился на Android, я бы мог назвать себя Adnroid-экспертом с 10-летним опытом в этой области. Но я, конечно, не могу этого сделать. Пока я для себя ещё не понял, хорошо это или плохо.

В конце хочется сказать про Sizl в целом.

Успешный запуск стартапа невозможен без высокого уровня самостоятельности и ответственности всех его участников. Хотя формально в команде нет руководителей, этого и не требуется.

Любой из команды может взять под контроль горящую задачу, решить её сам или найти исполнителя. Но главное, что каждый нацелен именно на рост и развитие, а не просто решает проблемы.

Желаем Sizl скорейшего расширения и ждём новостей!

Если у вас есть вопросы к Сене, пишите мне — Максиму Павлову, попрошу его ответить.