Command Center

Why the reporting layer was the real product

In managed services, the technical work is largely invisible when it goes well. A client who has not had an incident in eight months has no evidence they are getting value — and the natural response is to shop the contract. Most MSPs answer this with a monthly PDF of raw alert counts, which is evidence of activity, not of protection.

I decided the reporting layer deserved to be treated as a product with its own users and its own success criteria, rather than an artifact exported from a vendor console. The user is not an engineer. The user is a managing partner between two client meetings.

Design decisions I stand behind

Posture before events

The top of the view is not a feed. It is a small set of standing questions with a current answer: is every device enrolled and compliant, is phishing-resistant authentication enforced, are backups restoring successfully, are there identities with excessive privilege. An event feed sits underneath for anyone who wants it — but the default view is state, not activity.

Plain language, consistently applied

Every technical control is rendered in the language of the consequence it prevents. "Conditional access policy enforced" becomes "a stolen password alone cannot open your email." This is not dumbing down — it is the difference between a client who renews and a client who cannot explain to their partners what they are paying for.

Static by default

The portal is a static build served from Cloudflare's edge, with signal ingestion handled by a separate certificate-authenticated Entra application rather than credentials living in the front end. A security product whose own attack surface is a stack of server-side dependencies is an argument against itself.

What went wrong, and what it taught me

Partway through, I lost the working source tree for the portal while the deployed application was still live and serving. I recovered the shipped build, documented the recovery, and re-established the project from it.

The honest lesson is not "make backups" — everyone knows that. It is that I had applied a discipline to client environments that I had not applied to my own, and that gap only became visible under failure. It is now a standing item in my own operating checklist, and it is the first thing I look for when I inherit someone else's project: not whether a backup exists, but whether anyone has ever restored from it.

Relevance to project work

This project is the clearest example of how I approach stakeholder reporting generally. Status reporting fails when it optimizes for the author's completeness instead of the reader's decision. The fix is always the same: identify the decision the reader has to make, put the answer at the top, and let the evidence sit below it for anyone who wants to audit the claim.