Личный сайт-портфолио: от задачи до production

Проблема и личный контекст

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

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

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

Он не заменяет резюме, а дополняет его: резюме показывает общий опыт, сайт — как именно я работаю.

Аудитория и продуктовая задача

До разработки я определил четыре основные группы посетителей:

• HR-специалисты;
• IT-рекрутеры;
• руководители AI- и продуктовых команд;
• владельцы бизнеса, которым нужны автоматизация и цифровые решения.

Главный вопрос пользователя сформулировал так:

Можно ли за несколько минут понять, какие задачи решает Вадим и как он работает?

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

Для первой версии я сознательно отказался от отдельного backend, базы данных и административной панели. Приоритетом были понятная структура, реальный контент, адаптивность и возможность быстро добавлять новые проекты.

Архитектура сайта

Проект создан на Next.js с App Router и TypeScript.

В структуру вошли:

• главная страница;
• каталог проектов;
• отдельные страницы кейсов;
• контакты;
• страница 404.

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

Контент проектов хранится в MDX. Это позволяет добавлять новые кейсы через отдельные файлы, не перестраивая весь сайт и не создавая каждую страницу вручную.

Метаданные каждого проекта хранятся во frontmatter. Система проверяет обязательные поля, уникальность slug, статус публикации и порядок отображения проектов.

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

Организация работы с AI

Для проекта я создал рабочую систему из специализированных AI-ассистентов:

• главный архитектор и координатор;
• frontend-разработчик;
• UI-дизайнер и визуальный продюсер;
• редактор кейсов;
• QA и техническая проверка.

Это не была автономная команда. Я задавал каждой роли инструкции и контекст, формулировал требования, сравнивал варианты и принимал итоговые решения.

Рабочий цикл выглядел так:

задача → требования → вариант решения → проверка → корректировка → production-QA

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

В процессе я освоил практический подход к AI-assisted разработке, включая вайб-кодинг. AI ускорял создание и исправление кода, поиск причин ошибок и подготовку вариантов решений, но постановка задачи, архитектура, тестирование и ответственность за результат оставались за мной.

Разработка и итерации

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

Карточки проектов на мобильном

Проблема: карточки по-разному вели себя на небольших экранах.

Причина: отдельные элементы имели неодинаковые размеры и правила отображения.

Решение: карточки были приведены к единому компоненту и общему адаптивному поведению.

Изображение работало локально, но не открывалось на Vercel

Проблема: файл загружался в Windows, но пропадал после публикации.

Причина: регистр символов в пути не совпадал с реальным названием файла, а Linux учитывает это различие.

Решение: названия и пути были приведены к одному регистру и повторно проверены в production.

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

Проблема: локальная версия обновилась, а публичная оставалась прежней.

Причина: изменения не были зафиксированы и отправлены в удалённый репозиторий.

Решение: рабочий процесс был выстроен через Git-коммиты, push в GitHub и автоматический deploy в Vercel.

Публикация и технический запуск

Я самостоятельно прошёл полный путь публикации:

локальный проект → Git → GitHub → Vercel → собственный домен

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

После подключения репозитория к Vercel новые версии стали автоматически собираться и публиковаться после git push.

Затем я настроил DNS-записи у регистратора и подключил собственный домен. После запуска проверил маршруты, изображения, контакты, PDF-резюме и адаптивность сайта на компьютере и телефоне.

Дополнительно были настроены:

• SEO-метаданные;
• canonical-ссылки;
• Open Graph;
• robots.txt;
• sitemap.xml;
• подтверждение сайта в Яндекс Вебмастере.

Сайт стал не только способом показать прошлые проекты, но и самостоятельным цифровым продуктом. Я определил задачу, организовал AI-assisted разработку, проверил реализацию и довёл проект до production на собственном домене.