Launching a fiber network is really two businesses starting at once. One is a construction project: permits, fiber in the ground, electronics lit up, a network that physically works. The other is a software business you didn't necessarily plan on running: taking orders, scheduling installs, billing subscribers, keeping the lights on when something breaks. Most new operators have a plan for the first one. Fewer have a real plan for the second, and that's usually where the first 12 months get harder than they needed to be.
Why the business side catches new operators off guard
If you're building a network from scratch, you're probably not hiring a NOC team, a helpdesk, and a billing department before you've passed a single home. You don't have the volume to justify it yet, and you don't have the runway to wait until you do. But subscribers don't care that you're a startup. They expect an order to go through, an install to show up on time, and a bill that's actually correct. Every one of those expectations exists from day one, whether or not you've built the systems to meet them.
The six stages you're actually running, whether you've mapped them or not
Every fiber launch, regardless of size, moves through the same six stages. Naming them helps you see where the gaps actually are.
| Stage | The question you're answering | Where it usually breaks for a new operator |
|---|---|---|
| Plan | Where can we actually build, and in what order? | Coverage and serviceable-address data lives in spreadsheets, not systems |
| Build | Is the network physically ready? | No clean way to know construction status without calling the field crew |
| Sell | Can we take an order here yet? | Sales promises addresses that aren't actually ready |
| Install | Can we get a technician there on schedule? | Scheduling is manual, dispatch is a phone tree |
| Activate | Is the connection live and billing correctly? | Billing starts on a status flag, not confirmed service |
| Run | Who handles it when something breaks? | No helpdesk yet, so it lands on whoever's closest |
GIS Mapping for Fiber Network Planning goes deep on the Plan stage specifically, serviceable-address data, coverage mapping, and sequencing your build. What Is OSS and BSS in Fiber Network Operations? covers the Sell-through-Run handoffs in more detail if you want the fuller picture of where those systems typically fail to talk to each other.
What this looks like when a small team does it well
Ripple Fiber is the clearest example. It started as a 13-person team with a mandate to build fiber and none of the operational infrastructure that goes with it, no NOC, no helpdesk, no billing platform, no carrier network of its own. Rather than building each of those functions from scratch before their first subscriber, they ran their operations on AEX from day one. Ripple is now a 10-state operator passing more than 250,000 homes, doubling both its footprint and its customer base year on year. The lesson isn't that AEX did the work for them, it's that they didn't have to choose between launching fast and launching with real operational systems in place.
Funding timelines matter here too
A lot of new builds right now are BEAD-funded, which comes with its own reporting and readiness requirements on top of the usual construction timeline. If that's your situation, BEAD Funding and Operational Readiness for Greenfield Fiber walks through what funders actually expect to see before and after you're live, separate from the general launch questions covered here.
Why one connected platform matters more at launch than at scale
An established operator can absorb some disconnection between systems, a manual reconciliation step here, a spreadsheet there. A new operator usually can't. There isn't spare headcount to catch the gap between a closed sale and a scheduled install, or between a completed install and a bill going out correctly. That's the actual argument for running planning, sales, field execution, and support on a connected platform from the start rather than stitching together point tools as you grow into needing them.
Practically, that split falls across three areas: AEX Software covers planning, sales, provisioning, and monitoring, the traditional OSS/BSS ground. AEX Field Service covers scheduling and installation. AEX Network Services covers the physical build and day-to-day network operations. Pricing is per subscriber, so the cost scales with your revenue ramp rather than showing up as a fixed cost before you've passed a single home, which matters more at launch than at any later stage.
What to actually plan for, stage by stage
Plan:
Get your serviceable-address and coverage data into a system you can act on, not just a map you look at. This is what determines build sequencing and what sales can actually promise.
Build:
Track construction status somewhere your sales and support teams can see it, not just somewhere your field crew can see it. The gap between "built" and "known to be built" is where false promises to customers start.
Sell:
Don't let an order get approved against an address that isn't confirmed ready. This single check prevents most of the install-day failures that damage trust with a brand-new subscriber base.
Install:
Scheduling and dispatch need to work before you have the volume to justify a dedicated dispatcher. A small team doing this manually will hit a ceiling fast.
Activate:
Billing should start on confirmed connectivity, not on an upstream status flag. Getting this wrong early creates billing disputes that are disproportionately damaging when you're still building trust in a new market.
Run:
Decide who handles a support ticket before you get your first one. Even a lightweight helpdesk process beats "whoever answers the phone."
Frequently asked questions
What do you actually need to launch a fiber network?
Beyond the physical build, you need a way to manage serviceable-address data, take and fulfill orders, schedule installs, and bill subscribers correctly from day one. New operators often assume they can add these systems later, but subscriber expectations start on day one regardless of what's actually in place behind the scenes.
How long does it take to launch a fiber network from planning to first subscriber?
It varies heavily by market size, permitting timelines, and funding source, but the operational side, getting order-to-activation workflows working, can be running in parallel with construction rather than waiting until the network is built. Waiting until construction finishes to start on the business side is one of the more common causes of a slow first few months.
Can a small team launch and run a fiber network without a big operations staff?
Yes, but it depends on how much of the order-to-activation workflow is connected versus manual. Ripple Fiber launched and scaled to a 10-state operator with a 13-person founding team by running planning, sales, field service, and support on one connected platform rather than staffing separate functions for each.
What's the difference between building the network and running the business side of it?
Building the network is the physical work, fiber in the ground, electronics lit, backhaul connected. Running the business side is everything a subscriber actually interacts with, taking their order, scheduling their install, billing them correctly, and supporting them afterward. Both have to work from day one, even though only one of them is visible from the street.
Do we need separate software for planning, billing, and field service, or can one platform cover all of it?
You can run separate point tools for each, but every handoff between them is a place where a delay or manual error can happen. A connected platform that covers planning, sales, provisioning, field execution, and support reduces the number of places where something has to be manually reconciled, which matters most when you don't have spare headcount to catch it.
How does BEAD funding affect the launch timeline?
BEAD-funded builds come with reporting and readiness requirements on top of standard construction and activation work. It doesn't change the six stages themselves, but it adds documentation obligations at several of them, particularly around build status and service activation, worth planning for separately from the general launch timeline.
