No comments yet.
What’s different about our approach
Automation by default. We standardize device/identity baselines and recurring tasks with policy + scripts, aiming to cut busywork tickets and MTTR. Wherever sensible we use reproducible configs and self-healing checks rather than one-off fixes.
Security as table stakes. Enforced MFA, least privilege, rapid patch SLAs, phishing simulations with coaching, and a documented incident runbook from day one (not “phase 3”).
Observable operations. Clients get a simple monthly scorecard: patch compliance %, mean time to resolution, backup/restore test results, phishing failure rate, and “preventable ticket” trend lines.
Transparency over lock-in. Clear SLOs, shared runbooks/playbooks, and clean data export. If we’re not a fit later, you shouldn’t be stuck.
Simple pricing. Straightforward per-user/per-device plans with published inclusions. No surprise “consulting blocks” for routine care.
Where we are now
Working with early customers and refining our onboarding playbooks (identity, endpoint, backup, email security, and network).
Building on a vendor-agnostic stack; we favor open standards and, where it makes sense, open-source components for monitoring/telemetry and remote support.
Publishing select runbooks so clients (and other MSPs) can see how we work.
What I’d love feedback on from HN
If you run or buy from an MSP: what are your biggest pain points today?
Which metrics would you actually care to see each month?
Any strong opinions on stack choices to avoid or must-haves for a modern MSP?
Would open-sourcing more of our playbooks be genuinely useful, or just noise?
If this resonates (or if you think it’s misguided!), I’d appreciate your comments. I’m especially looking to talk with SMB founders/IT leads, other MSP operators, and security folks who’ve lived the day-to-day.
Thanks!!
