Рисунок 1.

Поэтому я начал с простого вопроса: «Как сделать приложение, если умеешь делать сайт?» И наткнулся на фреймворк на основе WebView — тот, что позволяет собирать мобильные приложения из веб-технологий. Это был малоизвестный инструмент, который буквально помог «обернуть» веб-страницу в нативную оболочку.

И знаете что? Это стало решением. Приложение заработало.

— Звучит как хак. А какие были сложности?

— Первые месяцы — никаких. Пользователям было неважно, на чём написано приложение. Главное — чтобы кнопка «Открыть дверь» работала. И она работала.

Но когда мы захотели добавить Bluetooth-интеграцию, чтобы гость мог открыть замок со смартфона, пришлось писать нативные плагины. Один — для Android на Java, другой — для iOS на Objective-C. Я этих языков не знал. Поэтому пришлось искать готовые решения, немного менять код, экспериментировать. В итоге всё получилось.

— А как насчёт инфраструктуры? Где вы разворачивали серверы?

— Вот тут тоже был лайфхак. Вместо того, чтобы платить 1 000 рублей в месяц за VPS в дата-центре, мы поставили обычный ПК в офисе и использовали его как внутренний сервер — он до сих пор работает!

Конечно, это не масштабируется до миллиона пользователей. Но для стартапа с 50 объектами — более чем достаточно. Главное — понимать, где можно сэкономить, а где нельзя.

Позже, когда в команду пришли фронтенд-разработчики и дизайнеры, они, мягко говоря, не поддержали выбранный стек. «Это же несерьёзно!» — говорили они. Но у нас не было выбора: нужно было запустить продукт за неделю, а не за полгода.

— То есть вы жертвовали «правильной» архитектурой ради скорости?

— Абсолютно. И считаю, что в стартапе это не жертва, а стратегия. Большие команды могут месяц заниматься одной кнопкой. У нас не было месяца — у нас не было даже недели.

Когда ресурсы минимальные, главное — проверить гипотезу. Работает ли продукт? Решает ли он «боль» клиента? Если да — тогда уже можно думать о CI/CD, рефакторинге, архитектуре и прочем.

— Как происходит коммуникация между бэкендом и фронтендом сегодня?

— По принципу «Не лезь в чужой огород». У меня — API, бэкенд, логика. У фронтенда — интерфейс, анимации, UX. Я не спорю, как должна выглядеть кнопка. Они не спорят, как должен работать вебхук.

Это снимает 90% конфликтов. Доверие плюс чёткие границы приводят к продуктивности.

— Какие еще принципы успешной работы и обучения команды есть у вас в арсенале?

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

Командная атмосфера — доверие, поддержка, позитивный настрой — тоже играют роль. Помогают сохранять мотивацию и двигаться вперёд даже в условиях высокой нагрузки.

— А что лично для вас — источник драйва в работе?

Очевидно, команда! Во-первых, команда. А во-вторых — разнообразие задач. Иногда запросы от клиентов и партнёров кажутся необычными, но в процессе реализации становится очевидно, что они дают реальную ценность.

— Например, новые фреймворки? Кстати, как вы относитесь к трендам в разработке: Go, Rust?

— Честно? Скептически. За 12 лет в индустрии я видел десятки технологий: Ruby on Rails, Python, теперь Go. Все пишут о простоте, скорости, масштабируемости…

Но вот пример: нам нужно было выпустить push-уведомления в CRM для риэлторов. Решили протестить Java — тогда это был модный выбор. Но каждый раз, чтобы проверить изменение, мы компилировали код. А на PHP (да, на PHP!) — поменяли две строчки, и сразу есть результат.

Разница в производительности? Никакой. Разница в скорости итераций? Огромная.

— А как же золотое правило роста — быть в тренде и теме рынка?

— Я не против новых языков — особенно если за них больше платят (а платят!) Но если старый стек решает задачу — зачем менять?

— Значит ли это, что ниша посуточной аренды перспективна для разработчиков?

— Конечно. Рынок огромен, но автоматизация — на уровне 2010 года. Люди до сих пор передают ключи лично! А ведь можно управлять заселением, оплатой, уборкой — и всё через одно приложение.

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

И спрос на такие решения есть. И он растёт, поверьте.

— И почему же? Чем обусловлен интерес предпринимателей к таким разработкам и автоматизации в целом?

— Даже управление одной квартирой вручную отнимает много ресурсов. А приложения управляют десятками и сотнями объектов. Одна система автоматизации решает до 60% рутинных задач — от заселения до оплаты и коммуникации с гостем. Для бизнеса это возможность быстро расти и с минимальными вложениями.

— Если взглянуть шире: почему эта ниша интересна всем игрокам рынка — и специалистам, и бизнесу?

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

— Мотивация на лицо! Что бы вы посоветовали тем разработчикам, кто хочет запустить свой продукт на рынке посуточной аренды?

— Не рассчитывайте на идеальный стек. Начните с того, что знаете. Еще одно правило: не верьте документации на 100%. Только живое тестирование покажет, работает ли интеграция.

— И без работающего MVP — без подтверждения, что ваш продукт кому-то нужен, тоже никуда!

— Да, делайте то, что решает «боль». Архитектура, дизайн, CI/CD — тоже важно, но не приоритет на начальных этапах. Приоритет — это результат.

В стартапе первостепенна скорость проверки гипотезы. Когда ресурсов в обрез, важно иметь не самый модный стек, а решить реальную проблему здесь и сейчас. Да, рано или поздно нужно будет рефакторить, что-то переписать. Но иногда лучше запустить «некрасиво», но быстро, чем идеально — и никогда!