Why I built it
Every company laptop was supposed to run a monitoring agent. On most of them it did not. It crashed on Windows, failed at startup on every recent Ubuntu release, and had been that way for three years.
I was handed it in week one with requirements that amounted to "make it work", and I had never used Linux. So I installed it on every machine I could get and used it until it failed, writing down each failure. Two weeks later I had a list of more than fifteen bugs and vulnerabilities, and that was what I worked from.
Halfway through the summer I picked up a second project on the business side. Sales procurement ran on email and paper across six departments, and one cycle took over a week.
What it does
I built three things over the three months: a monitoring agent that now runs on 400 Windows and Ubuntu laptops, a release pipeline that pushes an update to all of them in about five minutes, and an enterprise resource planning system for sales procurement used by more than 300 people.
I led the first two and was primary developer on the third, on a team of five.
How it works
How an update reaches 400 laptops
- 1
I build a new release on a dashboard on my machine.
One click builds the Windows version and the Linux version of the agent.
FastAPIC++
- 2
The dashboard signs the release and publishes it.
It goes to the company server, behind an nginx reverse proxy. Only someone with the private signing key can publish.
SHA-256nginx
- 3
The agent on every laptop checks the server for new releases.
300 Windows laptops and 100 Ubuntu laptops.
C++WindowsUbuntu
- 4
Each laptop verifies the release before installing it.
It checks the signature and the SHA-256 checksum. If either fails, nothing is installed.
signing keySHA-256
- 5
The updated agent sends its telemetry back.
The fields the company asked for, including the active browser URL.
CassandraMongoDB
The agent. I rewrote it from scratch in C++ and hand-wrote every package it needed, so it compiles to one binary with no outside dependencies. It reads the active browser URL through Chrome's accessibility tree. Before it went anywhere near the fleet I ran it on seven pilot machines and watched the logs come back through ngrok.
The ERP. Python and FastAPI over PostgreSQL, React on top, with role-based authentication so each person only sees the pages their role allows. Jenkins and GitLab handle the deploys.
The hard parts
Three years of crashes, and nobody knew why
The agent died on most Windows machines without logging anything useful. The build pulled in a 300MB package, and on a laptop with ordinary memory the process ran out of room and the OS killed it.
I stopped depending on it, hand-wrote the core logic, and compiled to a binary. 300MB became 20MB, and every Windows machine where it had been crashing came up and stayed up. Finding the cause took two weeks of reading the existing code.
The Linux build was written against X11
With Windows working I turned to the hundred Ubuntu machines, where the agent did not start at all. The original targeted X11, and current Ubuntu ships Wayland, so those calls failed at startup.
I rewrote the Linux side too. It came out under 1MB and reached all 100 machines.
Over half the developers were killing it on purpose
The agent now worked, and developers were ending it in Task Manager. More than half of them. That biases the data toward the people who leave it running.
Nobody asked me to fix this. I built a watchdog that watches process health and brings the agent back within seconds of a kill. If both processes go down at once, it flushes a last telemetry log inside the grace period the OS gives you during shutdown, and Windows Task Scheduler sits underneath as a final catch. Downtime incidents dropped 60%.
Six department heads described the workflow six different ways
I had no business background, so I sat down with the head of every department and asked how sales procurement actually worked. They gave me six answers. The heads of customer solutions and of sales gave me different sequences for what happens between a customer booking a demo and devices being installed.
I had no way to judge which was right, so I built a dependency graph of all the requirements and worked out which steps were physically impossible until another step finished. That ruled out most of the orderings and left two that both worked. I built both, put them side by side, and let the two heads argue it out in front of a running demo until they agreed.
The cycle went from over a week to two or three days.