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

Обычная первая фраза на встрече: «нужен сайт, чтобы клиенты оставляли заявки и видели статус заказа». В ней два разных проекта. Первая половина - сайт: рассказать о компании и собрать заявку. Вторая половина - уже приложение: у клиента появляется вход, у заказа появляется состояние, и кто-то должен это состояние менять. Разница не в размере и не в количестве страниц, и она сильно влияет на цену.
01Простой признак: на сайте читают, в приложении работают
Сайт можно открыть без входа, прочитать и закрыть. Данные на нём одинаковые для всех посетителей, а самое сложное действие - отправить форму. Приложение начинается там, где у человека появляется своя учётная запись и свои данные внутри.
Проверьте будущий проект по пяти признакам. Если хотя бы три из них про вас, речь об приложении:
- Пользователь входит под своей учётной записью, и внутри он видит не то же, что видят остальные.
- Пользователей несколько типов, и у них разные экраны и разные права: клиент, сотрудник, менеджер, администратор.
- У заявки, заказа или сделки есть состояния, и они меняются по ходу работы.
- Действия одного человека меняют то, что видит другой.
- Внутри есть данные, которые один пользователь видеть не должен: чужие цены, чужие документы, контакты клиента.
Если ни один пункт не подходит, вам нужен сайт, и это хорошая новость: он дешевле, быстрее и проще в поддержке.
02Четыре вопроса, которые решают до кода
В приложении почти вся сложность решается не на этапе вёрстки, а на этапе договорённостей. Мы собираем схему до написания кода и утверждаем её с заказчиком, потому что переделывать её потом дороже всего.
- Какие есть роли. Не «пользователь и админ», а честный список: кто заводит заявку, кто её выполняет, кто согласует, кто видит отчёт.
- Какие есть состояния. Что происходит с заявкой от появления до закрытия, и какие переходы между состояниями разрешены, а какие нет.
- Кто что видит. Для каждой роли: какие поля доступны, а какие не должны доходить до её экрана вовсе.
- С чем надо связаться. Оплата, банк, служба доставки, бухгалтерия, CRM, API партнёра. Каждая внешняя система - отдельный кусок работы со своими сроками.
Эти четыре ответа и есть техническое задание. Пока их нет, любая оценка стоимости будет гаданием.
03Права доступа стоят дороже, чем кажется
Самая частая ошибка в требованиях звучит так: «сделайте, чтобы подрядчик не видел цену другого подрядчика». В интерфейсе это выглядит как одна спрятанная строчка, и оценивают её соответственно. На деле прятать надо не строчку, а данные: если сервер прислал цену в браузер, её видно в инструментах разработчика, независимо от того, нарисована она на экране или нет.
Правильный ответ дороже: сервер вообще не должен отдавать то, на что у пользователя нет права. Причём одинаково в трёх местах - в ответе на запрос данных, в мгновенных обновлениях и в доступе к файлам. И это надо закрыть автотестами, потому что глазами такое не проверяется: экран выглядит правильно в обоих случаях.
04Из чего складывается цена
У сайта цена в основном зависит от объёма: сколько страниц, сколько языков, насколько сложный дизайн. У приложения объём страниц почти ни на что не влияет, а считают три другие вещи.
- Число ролей. Каждая новая роль - это свои экраны, свои права и свои проверки, а не «ещё одна кнопка».
- Число состояний и переходов между ними. Восемь переходов вместо трёх - это в разы больше случаев, которые надо описать и проверить.
- Внешние системы. Подключение к банку или к API партнёра почти всегда дольше, чем кажется: чужая сторона живёт по своему расписанию.
Наши открытые цифры: сайт - от 3200 манат, веб-приложение - от 25 000 манат. Ориентир по сроку из сданного проекта: маркетплейс с двумя кабинетами, сделкой из шести состояний, файлами и обновлениями в реальном времени занял четыре месяца разработки плюс приёмочное тестирование на стороне заказчика.
05Когда приложение не нужно
Чаще, чем принято думать. Если клиенту достаточно узнать статус по звонку или по сообщению, а заявок в день немного, связка «сайт с формой плюс таблица или готовая CRM» решает задачу за долю стоимости и работает завтра, а не через несколько месяцев. Приложение окупается там, где ручная передача информации между людьми уже мешает: заявок много, сторон несколько, и ошибки стоят денег.
Честный порядок такой: сначала проверяем, закрывается ли задача сайтом и готовыми инструментами. Если да, мы так и говорим.
06Как это выглядит вживую
Проще один раз открыть, чем прочитать десять определений. В нашем портфолио есть кейс «Маркетплейс для строительства» с публичной демо-версией: регистрация не нужна, на странице входа готовые учётные записи заказчика и двух компаний, кнопка рядом с аккаунтом входит сразу. Там видно всё, о чём написано выше: роли, состояния заказа, что видит и чего не видит посторонняя компания. Если открыть заказчика и компанию в двух разных браузерах, действие одной стороны появится у другой без перезагрузки страницы.
Ещё статьи
- Аналитика Что показывает Google Search Console - и чего не показывает Три сайта в Search Console: позиция у всех примерно одна, а доля кликов отличается в разы. Скриншоты отчётов и разбор, что из этих цифр следует, а что нет.
- Веб-разработка Зачем писать самому, когда Django сделает всё за тебя? Почему Django - выбор для быстрого и безопасного запуска: защита данных, масштабируемость и экономия ресурсов.
- Мобильная разработка React Native: как создать приложение, пока ваш кофе ещё горячий Один код для iOS и Android, скорость запуска и нативная производительность - почему его выбирают Facebook, Instagram и Airbnb.