Assessing an Old or Non-Standard System
Why this matters
A new, standard, code-built system is predictable. An old one, or one somebody modified along the way, is a question mark, and question marks are where estimates go wrong. The standard parts may not fit. The thing you have to touch may crumble. What looks like the system may not be how it actually works. Scoping a legacy or improvised system is a different skill from scoping a new one, and treating the two the same is how you eat the difference.
Why old and non-standard are different problems
Two distinct situations, often overlapping:
- Old means the system has age on it: worn components near end-of-life, obsolete sizes, materials no longer common, things that were code when installed and are not now. The risk is fragility and availability.
- Non-standard means somebody did it their own way: improvised repairs, mixed materials, undersized components, work that does not match how the trade does it. The risk is that your assumptions about how it is built are wrong.
A new standard system lets you quote from experience because it matches the textbook. An old or non-standard one does not, so you have to assess it directly instead of assuming.
Read the system before you price it
Spend real time understanding what you are actually looking at:
- Trace how it really works, not how it should. Follow the actual runs, connections, and flow. On a modified system, the labels lie and the logical layout is gone. Confirm by tracing, not by assuming.
- Identify what is original and what was changed. Mismatched materials, newer fittings on old work, repairs that do not match the rest: each tells you where someone intervened, and those spots are your prime suspects and your fragile points.
- Find the end-of-life components. Things that are worn, corroded, brittle, or simply old enough that touching them risks breaking them. These set the real size of the job.
- Spot the code gaps. Older systems were built to older rules. Know what is grandfathered (allowed to remain) versus what you must bring up to current code if you touch it, because that can expand the job whether you wanted it to or not.
The questions an old system forces
Before the estimate, answer these:
- Will standard parts fit? Obsolete sizes and discontinued components mean your normal stock may not work. A part you cannot get turns a same-day job into a wait.
- What will break when I touch it? The shutoff, the fitting, the connection you have to disturb. On an old system, assume the worst component is the one you must handle, and scope to replace it.
- Does touching this trigger a code requirement? If working on the old system means a section must be brought current, that is scope you did not ask for but now own. Find out before you quote.
- Is repair even sound, or is it false economy? Patching one failing part of a system that is failing all over is throwing good work after bad. Sometimes the honest scope is larger replacement, and the customer deserves that read.
Price for the unknown without padding blindly
You cannot quote an old system as tightly as a new one, but you also cannot just guess high. Use structure:
- Price what you can confirm. The visible, testable parts of the job get firm line items.
- Assume what you cannot confirm. Write it: "priced assuming existing connections are serviceable and standard sizes." The assumption is your hook to re-quote if reality is worse.
- Warn what you cannot rule out. "This is old enough that if we open it and find corrosion, it's more, and I'll stop and show you first." Honest, on the front end.
- Probe the high-risk items now. Gently test the shutoff, open the one panel you can, confirm the obsolete part is available. Two minutes of probing beats a two-hour surprise.
The conversation the customer needs
Owners of old systems often do not know what they have. Tell them plainly:
- Explain that old and non-standard carry uncertainty. "Because this was modified and it's got age on it, I can't promise there are no surprises behind it, and I'd rather tell you that now."
- Lay out the assumptions and the warnings. What you priced for, and what would change it. Said before the work, this is trust. Discovered after, it is a fight.
- Give the honest repair-versus-replace read. If patching the old system is a losing game, say so, and say why. The customer who hears the truth about an old system remembers it.
What good assessment looks like
You traced the real system instead of assuming the standard one. You found the changed work and the end-of-life parts. You know whether your parts fit and whether code is triggered. The estimate has firm lines where you are sure, assumptions where you are not, and warnings where you cannot tell. And the customer heard the honest version before signing. That is how you scope an old system without getting burned by it.
References
- Trade-standard practice for assessing legacy and modified systems
- Local code authority guidance on grandfathered work versus current-code requirements
- See related: The Job Bigger Than It Looks Decision Tree
- See related: The What-Could-Go-Wrong Pre-Job Scan