Resources • builder • presets • pricing
Fire door builder guide for presets, catalogues and pricing
A practical guide to using a preset catalogue to standardise installs and configurations — and how to keep pricing consistent across builder presets and quotes.
- Builder
- Presets
- Catalogue
- Pricing overrides
- Quotes
Installers pick consistent configurations
pricing stays predictable
A practical guide to using a preset catalogue to standardise installs and configurations, and how to keep pricing consistent across builder presets and quotes — before scaling quoting and remedials across sites.
Goal 01
Standardise options
Presets reduce "everyone does it differently." A shared catalogue means the same configuration — same description, same components, same pricing — whether it's quoted by the office or selected on site. Fewer one-offs, less rework, more comparable outputs.
Goal 02
Control edits
Catalogue changes should be deliberate and owned. When anyone can edit presets, sprawl and inconsistency follow quickly. Restrict edit access to a small set of owners so changes are reviewed, versioned, and intentional — not accidental overrides that break existing quotes.
Goal 03
Keep pricing rules clear
One rule beats mixed approaches without explanation. Decide whether pricing comes from inspection fail-reason mapping, builder overrides, or a baseline price list — then avoid mixing approaches without a documented rule. Clear pricing means explainable quotes.
Install teams
Consistent configurations — less interpretation on site. Presets mean the same part of the same config whether the installer is experienced or new, and whether they're working solo or alongside others.
Estimators
Pricing rules are predictable and explainable. When a client questions a line item, the estimator can trace it back to a preset and a pricing rule — not "that's just how we do it."
Admins
Presets are owned, reviewed, and kept consistent — not silently edited by whoever was last in settings. Edit access restricted to owners, with a review cadence to prevent catalogue sprawl.
Start small with your most common configurations
expand once the team is consistent
Review the presets that ship with Fire Door App, pick a small featured set for the most common configurations, then add additional presets as edge cases emerge. Resist building everything upfront.
Three tiers · featured · additional · review
Tier 01 · Featured
Your most common configurations
The 5–10 presets that cover the majority of your work — the ones every installer should know. FD30, FD60, common door types with the accessories that appear on most buildings. These are the defaults that ship-ready workflows depend on.
Tier 02 · Additional
Edge cases and specialist options
Added as needed, not pre-built speculatively. Specialist configurations — unusual door sizes, non-standard hardware, client-specific variants — belong here once they've been needed more than once. Not in the featured set to keep everyday quoting clean.
Tier 03 · Review cadence
Monthly or quarterly clean-up
Catalogues drift when no one is responsible for reviewing them. A monthly or quarterly review prevents near-duplicates multiplying, catches stale presets, and keeps pricing aligned with the current baseline. Assign an owner — someone with edit access who actually reviews it.
Preset naming standard · recommended
Three parts · consistent order · no free-text variants
Part 01
Type first
Start with the door rating
FD60 or FD30 — or whatever notation your team uses. This ensures presets sort sensibly and installers can scan by door type.
FD60 · FD30 · FD60s
Part 02
Key options
Add distinguishing accessories
The accessories that make this configuration distinct — closer, smoke seals, vision panel, intumescent. Keep it short.
w/ closers · smoke seals
Part 03
No variants
One spelling — enforce it
Pick one word and stick to it across every preset. "Closer" and "door closer" and "closers" will fragment reporting and create near-duplicate presets over time.
closer ✓ (not "closers")
Six steps from preset selection
to a saved, door-by-door configurable quote
Use this flow when you need quote outputs that stay linked to the configuration — comparable across jobs, consistent in wording, and ready to generate a PDF or approval link without rebuilding scope manually.
Six steps · preset → configured → saved quote
Step 01
Choose a preset
Start from a standard configuration where possible — don't configure from scratch every time. If the right preset doesn't exist, that's a signal to add one, not to build one-offs.
Step 02
Configure
Work through the configuration steps. Keep choices consistent with your catalogue rules — use the same component names and units. Deviations become overrides, not free-text one-offs.
Step 03
Add to basket
Drop each configured door into the quote. Repeat for each door type — different configurations get their own basket item so the quote reflects the actual mix of work.
Step 04
Review narrative
Check the wording that will appear on the PDF and email. This is the client-facing output — check descriptions are client-readable, not internal codes or shorthand.
Step 05
Fill client & project intake
Confirm contact and site details are correct before saving. Name, address, email recipient — errors here mean the PDF goes to the wrong person or carries the wrong address.
Step 06
Save quote & PDF
Generate the stored quote and download link. The quote is now linked to the configuration — changes to pricing or presets after this point don't alter the saved quote.
Pricing stays clean
when the same key and label is used across catalogue and quote
Three rules that prevent pricing from drifting — and a clear decision framework for when to use mapping vs overrides, and when mixing both without a rule creates unexplainable quotes.
Three key rules · then overrides decision
Rule 01
One meaning per key
Don't overload a key to mean two different scopes. "FD60-closer" should always mean the same thing — not "closer on 838 doors" in one quote and "closer on all FD60" in another. A key that means different things in different contexts isn't a key, it's a guess.
Rule 02
Explicit units in the label
Keep "per door" vs "per leaf" vs "per set" explicit in the label — not assumed. Mixed units create totalling errors that are tedious to spot and embarrassing to explain to clients. A double-leaf door quoted per leaf doubles the cost unexpectedly.
Rule 03
Versioned changes
If a key changes meaning, treat it as a new key. Renaming without versioning makes old quotes inexplicable — "why does this FD60-closer quote from last year price differently from this month's?" Versioned keys keep history traceable.
Override decision · use when
Avoid: mixing mapping and overrides without a documented rule — quotes become unexplainable after the fact.
Roll out the catalogue like a process change
not "just new buttons"
Three rollout steps, four catalogue drift patterns to avoid, and quick answers on client-specific presets, pricing consistency, edit permissions, and the builder's relationship to inspection records.
Rollout to installers
Three steps · pilot first · lock edits before scaling
Pilot one project
Confirm presets match real site work before rolling out to all installers. One building, one team, real findings — surfaces gaps in coverage and naming before they become a catalogue problem.
QA naming
Ensure outputs use consistent labels across the pilot quotes. If the PDF shows "door closer" and the catalogue says "closer", that's a naming drift to fix before rollout — not after.
Lock edits
Restrict who can change presets once live. Treat the catalogue like a product — edit access limited to owners, changes tracked, no silent updates that affect current quoting.
Catalogue drift · four patterns to avoid
Naming
Duplicate presets
Without a naming rule, "almost the same" options multiply — "FD60 with closer", "FD60 + door closer", "FD60 closers" all represent the same configuration but fragment reporting and confuse installers choosing between them.
Fix: agree one name per configuration and enforce it. Review quarterly and merge near-duplicates before they bed in.
Pricing
Silent pricing changes
Changing a preset price without recording the change means quotes from before and after the update are no longer comparable — and the reason for the difference is untraceable. "Why did this job cost more?" has no answer.
Fix: record the date and reason for every pricing change. Export the catalogue as a CSV snapshot before bulk changes.
Overrides
Overusing overrides
If overrides become common across most quotes, the baseline presets no longer reflect actual pricing. Every quote requires manual adjustment — which defeats the point of a catalogue. The override frequency is a signal to update the baseline, not to keep adjusting.
Fix: if an override is applied more than 3–4 times, fold it into the baseline preset or create a named variant.
Governance
No ownership
A catalogue without an owner drifts. If anyone can edit it, everyone quietly does — small changes accumulate into inconsistency. The knowledge of "why this preset exists" lives in nobody's head.
Fix: assign a named catalogue owner (or a small pair). Restrict edit access. Document the reason for every preset when it's created.
Common questions · quick answers
Yes — many teams start with a shared baseline catalogue that covers most jobs, then agree a rule for client-specific variations. These might be client-specific presets in the "additional" tier, named overrides, or a separate catalogue set for that client's work.
The key is keeping the rule documented so installers and estimators know which presets apply to which jobs — not discovering it varies mid-quote.
Decide one pricing source and stick to it: either pricing comes from inspection fail-reason mapping (outcomes → quote line items), from builder overrides (configuration diverges from baseline), or from a single price list applied to presets. Avoid mixing without a documented rule.
The most common source of inconsistency isn't wrong pricing — it's the same work priced via two different routes on different jobs, making totals incomparable and audits awkward.
Limit edit access to owners and admins — a small group of 1–3 people who understand the catalogue's purpose and are responsible for its consistency. Treat presets like a managed catalogue, not a shared document anyone can edit.
In practice: installers can select presets; estimators can apply overrides on individual quotes; only catalogue owners can add, rename, or remove presets from the shared catalogue.
No. The builder supports standardisation and configuration — it's a quoting and scope-building tool. Inspection records still require door-level identity (stable IDs), outcomes (pass/fail, fail reasons), and photo evidence captured on site.
The builder output feeds into quotes and pricing — it doesn't replace the evidence record that BS 8214 and audit requirements expect from the inspection itself.
Quick facts
Fire door builder at a glance
Featured presets
5–10 most common configs · everyone knows these
Naming
Type first · key options · one spelling enforced
Quote flow
Preset → configure → basket → narrative → intake → save PDF
Pricing
One source (mapping / override / baseline) · never mix without a rule
Access
Catalogue owners edit · installers select · estimators override per quote
Rollout
Pilot one project → QA naming → lock edits before scaling
Get started
Standardise one catalogue, then scale
Set a small featured preset set, lock edit permissions, and keep pricing rules clear so quoting stays consistent as the team grows.
Standardise one catalogue, then scale.
Featured presets, clear pricing rules, controlled edits.
Set a small preset set, lock edit permissions, and keep pricing rules clear so quoting stays consistent as the team grows.