Three non-negotiables Ian stated:
Full CRUD for ports, schedules, monitoring. CORS-enabled. Runs at localhost:8765.
Thin wrapper around the API. Handles auth, retries, error types. env-configurable.
Covers ports, schedules, and monitoring endpoints. Uses freezegun + respx.
Chart.js bandwidth graph, circuit state machine (BASE/BURST), 8-direction window manager, layout persistence.
Realistic-looking sine-wave traffic — but it's fake. No real network packets are being read.
The client SDK targets real Lumen endpoints but there are no real credentials or production API calls yet.
No Docker setup exists. Ian described this as the deployment model — nothing is packaged yet.
Ian said he'd bring reports to Dana at Lumen. No export or reporting feature exists in the dashboard.
Ian's entire security answer is "I put this in a container." This needs to exist before you put anything in front of a real client. A Dockerfile + docker-compose that packages the monitoring agent so it runs fully self-contained on the client's network — no inbound ports, no external calls except to the Lumen API. This is the trust story.
The dashboard currently shows simulated sine-wave traffic. For a real deployment the agent needs to read actual bandwidth — either via SNMP polling of the client's router/switch, or by calling the Lumen NaaS port metrics endpoint directly. SNMP is the easiest path for small clients (Stephen Hainline runs standard gear). The monitoring loop that reads real numbers and calls the Lumen API to burst/scale is the core product.
Ian explicitly said in the May 15 meeting: "The dashboard that I showed you in testing is just a test dashboard. The end result, I want it to look something more like this." The current dashboard works but uses placeholder styling. Before any client-facing demo, it needs ITG Group branding, a cleaner color palette, and a layout that communicates value at a glance — not a developer test harness.
The client SDK has the interface right (base_url, api_key, account_id) but it's pointing at localhost:8765. Someone needs to get real Lumen NaaS API credentials from Dana or the partner portal, confirm the actual endpoint URLs, and wire up the SDK's ENV file. This is likely easier than it sounds — the architecture already supports it with a one-line .env change.
The client SDK can already call the Lumen API to change port speed. What doesn't exist yet is a persistent agent loop that watches the traffic monitor and automatically fires a burst or scale-down when thresholds are crossed — the "set it and forget it" piece Ian described. This is what turns the demo into a real product. Shouldn't take long; it's essentially a while-loop around existing SDK calls with the circuit state machine from the dashboard.
Ian described showing Dana at Lumen "how it's working, how it's reacting, the test audits we're doing." The dashboard needs a "Download Report" button that generates a PDF or clean HTML showing: bandwidth over time, number of auto-scaling events, estimated cost savings vs. always-on peak bandwidth, and uptime. This is the proof that gets handed to Lumen and justifies the partnership.
Ian said setup takes 10 minutes. That should literally be true: a single script a client's IT person can run to pull the Docker image, enter their Lumen credentials and SNMP community string, and have the container running. Right now you'd need to clone a repo, set up Python, understand the project structure. That's a hard ask for a non-technical contact.
The dashboard has no authentication. For clients who expose it on their LAN, anyone on the network can see it. A simple token or password in the .env file is enough — this isn't meant to be internet-facing, but some IT directors will ask about it, and the answer can't be "it's open."
Stephen Hainline is one site. Thomas Germaine and Moda Partners have multiple locations. The current architecture assumes one NaaS port. To scale to larger clients, the dashboard and monitoring agent need to handle multiple port IDs / sites from a single deployment.
One-page "what this is" doc for the client contact, a setup guide for their IT team, and a short FAQ covering the most common security questions (who has access, what data leaves the building, etc.). Ian already has the pitch deck. This is the ops support material that goes with it.
Dana at Lumen has been asking for exactly this. Ian said: "position this tool as a solution for the scheduling tool that Dana keeps referring to and talking about." Dana is already pre-sold on the need. Go to her first with the proof-of-concept data, not a pitch. You're bringing her the solution she's been asking for — that's a completely different conversation than selling to a cold contact.
Lumen engineers will want to know how it works. Lumen managers care about what it does for sales. Bring both. The report from the Phase 1–3 clients gives you real numbers: hours of automated scaling, bandwidth utilization improvement, estimated dollars saved. Those numbers become Lumen's value story when pitching NaaS to enterprise customers.
The one-sentence pitch Ian defined: "Every time you make a NaaS sale, ITG Group can come in and do this for that client for you and add value to this sale for you." Lumen doesn't buy it, doesn't manage it, doesn't support it. They just include ITG in the conversation when a NaaS client would benefit. ITG handles everything after the handoff.
Ian's caution: "Don't rely on the assumption that managers will communicate these opportunities among themselves." Go direct to the reps in your territory — Aerial Neal in Kent is already identified. Use the existing Lumen Rep Outreach Playbook. Same pitch: "we do the demo work, you get the contract numbers." Each rep is a channel into their book of NaaS clients.
Every IT director at every enterprise will ask: "does ITG see our traffic?" The answer is a crisp no — and you need to be able to say it without hesitation: "The tool runs in a self-contained container on your network. No data leaves your building except the API call to Lumen's own infrastructure to change your port speed. ITG Group has zero visibility into your traffic." That answer needs to be in every pitch and every piece of documentation.