Fiber Network Design Software: Why a Take Rate Change Should Not Mean Redrawing the Build

Why fiber design breaks the moment an assumption changes

Cost per passing is the number the whole business case rests on, and it is the output of a design that took weeks. So when the board asks what happens if the take rate lands at thirty percent instead of forty five, or if the state programme requires a different set of eligible locations, or if the pole owner comes back with a make ready estimate three times the assumption, the honest answer from engineering is that they need two weeks and a designer.

That is not a competence problem. It is a representation problem. The design exists as drawings: a set of CAD layers with routes, a GIS layer with cabinet locations, a spreadsheet that sums footage against unit costs, and a designer who knows why the route jogs around the block on Fourth Street. Drawings do not recalculate. Change one input and everything downstream is manual again, so nobody explores alternatives, and the design that gets built is the first one that closed rather than the best one available.

The money at stake is not subtle. Across a build of any size, splitter placement strategy, cabinet siting and the choice between aerial and underground on marginal spans move cost per passing by a meaningful margin, and cost per passing multiplied by the passing count is the largest number in the business case. Design rework once construction has started is worse again, because now you are paying for redesign plus mobilised crews plus permits that referenced the old alignment.

Problem 1: the design is a drawing, so nothing recalculates

The core issue is that a fibre design is fundamentally a graph problem with constraints, and it is being stored as geometry. Routes along a street network, splitter locations serving a set of premises, a loss budget along each path, cable sizing determined by the count downstream, cabinet capacity, and the physical cost of getting from A to B by each available method. Every one of those is computable. None of it is computable from a DWG file.

Comsof Fiber and Biarri both attack exactly this and they are genuinely good at automated design. IQGeo, 3-GIS and VETRO are strong network records and field systems rather than optimisation engines. Bentley OpenComms sits in the CAD lineage. The reason operators still end up building something is rarely that the optimisation is bad. It is that the rules are theirs: their split architecture, their preference for distributed splitting in low density areas and centralised in multi dwelling clusters, their standard cabinet, their reach limit conventions, their rules about which streets are politically impossible to trench.

What a custom build does: model the design as data and the rules as configuration. Premises come from your location source, the street and plant network is a routable graph, and the engine places splitters and cabinets subject to your loss budget, your split ratios, your capacity limits and your cost model. The output is a design that can be regenerated. Then a take rate change is a re run, not a redraw, and the engineering team spends its time comparing three scenarios instead of producing one. That shift, from producing designs to evaluating them, is the entire return on this project.

Problem 2: your cost model is a national average and your build is not

Most cost models in this industry are a table of unit rates: so much per foot of aerial, so much per foot of directional bore, so much per pole for make ready, so much per splice. Those rates came from somewhere, usually a mix of last year's contractor pricing and industry rules of thumb, and they are applied uniformly across a build area where the reality varies block by block.

The variance is not noise. Rock changes boring cost. A state highway crossing needs a permit and a bore under the road. Railroad crossings carry their own agreement, their own fee and their own timeline that can exceed the rest of the build. Downtown cores have restoration requirements that dominate the trenching cost. A pole route through an area with heavy existing attachments carries make ready that can exceed the fibre cost on that span. A uniform unit rate hides all of it, so the design optimiser, if you have one, is optimising against a fiction.

What a custom build does: make cost spatial. Unit rates vary by surface type, jurisdiction, soil and known constraint layers, sourced from your own completed jobs rather than from a benchmark. Crossings become discrete cost and schedule objects rather than footage. Make ready is estimated per pole from the attachment data you have and refined as surveys come back. The design engine then compares an aerial route against an underground alternative with numbers that reflect where the route actually goes. Operators who run this find alignments that a uniform model would never surface, usually by accepting a longer route to avoid a single expensive crossing.

Problem 3: the design does not know what is already in the ground

Existing conduit, spare innerduct, dark strands on an adjacent route, a cabinet with spare ports two blocks away, a previous build's handholes: all of that is reusable and all of it is worth real money. In most operators it lives in an inventory system that the design process consults informally, by a designer who happens to know, if they happen to remember.

This gets much worse after an acquisition, because the acquired network's records use different conventions and nobody trusts them. So the default is to design as if the ground is empty, which is safe and expensive. We have seen builds specify new conduit along a corridor where spare duct already existed, discovered afterwards during construction, at which point the money is spent.

