Operations dashboard

DeviceOps Command Center

A service-operations dashboard bringing IT assets, vendor contracts, backup checks, and service performance into one view instead of six spreadsheets.

Overview

Operational work often lives across spreadsheets, tickets, emails, vendor portals, and manager memory. The problem this set out to solve was making that work visible without becoming another noisy admin tool.

The dashboard centres on operational state: assets, vendors, audits, backups, service performance, and review-ready notes.

This is a concept build, and its data is modelled rather than real. It grew out of Philip’s day-to-day IT management work at DeviceBytes and earlier at uBreakiFix, but it is not a deployed system running a business, and none of the figures in it describe actual operations. It is included here because the domain modelling and the dashboard structure are the transferable part — not because it has production users.

Source code and a live demo are both public, linked above.

Status: Self-directed concept build — modelled data, not a live client system
Built for: Operations managers tracking assets, vendors, audits, and service performance
Role: Product strategy, dashboard UX, API design, operations modeling
Timeline: 4 week concept build
Platforms: Web
Categories: Operations Platforms, Customer Portals

The DeviceOps Command Center operations overview dashboard

What was built

Responsibilities and core features

Responsibilities

Modelling the operational domain: assets, contracts, vendors, recovery procedures, and KPI history
React dashboard with overview, assets, vendor, audit, backup, and KPI modules
Node API organised around operational records, audit checks, and service metrics
Containerised local development and hosted deployment

Core features

Operations overview of assets, active vendors, service queues, and exception states
Audit controls covering security, backup, and recovery checks
KPI review grouping operational performance and partner reporting signals
Vendor and contract records modelled alongside the audits that reference them

Screens

The overview leads with exception states rather than with totals.

Engineering

Problems that came up, and what fixed them

The specifics matter more than the feature list. This is what the work actually consisted of.

Designing for exceptions rather than for totals
An operations dashboard that leads with totals tells a manager nothing actionable. The overview is built around exception states and next actions — what is overdue, what failed a check, what is queued — with aggregate figures kept secondary.
Modelling vendors and audits together
Vendor records and audit checks were modelled as one connected domain rather than as separate modules, because the real decisions combine them: whether a contract is worth renewing depends on the audit and service history attached to it.

Technical architecture

React dashboard with overview, assets, vendor, audit, backup, and KPI modules
Node API organised around operational records, audit checks, and service metrics
Postgres schema for assets, contracts, vendors, recovery procedures, and KPI history
Docker and Vercel deployment model for repeatable local development and hosting

Technology stack

React
Node.js
PostgreSQL
Docker
Vercel

What it adds up to

Nine dashboard views spanning assets, vendors, audits, backups, and KPIs
Six audit areas modelled around practical IT-management responsibilities
Postgres schema covering assets, contracts, vendors, recovery procedures, and KPI history

Related services