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

Портфолио на сайте. Кейс = задача, решение и результат, а не галерея скринов; так заказчик понимает, подходит ли вам подрядчик.

Зачем смотреть портфолио, а не только цену

Сайт разработчика - его витрина. Портфолио показывает, с чем он уже работал, и насколько честно описывает процесс.

Вот где ломают.

Я смотрю чужое портфолио глазами заказчика: есть ли похожие задачи, виден ли результат, не одни ли «красивые картинки».

На своём сайте я стараюсь давать не «сделали сайт», а «была проблема X, сделали Y, получили Z».

Мелочь? Нет.

Заказчик ищет совпадение по нише и по типу задачи: лендинг, каталог, интеграция.

Что должно быть в нормальном кейсе

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

Красные флаги в портфолио

Двадцать проектов, все без ссылок - возможно, mockup или NDA, но много «без URL» подозрительно. Один и тот же шаблон на всех скринах - конвейер без адаптации.

Сроки плывут отсюда.

Нет даты - непонятно, актуален ли опыт, «100+ сайтов» без одного развёрнутого кейса - маркeting.

Как проверить кейс за пять минут

Откройте сайт с телефона. Отправьте форму (тестовую). Посмотрите скорость первого экрана. Загляните в footer: не копипаст ли шаблон. Сравните с описанием кейса: правда ли там «форма в Telegram», если в кейсе так написано.

Я обычно прошу заказчика сделать то же при выборе любого подрядчика. Подробнее - как проверить подрядчика до оплаты.

Портфолио разработчика vs студии

У solo-разработчика меньше кейсов, но глубже описание: вы знаете, кто именно писал код, у студии больше логотипов, но проект мог делать junior, а смотрите «ответственный» и стек, не только логотип клиента.

NDA и «не могу показать»

NDA нормален. Тогда просят: обезличенное описание, скрин staging, отзыв с именем, созвон с реальным клиентом по согласованию. Полное отсутствие доказательств - риск.

Что искать под вашу задачу

Нужен лендинг для услуг - не ведитесь на портфолио только из интернет-магазинов. Нужна интеграция CRM - ищите кейс с API, не «лендинг на Tilda». Сопоставьте с вашим ТЗ.

Заказчик выбрал по красивому UI, а проекту нужен был каталог на 500 SKU. Портфолио не содержало ни одного каталога.

Отзывы

Отзыв с именем, компанией и конкретикой («сдали за 3 недели, форма в Telegram работает») лучше десяти «рекомендую!!!». Видео-отзыв на 30 секунд - золото, проверьте, не стоят ли все отзывы за один день.

Блог и экспертиза

Статьи вроде этой показывают, как человек думает. Технический блог не обязателен, но пустой сайт «мы лучшие» без текста - слабый сигнал. Я веду блог partly для SEO, partly чтобы заказчик прочитал до созвона и не задавал базовые вопросы.

Как оформить своё портфолио, если вы заказчик

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

Структура страницы кейса (шаблон)

Задача: лендинг для юриста, заявки в Telegram
Срок: 12 рабочих дней
Стек: HTML, форма -> bot API, Метрика
Не входило: SEO-продвижение, тексты
Результат: https://...
Цифра: время загрузки LCP 1.8s mobile

Цена и портфолио

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

Мобильное портфолио

Если разработчик показывает только desktop-скрины, спросите мобильную версию. Большинство ваших клиентов зайдут с телефона. Про скорость - lazy loading.

Итоговая мысль

Портфолио читают как резюме: совпадение задач, прозрачность, живые ссылки. Потратьте полчаса на 3-5 кейсов до предоплаты - сэкономите недели неправильного выбора. Вопросы для созвона - до предоплаты.

Скриншоты vs живой продукт

Dribbble красив, но кнопка может быть н нарисована, в портфолио разработчика приоритет - ссылка, при этом если только mockup, в подписи должно быть «концепт, не prod». Обман не intentional, но заказчик должен понимать.

Я добавляю в кейс дату: «апрель 2025». Старый кейс на jQuery не значит, что сейчас так же делаю, но показывает опыт. Без даты непонятно.

Open source и pet-проекты

У solo dev может быть мало «коммерческих» логотипов, но есть repo на GitHub с README и demo. Для технического заказчика это плюс. Для «просто лендинг» смотрите коммерческие кейсы.

Спросите: «Покажите похожий по объёму проект и что было сложного», ответ с деталями лучше, чем «делали много».

Как использовать портфолио на переговорах

Не «мне нравится дизайн кейса 3», а «в кейсе 3 форма в Telegram, нам нужно так же, как там?» Конкретная привязка к вашему ТЗ. Так созвон идёт по делу, не по вкусам.

Структура кейса, которую я использую

Задача одним абзацем. Что сделал: стек, срок, роль. Скрин или ссылка на живой сайт (с согласия клиента). Цифра, если можно: «LCP с 4.2 до 1.8 сек», «форма + Telegram за 2 дня». Без NDA - «проект в нише B2B, NDA».

Три сильных кейса лучше десяти «лендинг на Tilda», заказчик B2B смотрит похожие ниши: «делали ли вы что-то для медицины/опта/услуг».

Что не класть в портфолио

Макеты без запуска, учебные проекты без контекста, чужие темы с маркетплейса «как свои». Одна проверка - whois и переписка: ваш ли это кейс на самом деле.

Скриншоты vs живые ссылки

Живая ссылка убедительнее, но сайт клиента мог измениться или закрыться, я делаю и ссылку, и скрин на дату сдачи. Подпись: «Состояние на июнь 2026».

Для NDA-проектов: описание задачи, стек, схема без логотипа, отзыв с инициалами, заказчики понимают, что вы работали с серьёзными клиентами.

Страница «Процесс» рядом с портфолио

Как вы работаете: созвон, ТЗ, staging, приёмка. Снижает страх «а вдруг исчезнет». Я ссылаюсь на как веду проект один и ТЗ.

Обновление раз в квarter

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

Что сделать сразу

Я solo-разработчик и каждый такой проект веду сам: созвон, оценка, staging, выкладка, передача доступов. Заказчику не нужно разбираться в терминах, но нужно понимать решения: что вы выбрали, почему, что проверить при приёмке. Я обычно фиксирую это в переписке или в ТЗ, чтобы через полгода не вспоминать «а мы же договаривались».

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

Маршрут для заказчика

1. Выберите 3 кейса, близких к вашей задаче.
2. Откройте каждый сайт с телефона и проверьте форму.
3. Сверьте описание кейса с реальным функционалом.
4. Попросите обезличенный пример при NDA.
5. Почитайте блог или посты подрядчика, если есть.
6. Задайте на созвоне один вопрос по конкретному кейсу из портфолио.

Ошибки, которые видел на созвонах

• Выбирать по одному красивому скрину без проверки живого сайта.
• Не искать кейсы похожие по типу (каталог vs лендинг).
• Игнорировать отсутствие ссылок и дат в портфолио.
• Не просить контакт прошлого клиента при крупном бюджете.
• Путать дизайн-портфолио и разработку: макет Figma не равен prod.

Когда имеет смысл привлечь разработчика. Если в портфолио нет ни одного кейса близкого к вашему объёму, лучше обсудить с разработчиком pilot или этапность, чем быть первым экспериментом без договорённости. Ориентиры по срокам и бюджету - на странице цен, услуги - в разделе услуг.

Рядом по теме: Проверка подрядчика, Вопросы до предоплаты, Сколько стоит сайт.

Зафиксируйте решение письмом после созвона.