Разработка веб-приложений
Веб-приложение отличается от сайта тем, что в нём люди работают, а не читают. Значит, главное — не первый экран, а логика: кто что видит, кто что может изменить, что происходит при ошибке и как система ведёт себя, когда данных становится много.
Ошибки в этом слое стоят дороже всего: переписать интерфейс несложно, переделать модель данных на живом проекте — больно. Поэтому мы показываем схему ролей и сущностей до того, как начать разработку.
Обсудить задачуЧто чаще всего заказывают
Как проектируем
- 01
Разбор процессов
Смотрим, как работа устроена сейчас: в таблицах, в мессенджерах, в голове у сотрудника. Автоматизировать хаос нельзя, сначала его нужно описать.
- 02
Роли и права
Определяем, кто что видит и может менять. Это влияет на всю архитектуру и потом почти не меняется без боли.
- 03
Модель данных
Проектируем сущности и связи. Показываем схему заказчику — не как формальность, а чтобы поймать несостыковки на бумаге.
- 04
Ядро и итерации
Собираем минимально работающую версию с главным сценарием, запускаем в реальную работу, дальше растим по данным.
- 05
Нагрузка и надёжность
Логи, мониторинг, резервные копии, поведение при отказе внешних сервисов. Для внутренних систем это важнее красоты.
Что закладываем всегда
- Разграничение прав на уровне ролей, а не «спрячем кнопку»
- История изменений: кто, когда и что поменял
- Понятные состояния объектов вместо флагов в базе
- Выгрузки и отчёты, потому что их попросят на второй неделе
- Интеграции через API, а не через ручной перенос данных
- Мониторинг и оповещения о сбоях
- Документация по развёртыванию и передача репозитория заказчику
Отдельные направления
Внутри этой услуги есть задачи со своей спецификой — они разобраны отдельно.
Что обычно спрашивают
Сколько стоит разработка веб-приложения?
Разброс здесь больше, чем в любой другой нашей услуге: кабинет с тремя экранами и внутренняя система с ролями, отчётами и интеграциями отличаются на порядок. Оценка возможна только после разбора процессов — на созвоне мы обычно понимаем масштаб за час.
Можно сделать по частям?
Так правильнее. Запускаем ядро с главным сценарием, отдаём в работу и достраиваем по обратной связи. Это дешевле, чем полгода делать всё и обнаружить, что половину не используют.
Готовое решение или своё?
Если задача типовая, честнее внедрить готовое — так и скажем. Своя разработка оправдана, когда процессы нестандартные и подстройка коробки обходится дороже, чем написать под себя.
Что с нагрузкой?
Проектируем под ожидаемый объём, а не «на всякий случай под миллион». Заранее закладываем возможность масштабирования, но не платим за неё сразу.
Кто владеет кодом?
Заказчик. Репозиторий, инфраструктура и документация передаются, продукт не привязан к нашей команде.