Internal system · In production

IT infrastructure inventory

An internal IT infrastructure panel: a tree of services and servers, an access matrix, SSH keys and portals, tasks, problems, changes and an audit log. It replaced a legacy panel of 35 tabs; from the first commit to delivery into production took 11 days, and the system holds 16 data models and 23 pages.

The pain

The inventory lived in a legacy panel and scattered notes: who is connected to what, what runs where, who owns it. When a person left, access and context left with them.

Now

One panel: a service tree, the «who has access to what» matrix, keys and portals, tasks, problems, changes and an audit log. Login under your own account, sections visible by role.

What the business gets

A person leaving no longer takes access and context with them: it is visible who is connected to what and who owns it.
The question «what do we switch off when someone leaves» is answered by the access matrix, not by a round of the administrators.
Every change of permissions stays in the audit log, so «who granted this» is a question with an answer.
Only the logic was carried over from the legacy panel: the screens were built anew, and the old interface was not dragged along.

From source to result

Servers and services
People and roles
Access grants
Keys and portals
Tasks, problems, audit

The service tree is curated by hand, while facts from the collector are laid over it as a separate layer: the gap between «what is declared» and «what is actually there» stays visible instead of being silently overwritten.

How it works

The destructive operations of the panel - importing employees and importing facts - go into a separate database in tests, and without its address the tests simply refuse to run. The rule appeared after a run against the working database: it switched off every real person at once, and the people lists in tasks went empty.

The delivery pipeline came together first: CI and deployment to both the sandbox and production appeared a little over two hours after the first commit, and auth with roles and tests the same day. The «how do we ship this» question was closed before the domain part existed.

Who maintains it now

The engineer. The panel is run by the company’s IT team: tasks, problems and changes are entered by the people who work with them.

Other cases for this step

Internal system · In production

Management finance loop

Every number the company has - in one system

The pain: The numbers lived in ten spreadsheets, private chats and the heads of three people. When key people left, both access and context left with them.
Now: One source: cash flow, budget, payment requests, reconciliation and reference books in a single application with roles and permissions.

Timeline: one month
Replaced: ten spreadsheets and a chat thread
Coverage: cash flow, budget, requests, reconciliation

The same system pays off across 3 more steps

Internal system · In production

Data platform

One source of truth instead of everyone’s own report

The pain: Every department exported marketplace data its own way, so meetings started with an argument about whose spreadsheet was right. Last year’s history did not exist at all.
Now: The platform collects data on a schedule and takes it through layers up to ready-made data marts. From there everyone - people, applications and agents - takes the numbers from the same marts.

Collection
Coverage
Replaced: manual exports in every department

The same system pays off across 2 more steps

Internal system · In production

Map of the legacy warehouse

What sits in the legacy database is now known

The pain: The legacy warehouse arrived as a black box: several databases, hundreds of tables and views, an OLAP cube, no description at all. Every question started with excavation.
Now: A reusable client, a CLI for queries and a data map rebuilt by one command: databases, tables, views, columns, with a map of the cube beside it. Plus a check that the data can be trusted.

Map coverage
Updating: the map is rebuilt by one command
Data check: cube freshness and cube-against-SQL reconciliation

Type: Internal system
Status: In production
Timeline: 11 days to a working system
Maintained by: the company’s IT team
Replaced: a legacy panel of 35 tabs

Next.jsReactTypeScriptPrismaPostgreSQLshadcn/uiVitestPlaywrightGitHub Actions