INVESTMENT BRIEF PORT53 // PRODUCT
State of
the Stack
The foundation behind our SOC — what we've built, how solid it is, and the plan to grow it into the platform that powers both traditional SOC and SOC for AI.
Port53 · Confidential · Product & Engineering audit & plan01 / 15
TL;DR If you remember three things
The short
version.
01
We've built a real platform
A modern customer-facing product and an internal engine that runs our SOC / MXDR service today. Serious software, built by a tiny team.
02
The foundation is strong, but uneven
The flagship is excellent. Eric's engine runs the live service today — built lean, it now needs hardening to carry our biggest bet.
03
Invest now — harden it, then build on top
Strengthen the foundation and the team, keep advancing traditional SOC, and add SOC for AI as the next chapter — deliberately, not on a script.
The ask in one line: fund the foundation, resource the team, build the asset.02 / 15
THE MAP Plain English
What we
run today.
PLATFORMCustomer-facing
The product customers log into
A web platform plus iOS & Android apps. Where customers see their security alerts, scores, quotes, and contracts.
port53 · webiOS appAndroid app
PHOENIXInternal engine → the asset
The machine that runs the service
Connects Cisco XDR to our SOC's tickets and reporting. It powers our SOC today — and it's the foundation every future SOC offering builds on.
phoenix-controllerphoenix-flightCisco XDR ↔ Jira
CUSTOMER → PLATFORM → SHARED SOC DATA → PHOENIX → CISCO XDR + SOC TICKETS
Two products. One mission: detect & respond, then show the customer.03 / 15
THE ROSTER Five active systems · graded honestly
The five
systems.
System
What it does
Health
Status
port53
Rails web platform + the hub everything connects through
A−
Active
android-platform
Android app — tested, actively shipping, cleanly built
B+
Active
ios-platform
iOS app — built first; excellent UX & Hotwire craft. Tests + env split = clear path to A
C+ ↗
Catching up
phoenix-flight
Internal SOC portal, CRM & customer reporting
C+
Active
phoenix-controller
The live Cisco XDR ↔ Jira engine — the foundation everything builds on
C
Active
Grades reflect maturity & risk — never effort, talent, or vision. The goal: bring every row up to the flagship.04 / 15
THE WIN ▰ This is what good looks like
The flagship
is excellent.
The customer platform (platform.port53) is a genuinely modern, well-built codebase — the reference every other system should be measured against.
- ✓ Current framework, clean architecture, real automated testing & security tooling
- ✓ Encrypted secrets, sound customer-data isolation between tenants
- ✓ The hub the whole business — and every future SOC console — runs through
1
The bar to raise everything to
We're not starting from zero — we're raising the rest of the stack to a standard we've already proven.05 / 15
THE ORIGIN Eric's vision, running live
The engine that
runs the service
is a prototype.
From a vision, Eric built Phoenix into the live system that delivers our MXDR service — while running the entire SOC at the same time. On a team this lean, that it works at all is the achievement.
- ✓ Vision → a real service that detects, responds, and earns revenue today
- ✓ Wires Cisco XDR into our SOC and keeps customers covered, every day
- → Built fast & lean — productionizing it is simply the natural next chapter
4
Files run the whole live service
Live
Delivering MXDR revenue today
Next
Productionize & scale it
Eric got us here. Now we invest to take it further.06 / 15
THE DIRECTION An additional bet — not a pivot
Phoenix powers SOC —
and now SOC for AI.
CORE · ONGOINGTraditional SOC / MXDR — Cisco XDR detection & response for our customers. This stays central and keeps advancing — SOC for AI is built on top of it, not instead of it.
Additional · Rung 01
SOC for
AI Usage
See & control how AI tools are used across the org — detect & respond to risky AI usage.
Additional · Rung 02
SOC for
AI Apps
Protect the AI apps we build & ship — kill switches, copilot offline, key rotation as response.
Additional · Rung 03
SOC for
AI Agents
Govern autonomous agents — contain, pause, terminate, roll back. The category nobody owns yet.
Phoenix is the asset: one platform behind every SOC offering we sell. That's what makes us a platform company, not just a services firm.
A direction, not a deadline — each rung reuses the same Phoenix platform.07 / 15
THE BUILD A proposal received — the calls are mine to make
From a script
to a platform.
TODAYA few scripts
+ a portal
- 4-file XDR↔Jira batch job
- Django SOC portal
- Manual — no real backbone
- No tests, no monitoring
THE DIRECTIONA productionized,
event-driven platform
- Reliable, closer-to-real-time ingest
- Reusable detection & response
- Built for traditional SOC and AI
- Properly tested & monitored
Omar's brief proposes a detailed v1 architecture — event backbone, AI telemetry fabric, detection workbench, action surface, real-time gateway, LLM triage. My first deliverable is to pressure-test those calls — not assume v1 is final. I'll work closely with Eric to validate, sequence, and decide what we actually build.
A
Telemetry & data fabricnormalize signals from many sources
B
Event backbonereliable pipeline · tech TBD
C
Detection workbenchauthor & test detections
D
Action surfacesafe, reversible responses
E
Real-time gatewaylive console & dashboards
F
LLM-assisted triagemulti-provider, evaluated
Proposed building blocks (from the brief) — to validate, sequence, and decide.08 / 15
THE INVESTMENT Phoenix · the engine
Build the
engine.
Step 1 hardens what we run for traditional SOC today. The rest adds the new platform on top — sequenced after we've validated the architecture, not committed up front.
Investment
What it is
Why it matters
Productionize the engine first
Tests, idempotency, fix the corrupted file, structured logging, CI
Reliability for the SOC service we run today
Event-driven backbone PROPOSED
A reliable, closer-to-real-time pipeline — tech choice decided after evaluation
Move off fragile batch scripts
Telemetry & data fabric PROPOSED
Normalize signals into one schema + a catalog of sources
The data layer every detection builds on
Action surface PROPOSED
Versioned, reversible response actions with approval by risk
Safe response — for traditional SOC and AI
Detection workbench + triage PROPOSED
Author/test detections with quality gates; assisted triage
Ship quality detections faster
Security + SRE baseline
Fix portal config & secrets, retire stale branch, monitoring
Table stakes before anything customer-facing
Harden what exists; validate, then build the new layers on top.09 / 15
THE INVESTMENT Platform · the delivery surface
Deliver it to
the customer.
Investment
What it is
Why it matters
Real-time console
Live alert streams + dashboards for analysts and customers (today: batch reads)
A live view of risk — for traditional SOC and AI
New dashboards + data model
Extend the existing alert/issue/score model to new signal types
The product customers actually see
Mobile keeps pace
Surface new alerts in the apps — bring iOS up to standard first
Risk in your pocket, on both platforms
Scale hardening
Turn on alerts-webhook rate limiting, encrypt integration tokens
Holds up as alert volume grows
Resource the platform
Today one part-time engineer owns the entire customer surface
Our most valuable asset is under-staffed
The platform is already our strongest asset — and our thinnest-staffed.10 / 15
POSSIBLE SHAPE Illustrative — not a commitment
How it
could go.
Directional only. Real dates & scope get set after the architecture audit — we're not signing up to a calendar today.
Nearfirst
- Audit the brief & decide the architecture
- Harden the engine
- Lock the foundation
Nextafter
- Stand up the core platform pieces
- Early traditional-SOC wins
- Resource the team properly
Laterthen
- First production capabilities
- Internal AI detections (learning)
- Reusable response actions
Horizonbeyond
- Customer-facing SOC-for-AI pilots
- Design-partner feedback loop
- Expand from there
Risks
we name
Get it right vs fastRushing the architecture to hit a date is how you build the wrong thing twice
Action safetyNo response action ships without a tested rollback path
Talent flightThe senior platform team is the moat — retention is non-negotiable
A shape to react to — sequence first, dates later.11 / 15
THE TEAM Who builds this
A small team
carrying a lot.
Platform customer-facing
⚠ Our most valuable, customer-facing asset is run by one part-time engineer — the single thinnest point in the company.
Phoenix engineering
Suchithra
India · full-time
Pratibha
India · full-time
A lean team carrying the platform, the engine, and the next big bet.12 / 15
MOMENTUM Since I took over the team
Already
moving.
I took over the Phoenix dev team 2 months ago. The operating system changed fast — this is the same team, on a new footing.
01
Daily standups
Cadence, accountability, and daily unblocking — installed from day one.
02
Linear
Ticket management moved to Linear — real sprints, visibility, tracking.
03
PRD per project
Every project specced in a detailed PRD before a line of code.
04
5 playbooks shipped
Documented, repeatable SOC operations — not tribal knowledge.
05
Velocity up
Measurably more shipped per sprint under the new structure.
06
Dev management
Restructured ownership, process, and review across the whole team.
The foundation work is already underway — give me the runway and the team to go further.13 / 15
THE ASK What I need to do this right
The ask.
Fund the foundation. Resource the team. Make the right calls.
Resource
Platform
Real engineering capacity — it's run by one part-time engineer today
Harden
the engine
Productionize what runs the SOC service before we build on it
Runway
to decide
Time to audit the architecture & make the right calls before committing
Staff Platform beyond one part-time engineer
Add senior platform capacity for Phoenix
Protect time to pressure-test the architecture
Retain the senior engineers who are the moat
Scale comes from the platform — but only once it can bear the weight.14 / 15
PORT53 State of the Stack · 2026
Fund the
foundation.
Build the asset.
▸ Back the plan
Questions & deep-dive
Phoenix is Eric's vision — this plan scales it · Full technical audit on request · Confidential
Thank you — Kyle & the team15 / 15