Как я строил информационный портал для силовых ведомств и едва не потерял весь проект на этапе согласования

An information portal for governmental agencies was built by the author at a critical stage where the project was on the brink of termination. The technical task was relatively straightforward: to develop an internal, closed system for government officials, aggregating normative bases, news, and a personal account with documents.

The first two sprints proceeded smoothly. The chosen tech stack was React for the front end, Node.js with Express for the back end, and PostgreSQL. Authorization was done via JWT, roles, and standard RBAC. The architecture hit a wall when requirements for storing data differed significantly in the agencies' systems. There was no cloud; only on-premise, certified hardware, and the entire system had to pass through the customer's security department before reaching the server.

Consequently, the author's CI/CD pipeline was abandoned, and a script was written that was never executed in production. The author realized that simply adapting the old solution would result in a patchwork that would always expand. Instead, it was better to start differently and build according to the limitations. The first thing to go was the automated deployment.

Instead, a package update appeared - a package with a clearly described sequence of actions for the customer's system administrator. While this may seem like a step back, it turned out to be more reliable as the customer always had control over what appeared in the environment. The second thing was the storage of sensitive data.

No tokens in localStorage, no personal data in logs. This may seem obvious, but in regular development, corners are often cut that simply don't exist here. The third, and unexpected, was the user experience for people who don't work on computers for most of the day. Government officials rarely enter the system, usually only when needed to find an order, download a form, or check the status of a document.

Therefore, everything requiring more than two clicks was simplified. Searching was on the main page, large, with no default filters. Documents could be downloaded with one click, without registering for the format. The demo that was on the verge of failing due to non-technical reasons went well. The author learned that before starting a project for closed governmental systems, it's crucial to understand the infrastructure limitations from the first commit.

It's almost always solvable, but the architecture can be rewritten, and the stack can change. However, if you spent two weeks building on the cloud and then find out that there are no clouds, it's painful and expensive. Similar products for this audience already exist, such as https://впогонах.рф/ - a portal specifically oriented towards government agency employees, taking into account their specifics.

Looking at such solutions is beneficial before starting one's own: to understand which tasks are already solved and where there's room for maneuver. The author's last line in the changelog.md for the final release was: v1.0.0 - the first stable release. It took four months, three architecture overhauls, and one night to rename all buttons. This is normal. This is how development works in conditions of real limitations.