What a custom build does: treat existing plant as an input layer to the optimiser with a reuse cost rather than a build cost, so the engine prefers it automatically wherever it is genuinely available. Availability has to account for encumbrances, since strands committed under a long term agreement are not free even if they look unused. Where record confidence is low, the design should mark a reuse assumption for field verification instead of either trusting it blindly or ignoring it. That verification queue turns out to be one of the more valuable artefacts the system produces, because it directs survey effort at the places where the money is.

Problem 4: the design has to become construction and usually does not

A design that cannot be handed to a crew is an academic exercise. What construction needs is different from what an optimiser produces: permit drawings in the format each jurisdiction accepts, a bill of materials that matches the part numbers your warehouse actually stocks, splice schedules, work packets scoped to a crew week, and the pole application data in the format the pole owner's process demands.

The gap between design output and buildable packet is where most fibre programmes lose their schedule. A designer exports something, a drafter reformats it, someone else builds the material list in a spreadsheet against a catalogue that has changed, and each handoff introduces errors that surface as a crew standing on a street corner with the wrong cable.

What a custom build does: generate the construction artefacts from the same model, so the bill of materials is derived from the design rather than transcribed, splice schedules fall out of the connectivity model, and work packets are cut geographically with dependencies respected. As built information then comes back against the same objects, which is what keeps the inventory system honest and is the difference between records that stay accurate and records that decay from the day construction starts. Federal and state funded builds add reporting obligations against defined location data, and generating that from the model rather than assembling it separately is worth the effort on its own.

What a fiber planning build costs and how long it takes

From Digital Heroes delivery experience, a first release covering the routing and splitter placement engine with your architecture rules, your spatial cost model and scenario comparison runs $95,000 to $210,000 and ships in 14 to 20 weeks. A full platform adding permit and easement constraint handling, existing plant reuse, bill of materials and construction packet generation, pole application output and as built reconciliation runs $260,000 to $600,000 phased over 9 to 15 months.

What drives cost up on this specific build: the quality of your street and parcel data, because a routable network graph is only as good as its source and cleaning municipal centreline data is real work. The number of architectures you support, since centralised and distributed splitting with different reach conventions are two engines rather than one option. Aerial, if make ready and pole data have to be modelled properly rather than as a per pole allowance. Multiple jurisdictions with different permit formats. And the optimisation itself if your build areas are large, because a design covering tens of thousands of premises needs the problem decomposed sensibly rather than thrown at a solver whole.

What keeps cost down: starting with one architecture and one representative build area, and adding the construction output layer in phase two once the design engine is trusted.

When Comsof, Biarri, IQGeo or 3-GIS is the right answer

Buy, or engage as a service, if your volume is modest or your architecture is conventional. Comsof Fiber and Biarri Networks do automated design well and can be bought as software or as a design engagement, which for a single market build is almost always faster and cheaper than building anything. 3-GIS, IQGeo and VETRO FiberMap are the right answer for network records and field operations, and a custom design engine should feed them rather than replace them.

Our position on when to build: when two or more of these are true. You design continuously at scale rather than in one campaign. Your architecture rules differ enough from the standard patterns that configuring a product means fighting it. Your cost model needs to be spatial and derived from your own completed jobs. You have substantial existing plant whose reuse materially changes designs. Or your design output has to flow into construction and inventory systems you already run, in formats those systems define.

The tipping point is not design quality, since the commercial engines are good. It is control and iteration speed. When the business case is rebuilt monthly against changing funding rules and take rate assumptions, owning the engine means answering in an afternoon. Renting it means booking a service engagement each time, and after enough of those the arithmetic changes.

How to choose a developer for fiber design software

Ask them how they would represent the design. The right answer is a graph over a routable network with premises as demand points, splitters and cabinets as facilities with capacity, and a loss budget as a path constraint. Anyone who starts with map rendering has understood the visible part and missed the problem.

Ask how the optimiser handles a build area with fifty thousand premises. A developer who has done this will talk about decomposition, clustering and solving in tractable pieces with sensible boundaries, and will be honest that a globally optimal answer is not the goal. Someone who promises optimality across a whole city has not run one.

Ask what construction output they have produced. Bills of materials against a real catalogue, splice schedules, permit drawing formats for a named jurisdiction and pole applications are all specific work. The gap between a design and a buildable packet is where programmes slip, and a developer who has crossed it will say so unprompted.

Ask who owns the code, the repository and the infrastructure, in writing, before kickoff. At Digital Heroes it is yours from the first commit. A good way to test any developer or product before committing: hand them one completed build area where you know the real as built cost, and ask them to reproduce the design and the cost within a sensible margin. If the engine cannot match a build you have already paid for, it will not be trusted on the next one.