CIO 360.
A monitoring, automation & SOAR platform — one operational view across an organization's security stack.
CIO 360 pulls a dozen disconnected security tools into one dashboard and orchestrates responses on top. I built the entire web application and the React Native Android client as their sole developer, and I own the REST API contracts the Laravel backend and native iOS app both build against.
- Role
- Sole web + Android developer · API contract owner
- Timeline
- Jan 2024 — Present
- Team
- Me + external backend & iOS team (3)
- Users
- CIOs, CISOs and MSPs
01 — The problem
The problem
Mid-size orgs run security across a dozen disconnected tools — Entra ID for identity, DefensX for browsers, Dropsuite for backup — each with its own dashboard and alert format. No one, least of all the CIO who answers for all of it, had a single operational view. CIO 360 gives CIOs and MSPs one place to monitor the whole stack and trigger automated responses from it.
02 — What I built
What I built
I joined as the only web developer — no frontend codebase, no component library, no API docs, and a backend being built in parallel by an external team. So the job was three things at once: build the entire React web app from an empty repo, design and document the REST API contracts both clients consume, and act as the technical interface between product and the external engineers.
Once the web app was live, I built the Android client in React Native to full feature parity with the web app — same flows, same contracts, same normalization. Business-logic and the API layer are shared across both clients, so a fix or a new feature lands in one place and reaches both.
03 — How it works
How it works
A React SPA, a React Native Android app and a native iOS app all talk to a Laravel REST API that aggregates the vendor integrations — relational data in MySQL, high-volume vendor payloads in MongoDB. Because three clients across two teams consume the same API, I treated the contract as a designed artifact: written and agreed before any side wrote code.
→Contract-first, not code-first
Every endpoint was specified — shape, errors, pagination — before implementation. When clients disagree about a field, the document decides, not whoever shipped first.
→Normalize at the contract
A dozen vendor feeds arrive in a dozen shapes. The contract defines one canonical shape per domain, so web, Android and iOS render identical data with zero vendor-specific logic.
→One response envelope
Every endpoint returns the same envelope with machine-readable error codes, so all three clients share one error-handling path instead of special-casing endpoints.
GET /api/v1/alerts?source=entra&severity=high
200 OK
{
"status": "ok",
"data": {
"items": [{
"id": "alrt_8f3a...",
"source": "entra_id", // canonical key, not vendor-raw
"severity": "high", // normalized scale across vendors
"occurred_at": "2025-11-04T09:21:00Z",
"actions": ["disable_user", "require_mfa"] // SOAR hooks
}],
"page": { "current": 1, "per_page": 25, "total": 214 }
},
"error": null
}
502 { "status": "error", "data": null,
"error": { "code": "SOURCE_UNAVAILABLE",
"source": "entra_id", "retryable": true } }One envelope, canonical field names across every vendor, and error codes clients branch on. "actions" is what wires detection to SOAR response.
04 — The hardest call
The hardest call
The sharpest trade-off was normalization. Vendor APIs disagree about everything — severity scales, timestamps, what even counts as an alert. Flattening them into one canonical shape means some vendor-specific richness is lost, but the payoff is clients that never contain vendor logic and one shared UI for every source. I kept raw payloads retrievable for the cases that genuinely need them. Building the UI against the agreed contract with local fixtures also meant integration became verification, not discovery — when reality diverged from the document, the divergence was visible and arguable.
If you only remember four things
- Sole developer of a production React web app and its React Native Android client — empty repos to live users.
- Full feature parity across web and Android, with shared business-logic and API layers.
- Contract-first API design consumed identically by three client platforms.
- On multi-client systems, the interface is the product — precision there pays daily.