Shasta Cloud

The problem: Managed Service Providers juggled 4–20 vendor systems to manage enterprise networks, wasting hours on context-switching and troubleshooting across fragmented tools. The insight: MSPs didn't need a better dashboard - they needed one dashboard. And LiDAR-based spatial mapping could replace the guesswork in access point deployment. The result: Deployment time cut from 30 to 10 minutes per access point, 50% cost reduction vs vendor hardware, adopted by 7+ global enterprise clients.

I spent the first three weeks shadowing MSP engineers at two partner companies. The pattern was consistent: a technician would start in Cisco Meraki to check network health, switch to a vendor-specific portal to troubleshoot an access point, open a spreadsheet to cross-reference the deployment map, then call a colleague to confirm the physical layout of the site.

Four tools, three context switches, one troubleshooting task.

When I asked what frustrated them most, nobody mentioned missing features. Every complaint was about fragmentation:

The tools weren't bad individually. They were bad together — and no single solution covered the scope, so MSPs were forced to use all of them.

I audited three dominant tools MSPs were using - Cisco Meraki, Ubiquiti UniFi, and SolarWinds. I ran identical tasks in each: deploy an access point, diagnose a connectivity issue, generate a client report.

The pattern: tools designed for technical completeness, not for the task an MSP actually performs repeatedly. Every vendor assumed their hardware was the only hardware in the building.

The core architectural bet: instead of building another vendor-specific portal, build a layer that sits above any vendor's hardware. Cisco, Ubiquiti, TP-Link - all managed from the same interface.

I mapped which controls MSPs used daily vs. monthly from shadowing. Daily-use actions: primary dashboard. Monthly actions: advanced panel, accessible but not visible by default.

The pushback from engineering was real: "Every vendor's API is different. Unifying them adds months." I worked with the lead engineer to identify the 12 operations that covered 90% of daily MSP tasks and proposed we unify only those, leaving edge cases in vendor-native tools. That scope reduction cut the timeline from 8 months to 4 for the core dashboard.

Traditional AP deployment was guesswork. MSPs would estimate coverage based on floor plans, deploy, then walk the building with a signal tester and move things around. One technician described it as "hang it on the ceiling and pray."

We leveraged iOS LiDAR to let MSPs scan rooms and buildings, creating a 3D spatial model that accounts for wall materials - brick, concrete, glass - and their impact on signal propagation. The system then recommends optimal AP placement before a single device is mounted.

I designed the scanning flow to take under 2 minutes per room. The key UX challenge: LiDAR scanning is inherently spatial and unfamiliar. I tested three approaches:

• Free-form scan (point and move): 4 of 6 testers missed corners and produced incomplete models
• Guided path (follow on-screen arrows): All 6 completed successfully, but 3 called it "tedious"
• Room-by-room with preview (scan one room, see the model, continue): All 6 completed, 5 preferred it. The preview step gave confidence without adding friction

The room-by-room approach shipped. Post-launch, technicians reported cutting site surveys from 2+ hours to 20 minutes.

My first wireframe proposal for the dashboard was rejected outright in design review. I'd organised it by function (monitoring, deployment, alerts, reports) - a logical grouping that ignored how MSPs actually work.

MSPs don't think in functions. They think in sites. "What's happening at the downtown office?" not "Show me all alerts across all locations."

After the rejection, I restructured around a site-first hierarchy: select location, see health overview, drill into specific issues. The senior PM's feedback was direct: "Stop designing for the system. Design for the person standing in the building."

That restructuring took two weeks and one more round of testing with 4 MSP engineers. Three tasks that previously took 6+ clicks completed in 2. The site-first model held.

What I'd do differently: I should have shadowed before wireframing, not after. The rejection was avoidable. The insight - that MSPs think spatially, not functionally - would have been obvious during observation. I designed from assumptions because I was eager to show progress. That's a mistake I haven't repeated.

This was an 18-month project with a team of 20+ engineers and 3 PMs. My role was different from my other case studies - I was one of several voices shaping the product, not leading it end-to-end.

That constraint taught me something about influence without authority. Two examples:

The alert system. Engineering wanted to surface every system event as a notification. I argued for a severity-based filter: critical alerts interrupt, warnings appear in a feed, informational events log silently. I prototyped both and tested with 3 MSPs. The filtered version: zero missed critical alerts. The unfiltered version: 2 of 3 MSPs missed a critical alert buried in noise. The data made the decision.

Mobile-first dashboard. The initial spec was desktop-only. I pushed for a mobile companion based on my shadowing - MSPs troubleshoot on-site, standing in server rooms, not sitting at desks. I built a mobile prototype focused on three actions: check site health, acknowledge alerts, view AP status. The PM greenlit it after seeing a technician try to use the desktop dashboard on his phone during a site visit.

I didn't test with enough MSP sizes. Our partner companies were mid-market (50–200 clients). Enterprise MSPs managing 500+ clients had different workflows I didn't account for - bulk operations, delegation across team members, SLA-based alert priorities. The product worked well for our test group but needed significant iteration for larger operators.

The onboarding flow assumed technical confidence. MSPs are technical, but not every MSP team member is. Junior technicians needed more scaffolding than I'd designed. Post-launch, we added inline tooltips and a guided first-deployment walkthrough based on support ticket patterns.