A Subscription Estimator and Technical Library for Fire Protection Professionals

#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

#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.