APM wasn't designed from scratch as a product. It grew out of thirty years of writing tools — for clients, for production systems, and sometimes just to prove they could be built. Every generation of this thing ran real servers before the next one replaced it.
Started programming around 1995, mostly Perl. The motivation was almost never "this needs to exist" — it was usually closer to "I wonder if this is actually possible."
That curiosity drove things like a complete SMTP and POP3 server, written entirely in Perl. It worked well enough that it ended up running real email for real people. It stayed in production for nearly 10 years.
For five years, ran a web hosting company. Managed 100+ domains for clients, and rather than use an off-the-shelf control panel, built a complete one from scratch in Perl — FTP, email, DNS, billing, anti-spam, the whole stack.
That included the custom SMTP/POP3 servers mentioned above. They weren't a proof of concept any more — they were the actual mail infrastructure for real clients. That changes how you think about reliability.
Got curious about what was actually happening at a lower level. The result was a multi-threaded HTTP server in C++ — not a production tool, just an exercise in understanding what the language and OS were doing under the hood.
It worked. That was the entire point.
Client reality set in. Perl wasn't popular on their radar, so shifted toward PHP for most delivery work. Not a personal preference — a practical one. Whatever gets the job done and doesn't leave the client with something they can't maintain.
Spent this period building web apps, automation tools, and internal systems for clients. Also transitioned from graphic design roots into full-stack engineering.
Moved fully to Node.js. The compelling part was unifying frontend and backend in one language, and the event-driven model felt like a better fit for real-time systems.
Like most Node developers, ended up using PM2 for process management. It worked fine — until the workloads grew. Running multiple instances with custom load balancing started feeling fragmented: several processes, several configs, Nginx upstreams wired up by hand. Something more unified felt necessary.
So built one. TPM1 was a Node.js process manager with a socket server at the core that routed connections across worker instances. Rough in places, but it proved the concept. PM2 was gone from that point.
Eventually packaged it into a single binary. That worked, but came with some inconvenient realities:
Time to find something better.
Discovered Dart and it had one very appealing property: compile to a real standalone binary with no runtime dependency.
The result was TPM7 — a complete rewrite of the process manager in Dart. Binary size dropped from 160 MB to around 8 MB. It ran in production for over a year without incident.
Solid. But the obsession with pushing further didn't stop there.
Go felt immediately right for this kind of tool. Small binaries, fast startup, a concurrency model that makes the hard parts manageable rather than terrifying. The standard library covers most of what a systems tool needs without dragging in a runtime.
After about four months of focused development, the first working release of APM shipped. At 2.4 MB compressed — down from 160 MB when this whole thing started. Since then it's been in continuous development: features added, architecture refined, rough edges smoothed off by actual production load.
APM currently manages the infrastructure behind a 30+ branch cake shop chain operating across the UK and Canada — a combination of heavy back-office systems and live customer-facing services. Zero-downtime restarts, session persistence, real-time dashboards, the lot.
From the early Perl tools through Node.js, Dart, and now Go — every generation of this was built for and ran actual production systems. APM is no different. Sometimes the most useful tool is the one you had to build yourself because nothing else quite did the job.