В какой-то момент обычного сайта перестаёт хватать. Сначала добавляется форма. Потом личный кабинет. Потом менеджер просит сделать отдельный раздел для сотрудников. Потом появляется Excel, который почему-то считается «временным решением», а через два года в нём уже живёт половина операционной работы. Где-то рядом 1С, CRM, ещё одна таблица и человек, который знает, в каком порядке всё это нужно открывать, чтобы заказ всё-таки дошёл до клиента.
Само по себе это не катастрофа. Большинство бизнесов именно так и растут: сначала всё держится на нескольких людях, потом на таблицах, потом на наборе готовых сервисов, соединённых между собой где получится. Проблема появляется позже, когда компания уже не помещается в эти инструменты, а менять привычный способ работы страшно. Потому что если убрать одну таблицу, может выясниться, что без неё половина отдела вообще не знает, что делать утром.
Веб-приложение имеет смысл именно в этот момент. Не как «сайт нового поколения», а как собственный рабочий инструмент компании, который наконец собирает процесс в одном месте. Пользователь входит под своей учётной записью, видит только то, что ему положено, работает со своими данными, проходит определённые этапы и оставляет после себя понятную историю действий. Не нужно объяснять сотруднику, какие три окна держать открытыми рядом.
Где начинается приложение
Хороший пример — система, в которой у заявки может быть несколько состояний, несколько участников и довольно много правил. Менеджер создал заявку, специалист её проверил, бухгалтер запросил дополнительные данные, руководитель согласовал, после чего информация ушла в другую систему. На сайте такое можно изобразить, но довольно быстро вокруг этой формы начинает расти настоящая бизнес-логика. Кто имеет право изменить статус? Что произойдёт, если один из документов не загружен? Можно ли одновременно редактировать заявку двум сотрудникам? Кто должен увидеть изменение? Что делать, если внешняя система временно недоступна? Вот в этот момент вы уже строите не сайт, а приложение.
Мы начинаем именно с этих вопросов. Сначала разбираем сценарии и модель данных, понимаем, какие у пользователей роли, какие состояния есть у сущностей и как они между собой связаны. Это звучит менее эффектно, чем разговор про интерфейс, зато позволяет не выяснять через четыре месяца разработки, что важное бизнес-правило никогда не было описано.
Интерфейс как инструмент
Сам интерфейс строим так, чтобы он ощущался не как набор страниц, а как инструмент. Пользователь меняет данные, открывает следующий раздел, получает результат действия без полной перезагрузки страницы и продолжает работу примерно так же, как привык к обычной программе. Next.js и React хорошо подходят для этого слоя, а серверная часть на Go отвечает за бизнес-логику, интеграции, фоновые задачи и всё то, что не должно быть спрятано в браузере.
Данные хранятся в PostgreSQL. Транзакции нужны не ради красивого слова в архитектурной схеме, а потому что в реальном бизнесе бывают ситуации вроде «деньги списали, заказ не создался» или «два сотрудника одновременно изменили одну заявку». Система должна уметь гарантировать целостность таких операций, а не просто надеяться, что пользователи будут аккуратными.
Рост и нагрузка
Отдельный разговор — рост. Часто заказчик говорит, что ему нужно приложение «сразу на десятки тысяч пользователей», хотя сегодня его одновременно используют двести человек. Здесь легко потратить лишние деньги на инфраструктуру, которая понадобилась бы только в воображаемом будущем. Мы стараемся сделать иначе: понять, какой рост действительно ожидается, какие операции будут самыми тяжёлыми, где могут возникнуть ограничения, и заложить возможность расширения там, где она действительно нужна.
Перед запуском приложение имеет смысл нагрузить искусственно. Это не столько способ похвастаться количеством запросов в секунду, сколько возможность заранее увидеть, где система начнёт вести себя плохо. Иногда узким местом оказывается база. Иногда неожиданно тяжёлая операция, которую никто не считал критичной. Иногда вообще внешний сервис, на который приложение должно регулярно обращаться.
Продукт остаётся вашим
И ещё одна вещь, о которой приятно договориться заранее: продукт должен остаться вашим. Код находится в вашем репозитории, документация не является секретным знанием команды разработки, инфраструктура описана настолько, чтобы другой инженер смог её понять. Мы вообще не видим особой пользы в ситуации, когда через два года бизнес не может изменить собственный продукт без разрешения его создателя.
Первую рабочую версию обычно можно получить за 8–16 недель. Это не обещание собрать за этот срок весь огромный продукт из будущего. Скорее наоборот: стараемся найти тот сквозной сценарий, который уже даёт бизнесу пользу, и довести его до рабочего состояния. Потом становится гораздо легче решать, что добавлять следующим.
И, наверное, здесь есть главное отличие хорошего веб-приложения от дорогой самописной системы: через несколько месяцев сотрудники перестают замечать, что работают с «разработкой». Для них это просто инструмент. Они открывают его утром и делают свою работу. А всё остальное — архитектура, Go, PostgreSQL, контейнеры — остаётся там, где и должно быть, то есть за экраном.