First cost is easy to compare. Three numbers, one is lowest, decision made.
It is also the wrong basis for a structure that will be attacked by moving water repeatedly for thirty years, because the number that governs is what the asset costs over its life.
What actually recurs
Erosion protection has a maintenance profile, and it differs sharply between systems:
Replenishment. Loose stone migrates during large events and gets topped up. This is a normal, accepted maintenance model for riprap and it is only a problem when the interval gets short.
Component repair. Wire baskets corrode and abrade; the structure’s life is governed by the wire rather than the stone. See when a gabion is still the right answer for where that does not bite.
Undermining repair. Rigid systems crack and drop as voids form beneath them, and the repair is a section rather than a component. See rock bags vs concrete revetment.
Unit replacement. Individually placed units are replaced individually where damaged.
Inspection. Every system needs it. The cost differs less than the repair cost does.
Eventual replacement. At the end of service life, whatever that is for the system in its actual environment.
The number that is usually available and rarely used
You do not need a model to start this. Look at your own maintenance records.
How many times has this reach, this outfall, this abutment been repaired in the last twenty years? At what cost? By whom?
That count is the lifecycle argument, and it is more reliable than any projection because it happened. A site being repaired after every significant event has already made the case for a different approach; the case is just recorded in a maintenance budget nobody is reading against the capital budget.
How to build a comparison without inventing numbers
We publish no prices, and a lifecycle model built on invented figures is worse than no model. What can be done honestly:
1. Establish the analysis period. Typically the design life of the asset being protected, not the protection. A bridge with forty years left sets the period.
2. List the events. Initial construction, then each expected maintenance intervention, then replacement. Get the intervals from suppliers and from your own records rather than assuming.
3. Get real costs for your own history. Your past repairs at similar sites are the best data available and they are internal.
4. Ask each supplier for an inspection and maintenance expectation in writing. Interval, scope, and what triggers intervention. A supplier who cannot answer is telling you something.
5. Include the costs outside the construction budget. Service loss during each intervention, permitting for each intervention, and mobilisation each time. Repeat mobilisation to a difficult site is a large recurring cost.
6. Discount if your organisation requires it, using your own rate.
The output is not a precise number. It is usually a clear ranking, and the ranking is what you needed.
Where lifecycle analysis is genuinely inconclusive
Being straight about this, because lifecycle arguments are easy to abuse:
Service life estimates carry real uncertainty. We publish which test method backs which claim and do not publish measured values, and our service life positions are stated welded to the conditions they were measured under — approximately 100 years in water under EN 12447, and 50-100 years covered within a month under EN 12224 and BS EN ISO 13438. Those are conditions, not a site. Your site is not a laboratory.
We hold no costed lifecycle study. When not to use rock bags says so explicitly. Anyone presenting a lifecycle comparison as settled fact, including us, should be asked where the numbers came from.
Maintenance intervals depend on the event record, which is a probability rather than a schedule.
Discount rates dominate long analyses. Over thirty years, the rate can matter more than the engineering, and it is an accounting choice.
So: use lifecycle thinking to rank options and to make the recurring cost visible. Do not present the output as a precision it does not have.
The argument in one line
A system that stays in position after a design event avoids a cycle. A system that moves creates one.
That is the real content of the lifecycle case for any armor: not that it is cheaper per unit, but that it does not generate a recurring cost.
Which is also why the failure modes matter more than the unit properties. A system that stays put but is undermined at its toe generates the same cycle as one that migrates. See why scour protection fails.
Making the case internally
Where capital and maintenance are different budgets, the lifecycle argument is an organisational problem before it is an engineering one. What helps:
- Present the maintenance history for the specific site, in cost
- Count the interventions, because a count is harder to argue with than a projection
- Include service loss, which frequently belongs to a third budget and is the largest number
- Name the do-nothing option and its cost, including the eventual asset loss
- Be honest about the uncertainty, which makes the certain parts more credible
Where to go next
- What drives installed cost
- How to compare unlike armor bids
- Before the storm vs. after for the repeat-repair case
- Materials, testing, and service life for what we publish
- When not to use rock bags for what we do not
- The cost hub for the rest