Заказать обратный звонок
Заполните форму ниже
Нажимая кнопку «Отправить», вы соглашаетесь на обработку персональных данных
БЛОГ DIgital concierge
Интервью с создателем приложения для посуточной аренды DC: инсайты для крутых разработок и разработчиков
Интервью с создателем приложения для посуточной аренды DC: инсайты для крутых разработок и разработчиков
Приветствуем, друзья! Если вы читали первую часть нашего интервью с Виктором П. — разработчиком сервиса Digital Concierge, — то помните, как всё началось: с простой идеи автоматически заселять гостей в номера. В результате из небольшого проекта для одного отеля получилась полноценная платформа для посуточной аренды!
Сегодня мы продолжим нашу беседу — и на этот раз для разработчиков. Расскажем, что скрывается за «упаковкой» DC и почему такие решения становятся мощной мотивацией для создания digital-продукта на посуточном рынке!
Сегодня мы продолжим нашу беседу — и на этот раз для разработчиков. Расскажем, что скрывается за «упаковкой» DC и почему такие решения становятся мощной мотивацией для создания digital-продукта на посуточном рынке!
Читайте статьи первыми
Отправляя свои контактные данные, вы соглашаетесь с политикой конфиденциальности
Будем присылать самое интересное раз в 2 недели
Как запустить приложение без опыта и бюджета: инсайты из первых уст
— Виктор, вы уже упоминали, что раньше занимались сайтами. Вы ведь не были мобильным разработчиком изначально?
— Совершенно верно. В 2017–2018 годах была задача — выпустить приложение для управления посуточной арендой: заселение, открытие дверей через Bluetooth, удаленная коммуникация с гостями. Но ни команды, ни бюджета, ни опыта в мобильной разработке у меня не было. Я занимался вебом, знал CSS, HTML, JavaScript — и всё.
Поэтому я начал с простого вопроса: «Как сделать приложение, если умеешь делать сайт?» И наткнулся на фреймворк на основе WebView — тот, что позволяет собирать мобильные приложения из веб-технологий. Это был не React Native и не Flutter, а малоизвестный инструмент, который буквально помог «обернуть» веб-страницу в нативную оболочку.
И знаете что? Это стало решением. Приложение заработало, и Digital Concierge занял свою нишу на рынке.
— А какие были сложности?
— Первые месяцы — никаких. Пользователям было неважно, на чём написано приложение. Главное — чтобы кнопка «Открыть дверь» работала. И она работала.
Но когда мы захотели добавить Bluetooth-интеграцию, чтобы гость мог открыть замок со смартфона, пришлось писать нативные плагины. Один — для Android на Java, другой — для iOS на Objective-C. Я этих языков не знал. Поэтому пришлось искать готовые решения, немного менять код, экспериментировать. В итоге всё получилось.
Позже, когда в команду пришли фронтенд-разработчики и дизайнеры, они, мягко говоря, не поддержали выбранный стек. «Это несерьёзно!» — слышал от них. Но у нас не было выбора, стояла задача — запустить продукт за неделю, а не за полгода.
— То есть вы жертвовали «правильной» архитектурой сервиса ради скорости?
— Да. И считаю, что в стартапе это не жертва, а стратегия. Большие команды могут месяц заниматься одной кнопкой. У нас не было месяца — у нас не было даже недели.
Когда ресурсы минимальные, главное — проверить гипотезу. Работает ли продукт? Решает ли он «боль» клиента? Если да — тогда уже можно думать о CI/CD, рефакторинге, архитектуре и прочем.
Интересно, что даже в отчетах это было приоритетно: менеджер хотел видеть не красивый дашборд в Power BI, а «некрасивую» табличку с живыми цифрами. Он выбирал её, потому что она давала то, что нужно — без лишнего.
— Виктор, вы уже упоминали, что раньше занимались сайтами. Вы ведь не были мобильным разработчиком изначально?
— Совершенно верно. В 2017–2018 годах была задача — выпустить приложение для управления посуточной арендой: заселение, открытие дверей через Bluetooth, удаленная коммуникация с гостями. Но ни команды, ни бюджета, ни опыта в мобильной разработке у меня не было. Я занимался вебом, знал CSS, HTML, JavaScript — и всё.
Поэтому я начал с простого вопроса: «Как сделать приложение, если умеешь делать сайт?» И наткнулся на фреймворк на основе WebView — тот, что позволяет собирать мобильные приложения из веб-технологий. Это был не React Native и не Flutter, а малоизвестный инструмент, который буквально помог «обернуть» веб-страницу в нативную оболочку.
И знаете что? Это стало решением. Приложение заработало, и Digital Concierge занял свою нишу на рынке.
— А какие были сложности?
— Первые месяцы — никаких. Пользователям было неважно, на чём написано приложение. Главное — чтобы кнопка «Открыть дверь» работала. И она работала.
Но когда мы захотели добавить Bluetooth-интеграцию, чтобы гость мог открыть замок со смартфона, пришлось писать нативные плагины. Один — для Android на Java, другой — для iOS на Objective-C. Я этих языков не знал. Поэтому пришлось искать готовые решения, немного менять код, экспериментировать. В итоге всё получилось.
Позже, когда в команду пришли фронтенд-разработчики и дизайнеры, они, мягко говоря, не поддержали выбранный стек. «Это несерьёзно!» — слышал от них. Но у нас не было выбора, стояла задача — запустить продукт за неделю, а не за полгода.
— То есть вы жертвовали «правильной» архитектурой сервиса ради скорости?
— Да. И считаю, что в стартапе это не жертва, а стратегия. Большие команды могут месяц заниматься одной кнопкой. У нас не было месяца — у нас не было даже недели.
Когда ресурсы минимальные, главное — проверить гипотезу. Работает ли продукт? Решает ли он «боль» клиента? Если да — тогда уже можно думать о CI/CD, рефакторинге, архитектуре и прочем.
Интересно, что даже в отчетах это было приоритетно: менеджер хотел видеть не красивый дашборд в Power BI, а «некрасивую» табличку с живыми цифрами. Он выбирал её, потому что она давала то, что нужно — без лишнего.
“
На первых этапах пользователю вообще неважен дизайн. Ему важно: нажал — получил результат. Была кнопка? Открывала дверь? То, что нужно. Позже, когда DC заработал и появилось время на улучшения, мы уже могли позволить себе красивые интерфейсы. Но сначала — функционал.
Доверяй и действуй: как наладить коммуникацию между фронтендом и бэкендом
— Как изменилась ваша роль, когда в команде появились фронтендеры?
— Сейчас я почти не трогаю внешнюю часть приложения. Отвечаю за бэкенд — интеграции, логику, API. А за то, как это выглядит, отвечают другие. И я сознательно «отпустил» фронтенд. Доверяю команде, у них есть вкус, опыт, понимание UX.
— А как в принципе строится коммуникация между бэкендом и фронтендом?
— Через уважение и границы. У нас есть API-контракты, документация, регулярные синхронизации. Но главное — не пытаться «улучшать» чужую работу без запроса. Фронтендеры знают, как лучше показать данные. Я знаю, как их правильно отдать. И этого достаточно. Когда кто-то вторгается в чужую зону ответственности — это тормозит процесс и мотивацию.
— А бывали случаи, когда фронтенд и бэкенд разошлись в ожиданиях?
— Бывало. Чаще всего это происходило на ранних этапах, когда API ещё не готов или требования не до конца проработаны. Сейчас мы стараемся обсуждать такие моменты заранее, на стадии планирования задачи. Если всё же расходимся во мнениях, садимся вместе, смотрим на пользовательский сценарий и решаем, что важнее: наличие данных, скорость отклика или визуальное поведение. Главное — не становиться в оборону, а пытаться найти решение для общего результата.
— Как изменилась ваша роль, когда в команде появились фронтендеры?
— Сейчас я почти не трогаю внешнюю часть приложения. Отвечаю за бэкенд — интеграции, логику, API. А за то, как это выглядит, отвечают другие. И я сознательно «отпустил» фронтенд. Доверяю команде, у них есть вкус, опыт, понимание UX.
— А как в принципе строится коммуникация между бэкендом и фронтендом?
— Через уважение и границы. У нас есть API-контракты, документация, регулярные синхронизации. Но главное — не пытаться «улучшать» чужую работу без запроса. Фронтендеры знают, как лучше показать данные. Я знаю, как их правильно отдать. И этого достаточно. Когда кто-то вторгается в чужую зону ответственности — это тормозит процесс и мотивацию.
— А бывали случаи, когда фронтенд и бэкенд разошлись в ожиданиях?
— Бывало. Чаще всего это происходило на ранних этапах, когда API ещё не готов или требования не до конца проработаны. Сейчас мы стараемся обсуждать такие моменты заранее, на стадии планирования задачи. Если всё же расходимся во мнениях, садимся вместе, смотрим на пользовательский сценарий и решаем, что важнее: наличие данных, скорость отклика или визуальное поведение. Главное — не становиться в оборону, а пытаться найти решение для общего результата.
“
Коммуникация между бэкэндом и фронтендом сегодня происходит по принципу «Не лезь в чужой огород». У меня — API, бэкенд, логика. У фронтенда — интерфейс, анимации, UX. Я не спорю, как должна выглядеть кнопка. Они не спорят, как должен работать вебхук. Это снимает 90% конфликтов. Доверие плюс чёткие границы приводят к продуктивности.
Дубай, Греция и «умные» замки: как не сломаться на международном рынке
— DC не так давно вышел на новый рынок. Как продукт адаптирован под Дубай?
— Там всё не так просто. Например, власти Дубая ввели закон: все замки в апартаментах должны быть от одной сертифицированной компании. У них нет открытого API, и из-за этого есть сложности с интеграцией наших решений.
Зато с другим удивительно легко. Например, «умный» дом одного бренда, который официально не работает в Дубае, на деле работает. Просто документация отстаёт от реальности. И это частая проблема: в API-доках пишут одно, а на практике — другое. Поэтому я не даю гарантий по интеграции, пока не протестирую всё сам.
— А как проходит локализация приложения под разные страны?
— Мы выкладываем приложение во все регионы App Store и Google Play. Язык подстраивается автоматически: если у пользователя не русский — показываем английский. Не самое элегантное решение, но рабочее. Завтра мы можем выйти на посуточный рынок Греции, и приложение будет там работать. Главное — чтобы гость мог его скачать.
— Как вы тестируете интеграции в новых регионах, если нет официальной документации, например?
— Мы делаем всё на месте. Без исключений. Даже если есть поддержка, я не уверен до тех пор, пока не запущу сценарий от первого до последнего шага в реальных условиях. Часто именно такие «полевые» проверки помогают понять ограничения, о которых никто не пишет: геоблокировки, локальные сервисы, региональные политики безопасности. Интеграция — это не код. Это работа в контексте конкретной юрисдикции.
— DC не так давно вышел на новый рынок. Как продукт адаптирован под Дубай?
— Там всё не так просто. Например, власти Дубая ввели закон: все замки в апартаментах должны быть от одной сертифицированной компании. У них нет открытого API, и из-за этого есть сложности с интеграцией наших решений.
Зато с другим удивительно легко. Например, «умный» дом одного бренда, который официально не работает в Дубае, на деле работает. Просто документация отстаёт от реальности. И это частая проблема: в API-доках пишут одно, а на практике — другое. Поэтому я не даю гарантий по интеграции, пока не протестирую всё сам.
— А как проходит локализация приложения под разные страны?
— Мы выкладываем приложение во все регионы App Store и Google Play. Язык подстраивается автоматически: если у пользователя не русский — показываем английский. Не самое элегантное решение, но рабочее. Завтра мы можем выйти на посуточный рынок Греции, и приложение будет там работать. Главное — чтобы гость мог его скачать.
— Как вы тестируете интеграции в новых регионах, если нет официальной документации, например?
— Мы делаем всё на месте. Без исключений. Даже если есть поддержка, я не уверен до тех пор, пока не запущу сценарий от первого до последнего шага в реальных условиях. Часто именно такие «полевые» проверки помогают понять ограничения, о которых никто не пишет: геоблокировки, локальные сервисы, региональные политики безопасности. Интеграция — это не код. Это работа в контексте конкретной юрисдикции.
“
DC есть, где развернуться и в России, и в международном масштабе. На нашем рынке максимум два-три подобных сервиса. И даже среди них мало тех, у кого продукт действительно работает, а не просто лежит в App Store.
Гонка за модными языками: быть или не быть
— Как вы относитесь к трендам в разработке: Go, Rust и тому подобным?
— Честно? Скептически. За 12 лет в индустрии я видел десятки технологий: Ruby on Rails, Python, теперь Go. Все пишут о простоте, скорости, масштабируемости…
Но вот пример: нам нужно было выпустить push-уведомления в CRM для риэлторов. Решили протестить Java — тогда это был модный выбор. Но каждый раз, чтобы проверить изменение, мы компилировали код. А на PHP — поменяли две строчки, и сразу есть результат.
Разница в производительности? Никакой. Разница в скорости итераций? Огромная.
— А как же золотое правило роста — быть в тренде и теме рынка?
— Я не против новых языков — особенно если за них больше платят. Но если старый стек решает задачу — зачем менять?
— Но ведь за новые языки действительно платят больше!
— Да, и это главный стимул для разработчиков. Знакомые специалисты уходили на Go — и получали больше. Но если ваша задача решается на Java или PHP — зачем усложнять? Особенно если вы небольшая команда.
Крупные компании могут позволить себе эксперименты: потратить миллион для того, чтобы перейти на новую архитектуру. Стартапу это может стоить жизни. Поэтому я за баланс: быть в курсе трендов — да, слепо следовать им — нет.
— Как вы относитесь к трендам в разработке: Go, Rust и тому подобным?
— Честно? Скептически. За 12 лет в индустрии я видел десятки технологий: Ruby on Rails, Python, теперь Go. Все пишут о простоте, скорости, масштабируемости…
Но вот пример: нам нужно было выпустить push-уведомления в CRM для риэлторов. Решили протестить Java — тогда это был модный выбор. Но каждый раз, чтобы проверить изменение, мы компилировали код. А на PHP — поменяли две строчки, и сразу есть результат.
Разница в производительности? Никакой. Разница в скорости итераций? Огромная.
— А как же золотое правило роста — быть в тренде и теме рынка?
— Я не против новых языков — особенно если за них больше платят. Но если старый стек решает задачу — зачем менять?
— Но ведь за новые языки действительно платят больше!
— Да, и это главный стимул для разработчиков. Знакомые специалисты уходили на Go — и получали больше. Но если ваша задача решается на Java или PHP — зачем усложнять? Особенно если вы небольшая команда.
Крупные компании могут позволить себе эксперименты: потратить миллион для того, чтобы перейти на новую архитектуру. Стартапу это может стоить жизни. Поэтому я за баланс: быть в курсе трендов — да, слепо следовать им — нет.
“
За 12 лет в индустрии я видел, как каждые пару лет появляется язык будущего: сначала Ruby on Rails, потом Python, теперь Go. Все идут учить, но на практике разницы в решении задач часто нет. Поэтому я не против новых технологий, но не вижу смысла менять рабочий инструмент только потому, что он «модный». Особенно в стартапе, где каждая минута на счету.
Почему посуточный рынок — золотая жила для разработчика
— Как вы считаете, ниша посуточной аренды перспективна для разработчиков?
— Конечно. Рынок огромен, но автоматизация — на уровне 2010 года. Люди до сих пор передают ключи лично! А ведь можно управлять заселением, оплатой, уборкой — и всем через одно приложение.
Конкуренция пока минимальна, поэтому можно спокойно прийти с хорошим решением и занять свою нишу. Особенно если фокусироваться не на «крутых» технологиях, а на реальных задачах бизнеса.
Спрос на такие решения есть, и он растёт, поверьте.
— А можно ли войти в разработку без опыта?
— Честно? Это сложно. У меня был кейс: человек прошёл трёхмесячные курсы, но не понимал даже базовых концепций — что такое переменная, функция, класс. Без фундамента — никуда.
Конечно, можно выучить 1 000 слов за час, как в английском, но без грамматики вы не построите предложение. В программировании то же самое: нужны основы логики, понимание структуры данных. Образование или хотя бы системное самообразование обязательно.
— Что бы вы посоветовали тем, кто хочет запустить свой продукт на посуточном рынке?
— Не рассчитывайте на идеальный стек. Идеальный дизайн, код, архитектура — не главное на старте. Начните с того, что знаете. Решите задачу, а потом улучшайте. И не верьте документации на 100%. Только живое тестирование покажет, работает ли интеграция.
Что ещё важно — рабочий MVP и понимание, что ваш продукт кому-то нужен, поэтому делайте то, что решает «боль». Архитектура, дизайн, CI/CD нужны, но это не приоритет. Приоритет — это результат.
— Как вы считаете, ниша посуточной аренды перспективна для разработчиков?
— Конечно. Рынок огромен, но автоматизация — на уровне 2010 года. Люди до сих пор передают ключи лично! А ведь можно управлять заселением, оплатой, уборкой — и всем через одно приложение.
Конкуренция пока минимальна, поэтому можно спокойно прийти с хорошим решением и занять свою нишу. Особенно если фокусироваться не на «крутых» технологиях, а на реальных задачах бизнеса.
Спрос на такие решения есть, и он растёт, поверьте.
— А можно ли войти в разработку без опыта?
— Честно? Это сложно. У меня был кейс: человек прошёл трёхмесячные курсы, но не понимал даже базовых концепций — что такое переменная, функция, класс. Без фундамента — никуда.
Конечно, можно выучить 1 000 слов за час, как в английском, но без грамматики вы не построите предложение. В программировании то же самое: нужны основы логики, понимание структуры данных. Образование или хотя бы системное самообразование обязательно.
— Что бы вы посоветовали тем, кто хочет запустить свой продукт на посуточном рынке?
— Не рассчитывайте на идеальный стек. Идеальный дизайн, код, архитектура — не главное на старте. Начните с того, что знаете. Решите задачу, а потом улучшайте. И не верьте документации на 100%. Только живое тестирование покажет, работает ли интеграция.
Что ещё важно — рабочий MVP и понимание, что ваш продукт кому-то нужен, поэтому делайте то, что решает «боль». Архитектура, дизайн, CI/CD нужны, но это не приоритет. Приоритет — это результат.
“
В стартапе первостепенна скорость проверки гипотезы. Когда ресурсов в обрез, важно иметь не самый модный стек, а решить реальную проблему здесь и сейчас. Поэтому иногда лучше запустить «некрасиво», но быстро, чем идеально — и никогда!
Хотите получить больше инсайтов или задать вопрос Виктору? Напишите нам в telegram-канале — и мы обязательно ответим!
Остались вопросы?
Отправляя свои контактные данные, вы соглашаетесь с политикой конфиденциальности
Записывайтесь на бесплатную консультацию
Подпишитесь на наш Telegram-канал!
Рассказываем о важных материалах и событиях для начинающих и профессионалов посуточного бизнеса