Проектирование и разработка веб-приложений начинается не с открытия редактора кода, а с ответов на несколько вопросов: кто будет пользоваться сервисом, какие у него роли и сценарии, какие данные хранятся и как они связаны между собой. Если пропустить этот этап, переделки в середине разработки обходятся в разы дороже, чем правка макета в Figma. Дальше показываю порядок работ, который использую сам на проектах: с чего начинается архитектура, как строится интерфейс до кода и что реально влияет на цену и сроки.
С чего начинается проектирование веб-приложения до кода
Я делю подготовительный этап на шесть шагов, и пропустить порядок не получается: каждый следующий шаг зависит от предыдущего.
- Сбор требований и ролей - кто пользуется сервисом (админ, менеджер, клиент, партнёр) и что каждая роль должна уметь делать
- Карта пользовательских сценариев - что происходит от входа в систему до результата, по каждой роли отдельно
- Модель данных - какие сущности хранятся (заказы, пользователи, платежи, документы) и как они связаны
- Архитектура и стек - монолит или разделение на бэкенд и фронтенд, какие сервисы взаимодействуют между собой
- Прототип интерфейса - экраны под каждый сценарий, сначала в wireframe, потом в кликабельном макете
- Техническое задание - фиксация объёма, экранов, ролей и интеграций перед тем, как открыть редактор кода
По моей практике этап занимает от одной до трёх недель в зависимости от количества ролей и экранов. Пропустить его и сразу сесть кодировать можно, но тогда архитектурные решения принимаются на ходу, а любое изменение модели данных в середине разработки тянет за собой миграции и правки уже написанного кода.
Архитектура: решения, которые дорого менять после старта
Часть решений можно поменять на любом этапе без больших потерь - цвет кнопки, текст на экране, порядок полей в форме. Другая часть решений закладывается в фундамент, и переделка означает переписывание кода, а не правку стилей.
Стек и границы между модулями
Я обычно развожу проект на отдельный бэкенд и фронтенд, а не собираю монолит на одном фреймворке. Для админ-панели с ролями и правами доступа беру React, для дашборда с графиками и отчётами - Vue, а бэкенд с API и бизнес-логикой пишу на Laravel. Это даёт возможность развивать части сервиса отдельно: поменять дашборд, не трогая админку, добавить мобильное приложение поверх того же API. Где проходит граница между модулями и что отдаётся через API, а что остаётся внутри сервиса, я фиксирую до старта разработки - после старта эта граница обрастает кодом с обеих сторон.
Модель данных и роли доступа
Схему базы данных и список ролей я рисую до того, как написана первая миграция. Если в проекте есть три роли (администратор, менеджер, клиент), а права каждой роли на каждую сущность не описаны заранее, то в середине разработки появляется четвёртая роль или новое ограничение - и это переписывание уже готовых контроллеров и проверок доступа, а не полчаса работы.
Сюда же на этапе архитектуры включаю внешние интеграции - эквайринг Т‑Банка, доставку через СДЭК, уведомления через Telegram-бота на aiogram, синхронизацию процессов через n8n. Каждая интеграция диктует свои поля в базе и свои сценарии ошибок: платёж не прошёл, курьер недоступен, вебхук пришёл дважды. Эти сценарии проще заложить в схему сразу, чем добавлять патчами позже.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Интерфейс и прототип: от wireframe до кликабельного макета
Экран - это ответ на вопрос, что человек должен сделать на этом шаге, а не просто картинка. Поэтому я начинаю с wireframe: чёрно-белые блоки без шрифтов и цвета, только структура и порядок действий. На этом этапе легко увидеть, что в форме заказа семь обязательных полей вместо трёх, или что раздел с отчётами вообще не нужен нужной роли.
После wireframe собираю кликабельный прототип в Figma - экраны связаны переходами, кнопки и ссылки ведут туда же, куда поведут в готовом сервисе. Прототип даёт возможность прогнать сценарий с заказчиком или с реальным пользователем ещё до того, как написана хоть одна строка кода, и поймать нестыковки в сценарии, а не в интерфейсе. У Figma есть открытый API, через который структуру макета и параметры компонентов можно забирать напрямую в разработку - это ускоряет передачу между дизайном и кодом на проектах с большим количеством экранов.
Отдельно фиксирую дизайн-систему - набор компонентов (кнопки, поля, таблицы, модальные окна) с состояниями. Без неё каждый новый экран рисуется заново, а в коде появляются три разных стиля одной и той же кнопки.
Из чего складывается цена и что реально влияет на срок
Цена проекта складывается не из часов на кодирование, а из объёма решений, которые нужно принять и проверить до того, как код станет финальным.
| Фактор | Как влияет на срок и цену |
|---|---|
| Количество ролей и уровней доступа | Каждая новая роль - это отдельные сценарии, экраны и проверки прав, а не просто переключатель в настройках |
| Число внешних интеграций | Эквайринг, доставка, CRM, аналитика - у каждой свои поля данных, вебхуки и сценарии ошибок, которые нужно продумать в архитектуре |
| Готовность контента и данных | Если тексты, каталоги или данные для миграции не готовы, прототип и разработка идут с заглушками, а доработка происходит позже |
| Кастомный дизайн против готовой библиотеки компонентов | Дизайн с нуля увеличивает этап прототипа, готовая библиотека компонентов его сокращает |
У меня разработка веб-приложения или SaaS-сервиса «под ключ» начинается от 300 000 ₽, минимальный срок - от 8 недель, и в эту стоимость входит этап проектирования, а не только код. Если нужен только прототип интерфейса и техническое задание без разработки, это отдельная и более короткая по деньгам и срокам задача. Если нужен независимый взгляд на уже готовый прототип или архитектуру, такие разовые задачи я беру через консультацию.
Что нужно подготовить заказчику перед стартом
Часть задержек в проектах происходит не из-за разработки, а из-за того, что решения на стороне заказчика принимаются медленнее, чем идёт работа.
- Список ролей и что каждая роль должна делать в сервисе, а не только «админ и пользователь»
- Референсы - похожие сервисы или экраны, которые нравятся или, наоборот, не нравятся, и почему
- Список обязательных интеграций: платёжная система, CRM, доставка, аналитика, рассылки
- Один человек, который принимает решения по макетам быстро, а не согласовывает их с пятью отделами
- Черновые тексты и данные для наполнения прототипа - хотя бы часть, чтобы экраны не собирались на условном «lorem ipsum»
Типовые ошибки, из-за которых проекты ломаются
Эти ошибки повторяются от проекта к проекту, и почти все они происходят от того, что решение откладывают на потом вместо того, чтобы принять его на этапе проектирования.
- Роли и права придумываются по ходу разработки, а не фиксируются заранее - на одном проекте с админ-панелью на React мы добавили роль «наблюдатель» после того, как контроллеры уже были написаны под двух пользователей, и часть проверок доступа пришлось переписывать заново
- Интеграции продумываются в конце, когда модель данных уже написана под другую структуру, и вебхуку от платёжной системы или курьерской службы просто некуда сохраниться без миграции
- Вместо технического задания - фраза «сделайте как у конкурента», из-за которой на середине проекта выясняется, что часть функций не нужна, а часть, наоборот, забыта
- Прототип утверждается по картинке, без проверки реального сценария - в разделе с отчётами кнопка «скачать» ведёт в никуда, потому что сценарий скачивания не проговорили заранее
- Этапы проектирования и разработки смешиваются - код пишется раньше, чем зафиксирован список экранов и ролей, и любое уточнение требований превращается в переделку уже написанного
Частые вопросы
Сколько времени занимает проектирование веб-приложения до старта разработки?
По моей практике на архитектуру, модель данных и прототип интерфейса уходит от одной до трёх недель - срок зависит от количества ролей и экранов. Для проекта со сроком разработки от 8 недель проектирование обычно укладывается в первые две-три недели.
Чем архитектурный этап отличается от прототипа в Figma?
Архитектура - это решения про данные, роли, интеграции и границы между бэкендом и фронтендом, они не видны на экране. Прототип в Figma - это то, что видит и нажимает пользователь. Оба этапа идут параллельно, но архитектуру я фиксирую в схеме и документе, а прототип - в кликабельном макете.
Можно ли начать разработку без готового технического задания?
Можно, но тогда решения по объёму и границам функций принимаются на ходу, а любое изменение модели данных в середине разработки требует миграций и правок уже написанного кода. На практике это выходит дороже, чем две-три недели на проектирование в начале.
Сколько стоит проектирование и разработка веб-приложения под ключ?
У меня такой проект начинается от 300 000 ₽ при минимальном сроке от 8 недель, и это включает этап проектирования - архитектуру, модель данных и прототип интерфейса, а не только код. Итоговая цена зависит от количества ролей, экранов и интеграций.