Первый заказ с VibeMarket: как Jet Service вырос из корпоративного сайта в веб-платформу

Заказ на Jet Service пришёл ко мне через VibeMarket. Оплата была прямым платежом, без TON Escrow. Для меня это важная часть истории: площадка помогла нам найти друг друга, а способ расчёта мы согласовали отдельно.

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

Я сам создавал VibeMarket, чтобы заказчики могли находить разработчиков по реальным работам, а не только по описанию профиля. Поэтому особенно приятно, что первый такой заказ пришёл через собственную площадку.

Так Jet Service постепенно вырос из сайта-представительства в веб-платформу с каталогами и собственной CMS.

На главной собраны переходы к услугам, моделям воздушных судов и другим разделам сайта.

Когда страницам понадобились связи

У посетителей Jet Service разные задачи. Одному нужно понять, обслуживают ли конкретную модель самолёта. Другой ищет запчасть по каталожному номеру. Третий хочет изучить воздушное судно перед покупкой. Ещё кто-то приходит посмотреть, какие работы уже выполнялись.

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

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

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

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

В карточке самолёта важна не только модель

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

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

Это потребовало внимания к мелочам в CMS. Характеристики должны переноситься на новую строку, сохранять заданный порядок и позволять повторно использовать названия полей. Если редактор однажды завёл «Основной двигатель», ему не нужно заново вводить этот заголовок для каждой модели. А автоматически сортировать такие строки по алфавиту было бы неправильно: порядок задаёт смысл.

Сейчас в опубликованной записи семейства Cessna 172 / Reims F172 подробно заполнена одна модификация. Остальные варианты можно добавлять теми же средствами, но каталог пока заполнен не всеми версиями.

В карточке общие сведения о семействе отделены от характеристик конкретной версии.

Запчасти: связи полезны, когда они заполнены

Карточка авиационной детали устроена иначе, чем обычная карточка товара. Здесь важны каталожный номер, производитель, назначение, совместимые модели, прежние и альтернативные номера, возможные заменители и связанные услуги. Я заложил эти поля в CMS, чтобы данные можно было связывать и переходить от одной позиции к другой.

При этом на сайте пока не большой интернет-магазин с полной номенклатурой. На момент подготовки статьи в публичном каталоге опубликована одна позиция: J.P. Instruments Fuel Scan FS-450. У этой записи нет опубликованных заменителей или связанных каталожных номеров, поэтому на скриншоте я не буду изображать такую связь как уже наполненный каталог. Наличие, комплектность, стоимость и применимость детали к конкретному борту предлагается уточнять у Jet Service.

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

На момент проверки в каталоге опубликована одна позиция; наличие и совместимость уточняются по запросу.

В карточке указаны производитель и каталожный номер; связанные позиции для этой записи не опубликованы.

Зачем понадобилась собственная CMS

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

Я сделал административную часть под структуру Jet Service: отдельные типы записей, характеристики, изображения и связи между ними. В интерфейсе использовал React-компоненты, в том числе на основе shadcn/ui. Редактору важно сохранить запись и сразу увидеть, как она будет выглядеть для посетителя.

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

Административная панель стала отдельной частью проекта. Я проектировал формы, работу с базой и повседневные действия редактора: как повторно использовать характеристики, сохранять порядок строк, связывать каталоги и не терять контекст при загрузке изображений. Для входа предусмотрел дополнительное подтверждение по электронной почте и управление сессиями. При этом важно было не разлогинивать администратора слишком часто и не оставлять его авторизованным без нужды.

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

Для меня главный критерий CMS простой: насколько легко поддерживать содержимое в актуальном состоянии. Может ли сотрудник добавить услугу, изменить описание модели или заменить изображение сам? Сохраняются ли связи? Понятно ли, как материал будет выглядеть после публикации? Такие вопросы всплывали уже после того, как основная функциональность вроде бы была готова.

Под капотом: сайт, CMS и обновления

Jet Service построен на Next.js, React и TypeScript. Для серверной части и развёртывания я использовал собственную инфраструктуру и Docker. Пришлось настроить домен, HTTPS, отправку писем, хранение данных и порядок обновления приложения. Это те части работы, которых посетитель обычно не замечает, пока они не мешают пользоваться сайтом.

Отдельно я работал над производительностью загрузки: изображениями, тяжёлыми медиафайлами, запросами и поведением отдельных компонентов. Для каталога важно не загружать все записи, когда посетителю нужна одна карточка. Видео я проверял и в Chrome на компьютере, и в Safari на iPhone.

Разделы и поисковая структура

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

Для каждой сущности предусмотрен собственный адрес и набор метаданных. У разделов есть иерархия, а между связанными страницами можно переходить по внутренним ссылкам. На действующем сайте доступны sitemap.xml и robots.txt; в карте сайта перечислены, среди прочего, разделы услуг, модели и страницы подбора воздушных судов. Это техническая основа для дальнейшего наполнения, но сама по себе она не обещает рост поискового трафика.

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

Страница описывает направление услуги и данные, нужные для обсуждения конкретной задачи.

Интерфейс проверялся в браузере, а не только на макете

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

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

Похожий урок я получил с видео в главном блоке. После изменений для iOS ролик в какой-то момент перестал нормально воспроизводиться. Пришлось проверять ограничения мобильного Safari и повторно проходить сценарии на разных устройствах. Правка для одного браузера может задеть остальные, поэтому я не считал её законченной, пока не проверял страницу и на десктопе, и на мобильных устройствах.

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

Мобильная версия главной страницы, проверенная при ширине 390 пикселей.

Что я отдавал ИИ, а что проверял сам

В Jet Service я активно использовал ИИ-инструменты и AI-агентов: просил подготовить код, переработать компоненты, разобрать ошибки, предложить варианты решения и помочь с тестами. Это сокращало ручную работу, особенно если задача была ограничена конкретным компонентом и у неё был понятный способ проверки.

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

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

Мой обычный цикл был таким: сформулировать ожидаемое поведение, поручить агенту ограниченное изменение, посмотреть затронутые файлы, а потом пройти пользовательский сценарий в браузере. Если менялась сложная часть, я отдельно проверял соседние функции и повторно открывал страницу на нужном устройстве. Это дольше, чем принять ответ агента на веру, зато именно так обнаруживается расхождение между «код изменён» и «задача действительно решена».

Эта тема перекликается с материалами ВайбЖурнала о том, где AI-агентам нужен человеческий контроль и когда прототип на вайбкодинге пора переводить в инженерный режим. В работе над Jet Service я пришёл к тому же выводу на конкретных задачах: код можно поручить инструменту, а критерии готовности и проверку поведения оставлять за человеком.

Что получилось и что я вынес из проекта

Jet Service работает по адресу jetservice.tech. Сейчас на сайте можно изучить услуги, модели воздушных судов, запчасти, выполненные работы и статьи. Для управления этими материалами есть собственная CMS. Раздел продажи самолётов уже существует, но на момент подготовки статьи он ещё не содержит опубликованных предложений.

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

Главный вывод для меня не в том, что каждый корпоративный сайт нужно превращать в платформу. Это было бы лишним для простого набора страниц. В случае Jet Service каталог быстро потребовал моделей, модификаций, характеристик и связей с услугами и запчастями. Как только такие данные начали повторяться, отдельная CMS и модель содержимого стали практичнее ручного редактирования страниц.

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

Мне хочется, чтобы на VibeMarket появлялось больше таких историй от разных разработчиков. Так заказчики смогут выбирать по работающему продукту и описанию реальной задачи, а исполнители покажут больше, чем список технологий.