NexusPort

Overview

Currently referred to as NexusPort — a working name, not final branding — this is an independently developed product for bandwidth scheduling and telecom workflow automation. I build it after hours, on my own time and resources, as a commercial product exploration: take a class of network workflow that tends to be manual, repetitive, and timing-sensitive, then turn it into a structured product experience with real guardrails. Final product naming and business structure are still being finalized.

It sits squarely in the kind of work I enjoy most — software architecture and network automation meeting real operational pain. The product architecture is original, built from public documentation, public and general technical knowledge, standard software libraries, and authorized API integrations where applicable. This page describes the product direction and the engineering behind it. NexusPort is an evolving commercial product exploration rather than a finished, mature SaaS.

The problem

Port-level service changes — bumping bandwidth up for an event, scaling it back down afterward, activating or adjusting a service — sound small, but in practice they carry real friction:

• They’re recurring, so the same careful steps get repeated over and over.
• They need coordination, often across people, tickets, and maintenance windows.
• They’re timing-sensitive: a change applied at the wrong moment is as much of a problem as a change applied incorrectly.
• A mistyped value or a mistimed order can have outsized consequences.
• There’s frequently little visibility into what’s scheduled, what’s in flight, and what already happened.

The net effect is that routine work demands disproportionate attention, and operators carry quiet anxiety about getting it exactly right. That combination — repetitive, risky, low-visibility — is exactly the kind of workflow that benefits from being turned into software.

Product idea

The core idea is to separate intent from execution:

• An operator expresses what they want — this port, this bandwidth or service state, at this time.
• The system turns that intent into a planned, reviewable change rather than an immediate live action.
• Scheduling is a first-class part of the workflow, not an afterthought.
• Validation happens before anything is applied.
• State and status are visible throughout, so there’s always a clear answer to “what’s planned, what’s running, what’s done?”
• Integration with publicly documented developer platforms is treated as an implementation detail — the product is the workflow and the guardrails, not any single API.

That last point matters: the goal is a system that models the operator’s problem, and keeps integration-specific mechanics behind a clean boundary.

Architecture approach

The shape of the system follows from that separation of intent and execution. This is the design direction rather than a claim about a finished codebase:

• Modular app boundaries — distinct concerns for the UI, the domain logic, and the adapters that talk to publicly documented external APIs.
• A domain data model with ports, schedules, plans, and orders as first-class entities, so the system reasons about what should happen before how it happens.
• Integration-agnostic design — integration details live behind adapter boundaries, so the product isn’t welded to any single API surface.
• Validation before mutation — a request is checked while it’s still just a plan, before it can change anything live.
• Auditability — changes leave a trail, so there’s a record of who asked for what, when, and what the outcome was.
• Safe execution — applying a change is a deliberate, observable step, not a silent side effect.

I’ve written before about keeping clear boundaries while moving fast in AI-assisted development without losing architecture; the same instinct drives NexusPort’s structure.

Operator workflow

The intended workflow reads like the operator’s own mental model. This is the current design direction — some of it is built, some is still being shaped:

1. Choose the customer and port to work on.
2. Specify the desired bandwidth or service state.
3. Schedule the change for the right window.
4. Validate the request while it’s still a plan.
5. Queue and execute through the API integration.
6. Track status as the change moves from planned to in-flight to complete.
7. Audit the outcome against what was requested.

Framing it as a sequence of reviewable steps is deliberate: each stage is a place to catch a mistake before it becomes a live problem.

Safety and validation

For a system designed to change network services, safety isn’t a feature bolted on at the end — it’s the point. The design leans on a few principles:

• Explicit confirmation before anything touches a live service.
• Clear review screens so a planned change is easy to read and sanity-check.
• Validation as a gate, not a suggestion — invalid plans don’t get to run.
• Audit logs that record intent, action, and outcome.
• Idempotency as a design goal, so retries and re-runs don’t compound mistakes.
• Graceful failure handling, so a failed change is visible and recoverable rather than ambiguous.
• No silent automation — the system should never quietly do something the operator can’t see or didn’t intend.

Technical themes

A note on scope: this portfolio page is only the presentation of the product. The product architecture and implementation live outside this Astro repo.

The engineering themes the project exercises:

Theme	Why it matters here
Product engineering (TypeScript / Laravel-style)	Modeling a real operational domain as durable software
API integration	Talking to publicly documented APIs behind clean adapter boundaries
Workflow & scheduling	Turning timing-sensitive steps into first-class, reviewable state
Observability & auditability	Always being able to answer “what happened, and why?”
Secure credential handling	API secrets stay out of the product surface and out of this repo
Operator UX	Designing for confidence, not just capability

What I learned

A few things this project keeps reinforcing:

• Product automation is as much about guardrails as it is about API calls — the calls are the easy part.
• Operator trust is a real design requirement. People won’t lean on a system that can surprise them.
• Naming states clearly is architecture. “Planned,” “scheduled,” “in-flight,” “done,” “failed” aren’t just labels — they shape the whole system.
• Provider-specific details should not leak everywhere; keeping them behind a boundary keeps the product coherent.
• Good workflow design reduces both errors and anxiety — and the second one is easy to underrate.

What’s next

Honest, aspirational next steps — directional, not promises:

• A deeper customer and port onboarding model.
• A stronger plan/review UI for reading a change at a glance.
• Hardening the integration adapter layer.
• Notification workflows around scheduled and completed changes.
• A richer audit trail.
• Eventually, billing/pricing integration where it fits the workflow.
• Case-study screenshots and deeper documentation as the build matures.

If this problem space is close to something you’re working on — or you just want to compare notes on operator-focused automation — I’d genuinely like to talk. You can see the engineering background across the work, or reach out to Brandon directly and get in touch.

Project note

NexusPort is an independently developed product by Brandon Donaly / Pakkit, and “NexusPort” is a working name rather than final branding — final product naming and business structure are still being finalized. It is built from original architecture, public documentation, standard software libraries, and authorized API integrations where applicable. The project is not affiliated with or endorsed by any employer, vendor, or service provider referenced in the surrounding technical domain.

Related writing

If you want the philosophy behind this kind of build, read Building Weird Ideas Into Real Systems. For the AI-assisted workflow behind this site and similar architecture work, read AI-Assisted Development Without Losing the Architecture.