ISP / Engineering
Previous chapter FeaturedDuvall WiFi
How a plan to get better internet to one house became an ISP, an infrastructure laboratory, and a broader engineering consultancy.
- ISP
- Network Engineering
- Software Engineering
- Cybersecurity
- Automation
- Infrastructure
- Managed Services
- Operations
What this proves
Proves I can carry a real infrastructure problem from idea through architecture, software, security, operations, billing, and support — then adapt when deployment constraints change.
Overview
Duvall WiFi started because one house needed better internet.
My then-partner’s house was about 3,200 feet from the nearest point where the incumbent provider was willing to build from. The quote I received was more than $40,000 in construction costs, followed by roughly $670 per month for at least six years, just to deliver a symmetric gigabit connection. That was an approximately $88,000 commitment for a problem that looked much less expensive when I priced the physical materials myself.
Instead of accepting that as unavoidable, I started investigating how wholesale bandwidth, last-mile transport, subscriber access, and community networks actually worked. That investigation became Duvall WiFi: first an attempt to build a local ISP, then a hands-on engineering consultancy that crossed networking, software, security, automation, hosting, and practical operations.
From August 2022 through November 2024, I owned the work end to end — discovery, architecture, implementation, production operations, sales, billing, and customer support. It was not a large agency with layers of departments. It was me taking responsibility for the complete system and the people depending on it.
The original ISP idea
The original idea was a community-owned transport network. Neighboring homes would connect to each other, share the cost of reaching a wholesale bandwidth handoff, and gain more choice than a single last-mile provider could offer.
The proposed model was deliberately practical:
- Start with wireless links so homes could connect without waiting for a complete fiber build.
- Combine multiple upstream connections for bandwidth and failover.
- Give every subscriber an isolated network rather than placing an entire neighborhood on one flat LAN.
- Purchase wholesale bandwidth once enough homes were connected to make the economics work.
- Add fiber later for much more capacity while retaining wireless as a backup path.
- Let the transport network carry more than internet access, including private connectivity and locally hosted services.
The initial rollout used MikroTik wireless equipment, including 60 GHz 802.11ad/ay links, alongside multiple upstream technologies. The larger architecture was designed to grow toward serving as many as 160 homes with symmetric gigabit service. The phase-two design called for six-core buried fiber, a 20 Gbps shared backbone, and room to increase backbone capacity later. That fiber design remained a planned second phase rather than a completed deployment.
The original planning and economics are still documented on the Duvall WiFi “How it works” page.
Building the ISP stack
An ISP is much more than radios and a fast upstream. Subscribers need to be identified, authorized, isolated, provisioned, monitored, billed, and supported. I built the systems around the network as well as the network itself.
- A Spring-based captive portal and custom FreeRADIUS integration provided account-backed authentication, authorization, and accounting.
- Subscriber networks were segmented so one customer’s devices were not exposed to another customer’s traffic.
- GenieACS and TR-069 supported remote provisioning and management of MikroTik customer-premises equipment and Yealink phones.
- Monitoring and operational tooling made device state and failures visible without waiting for a customer to report them.
- Multiple upstream paths and hub-and-spoke VPN connectivity supported resilient access across sites.
- PBX and CRM integrations connected the technical platform to the customer and support workflows around it.
This was one of the most valuable parts of the project: every new layer forced me to connect software design, network behavior, security boundaries, physical equipment, and human support into one operable system.
The constraint was not bandwidth
The network was technically possible. The harder problem was where the cable was legally and physically allowed to go.
The original house-to-house concept looked simple when drawn across cooperating private properties. In practice, a route eventually encounters roads, public rights-of-way, utility easements, poles, or parcels where a handshake between two neighbors is not sufficient permission.
Once that happens, installing fiber becomes a civil-infrastructure project. It can require a utility franchise, right-of-way construction permits, documented easements, inspections, traffic control, restoration work, and pole-attachment agreements. Wireless can avoid trenching across some of those boundaries, but it introduces its own line-of-sight, mounting, power, and coverage constraints.
That did not make the ISP design impossible. It changed the cost, timeline, and risk enough that I could not treat expansion as simply buying cable and connecting the next house.
It taught me something that now shapes how I approach every project: a technically valid system is not automatically a deployable system. Architecture has to account for physics, property, regulation, operations, economics, and the people who will maintain it.
From ISP to broader engineering work
Discovering those constraints did not end Duvall WiFi. It expanded what the business was for.
The same capabilities needed to operate an ISP translated naturally into residential and business technology work:
Networking and connectivity
- Wi-Fi, routing, switching, VLAN, structured-cabling, and point-to-point network design.
- Managed routers, multi-WAN failover, SD-WAN, VPNs, traffic policy, and monitoring.
- Resilient networks spanning multiple buildings or properties.
- Customer-premises equipment provisioning and lifecycle management.
Infrastructure and hosting
- VMware vSphere and vSAN hyperconverged infrastructure.
- Managed virtual machines, websites, application environments, backups, and monitoring.
- Private-cloud services and locally hosted network amenities.
- Infrastructure designed around redundancy, observability, and recoverability.
Software and integrations
- Spring and Laravel production services.
- Internal tools that removed repetitive operational work.
- Captive portals, account systems, APIs, and webhook integrations.
- PBX, SIP, CRM, and business-workflow integrations.
Security
- An air-gapped root certificate authority and practical PKI.
- Zero-trust segmentation and least-privilege access patterns.
- Edge filtering, SIEM monitoring, auditability, and secure remote access.
- Security designed to remain usable during normal operations.
Automation and custom systems
- Home and business automation built around the actual goal rather than a pile of gadgets.
- Device, environment, presence, energy, and infrastructure monitoring.
- Custom hardware and software integrations when off-the-shelf products stopped short of what the customer needed.
“WiFi” was the starting point, not the boundary. The real throughline was taking a messy technology problem that crossed several disciplines and turning it into one understandable, maintainable system.
What this project proves
Duvall WiFi gave me experience that is difficult to get from working inside only one layer of a larger organization.
I had to understand what a customer was really asking for, survey the physical environment, model the economics, choose equipment, design the network, write the software, secure it, deploy it, monitor it, invoice for it, answer the phone, and fix it when reality disagreed with the diagram.
That full ownership changed how I engineer:
- Product decisions include operational and support costs from the beginning.
- Security boundaries are designed with the network and application, not added after them.
- Automation exists to make a system easier to operate, not merely more clever.
- Documentation and observability are part of the deliverable.
- Constraints are investigated early, especially when software meets physical infrastructure.
- A system is not finished until another person can understand and operate it.
Where it carries forward
Duvall WiFi ended as a business chapter in 2024, but the engineering instincts behind it carry directly into my current independent work under Brandon Donaly / Pakkit: follow the problem across layers, build the smallest reliable path, make security part of the architecture, and leave behind something people can actually operate.
If you have a networking, software, infrastructure, security, or automation problem that does not fit neatly into one box, talk to me directly.
Related writing
Building Weird Ideas Into Real Systems explains the broader operating style, while Notes From a Private Cloud Gremlin covers the infrastructure judgment that grew alongside this work.
Where to next
Keep exploring
A few good next steps from here — a related build, some background reading, or a way to take it further together.