# A Subscription Estimator and Technical Library for Fire Protection Professionals

> Estimators and technicians were hunting through manufacturer documents to find the right fire stopping system for each penetration. We built a web application that puts approved systems in one searchable library, filters them by manufacturer, produces PDFs for quotes and inspections, and sells access by subscription.

- Source: https://synconai.com/case-studies/fire-protection-estimator-and-technical-library
- Publisher: SynconAI (https://synconai.com)
- Type: Case study
- Evidence: Delivered client engagement. The client is anonymised; the industry, products and outcomes are theirs.
- Organisation: An Australian passive fire protection contractor that turned its technical know-how into a subscription product for estimators and technicians
- Industry: Commercial & Business Services
- Products: Next.js, Custom web application, Authentication and roles, Subscriptions, PDF generation, AI product identification (in development)
- Service: Custom Web Application Development (https://synconai.com/custom-web-application-development)
- Reading time: 6 minutes

## In short

We built a subscription web application for a fire protection business: a technical library of approved fire stopping systems and products, an estimator that finds the right system and produces a PDF for a quote or inspection, role-based access for users, technicians and administrators, manufacturer filtering, and subscription pages, with AI product identification in development.

## Key points

- Specialist knowledge can be a product. A contractor’s technical library, organized well, is valuable to estimators and technicians well beyond its own team.
- Build the library before the features. Search, filters, estimating and AI all depend on clean, structured product data.
- Roles are a design decision, not a login screen. Users, technicians and administrators need different views and different rights from the first release.
- Label what is in development. AI features belong on the roadmap until they are live, and saying so protects trust in the parts that are.

## From technical library to quote-ready PDF

At the base is the technical library: approved fire stopping systems and products, organized so they can be searched and filtered by manufacturer. Above it sits access control, with separate roles for users, technicians and administrators, and subscription pages that let external professionals buy access. The estimator layer lets a user find the right system for a situation and produce a PDF to support a quote or an inspection. At the top, AI product identification and MCP-based workflows are in development, designed to read from the same library.

### 1. AI layer (in development)

- Product identification
- MCP workflows

Built on the same library, not a separate source.

### 2. Estimator

- System lookup
- Selection
- PDF output

From question to document in one place.

### 3. Access

- Users
- Technicians
- Administrators
- Subscriptions

Each role sees what it needs.

### 4. Library

- Approved systems
- Products
- Manufacturer filters

One source of technical truth.

## The starting position

Passive fire protection is a technical trade. Every time a pipe, cable or duct passes through a fire-rated wall or floor, the gap has to be sealed with a tested system that matches the wall type, the penetration, the size and the fire rating required. Manufacturers publish their approved systems in long technical documents, and those documents change.

For estimators and technicians, that means a lot of searching. Pricing a job, or checking that the right product was installed, starts with finding the right approved system among many manufacturers' documents. Experienced people carry much of this in their heads, but knowledge in heads does not scale, and newer staff spend real time looking things up.

The contractor in this engagement had already connected its own sales, jobs and invoicing on Salesforce. It also had something less common: a deep, organized understanding of fire stopping systems built up over years of work. It saw an opportunity to turn that knowledge into a product, a technical library and estimator that its own people could use and that other professionals in the industry would pay to access.

There was a second motive. A library that the whole industry can use raises the standard of work across it, and it positions the contractor as the people who know fire stopping systems best, which helps its contracting business win work too.

The brief was to build that product as a proper web application: searchable, role-based, able to produce documents, and ready to sell by subscription.

## What we built

### 01 A structured technical library

The heart of the application is a library of approved fire stopping systems and products, structured so it can be searched and filtered instead of read page by page. Each system carries the details an estimator or technician needs to decide whether it fits the situation in front of them.

### 02 Manufacturer filtering

Users can filter the library by manufacturer, which matters in practice. A specification may require a particular manufacturer's products, or a contractor may stock one range and not another. Filtering cuts the search to the systems that are actually usable on the job.

### 03 The estimator and PDF output

The estimator turns a lookup into something useful for the business. A user finds the right system for a situation and produces a PDF that supports a quote or an inspection record. The document carries the system details, so the person reading the quote or checking the work sees exactly what was proposed.

### 04 Authenticated access with three roles

The application has authenticated access for three roles. Users look up systems and produce documents. Technicians get the technical detail they need in the field. Administrators maintain the library and manage who has access. Each role sees what it needs and nothing more.

### 05 Subscription pages

Because the library is a product, the application includes subscription pages so external professionals can sign up and pay for access. That turns the contractor's know-how into a revenue line alongside its contracting business.

### 06 AI identification, in development

On top of the library, AI identification of fire stopping products and MCP-based workflows are in development. The idea is that a user could identify a product from what they see on site and connect straight to the right approved system. These features are not live yet, and they are being built to read from the same library, so the product keeps one source of truth.

## How it is used

An estimator pricing a commercial fit-out has a list of penetrations from the drawings: a set of copper pipes through a plasterboard wall, a cable bundle through a concrete slab, a duct through a fire-rated ceiling. For each one, they open the library, filter by the manufacturer the specification calls for and narrow to the systems that fit the wall or floor type and the penetration. They select the right system and produce a PDF that goes with the quote.

Weeks later, a technician on site checks the same system in the library before installing it, and an inspector reviewing the work can be shown the document that supported the quote. The information is consistent from estimate to installation, because it all came from the same place.

## Why a custom web application

The contractor's own operations run on Salesforce, and it would have been possible to build a library inside the CRM. It would also have been the wrong product. The people who will pay for the library are estimators and technicians at other businesses, most of whom will never have a Salesforce licence. They need a fast, public-facing experience built around search and documents, with a simple way to subscribe.

A custom Next.js application gives exactly that. It is designed around the library and the estimator instead of around CRM records, it handles authentication and subscriptions directly, and it can grow into AI features without being limited by a platform built for something else. The CRM and the product each do what they are best at.

## Designing a library that stays trustworthy

A technical library is only valuable if people trust it, and trust depends on how it is maintained.

**Structure over documents.** Systems and products are stored as structured records, not as copies of manufacturer PDFs, so they can be searched, filtered and updated individually.

**Administrators own the content.** The administrator role exists so that the people who understand the systems decide what goes in the library and when it changes.

**Every output traces back.** PDFs carry the system details from the library, so any document can be checked against its source.

**New features read the same data.** The AI work in development is designed to sit on top of the existing library, not beside it. Two sources of technical truth would undermine the whole product.

## How we delivered it, end to end

**Product thinking first.** We treated the application as a product with paying users, not an internal tool, which shaped the decisions about roles, subscriptions and the public experience.

**Library before features.** The data model for systems and products came first, because search, filtering, the estimator and the future AI all depend on it.

**Roles from the first release.** Access for users, technicians and administrators was designed in from the start.

**Documents that stand on their own.** PDF output was designed to be read by someone who never sees the application, such as a builder reviewing a quote.

**Honest roadmap.** AI identification and MCP workflows are being built as the next stage and are described as in development until they are live.

## The decisions that mattered

**Custom application, not a CRM page.** Building outside Salesforce served the real buyers of the product.

**One source of truth.** Every feature, present and future, reads from the same structured library.

**Subscriptions built in.** Treating the library as a product from day one opened a new revenue line for the business.

## What changed

| Area | Before | After |
| --- | --- | --- |
| Finding systems | Searching manufacturer documents | Searchable, structured technical library |
| Narrowing options | Manual reading | Filtering by manufacturer |
| Supporting quotes | Details copied by hand | PDF output from the selected system |
| Access | Knowledge held by experienced staff | Roles for users, technicians and administrators |
| Commercial model | Know-how used internally only | Subscription access for external professionals |
| Next stage | Not planned | AI identification and MCP workflows in development |

## What we would tell a specialist business considering this

If your team has built up technical knowledge that others in your industry struggle to find, it may be worth more as a product than as a habit. Structure it first, so it can be searched and maintained. Design the roles and the commercial model from the start, and keep everything, including future AI, reading from one library. Then be honest about what is live and what is coming, because in a technical trade, trust is the product.

## Questions

### Why build a custom web application instead of using Salesforce?

The product is sold to external professionals who will never hold a Salesforce licence, and it needed a public-facing, subscription-based experience designed around search and documents. A custom Next.js application was the better fit, while the contractor’s own operations continue to run on Salesforce.

### Who uses the application?

Three roles: users who look up systems and produce documents, technicians who need the technical detail in the field, and administrators who maintain the library and manage access. External professionals can subscribe through the subscription pages.

### Is the AI product identification live?

No. AI identification of fire stopping products and MCP-based workflows are in development. The library, estimator, roles, filtering, PDFs and subscriptions are the parts in use today.

---

SynconAI. https://synconai.com/case-studies/fire-protection-estimator-and-technical-library