🔥 What is FireFlight and how is it different from off-the-shelf software?
Off-the-shelf software is built for the average of its market. The forms, the workflows, the reports, all of them reflect decisions made for thousands of businesses at once. FireFlight is the opposite. PCG built it specifically so that a new client's system starts from what their operation actually does, not from a generic template that needs to be worked around.
The platform is modular. PCG has built and refined a library of components covering scheduling, credentialing, inventory, billing, compliance tracking, asset management, document handling, and more. Those components are the starting point. The logic, the fields, the permissions, and the workflows are all configured for the client before go-live. What takes months in traditional custom development takes weeks in FireFlight because the foundational engineering is already done.
The difference a buyer notices on day one is that the system matches how they work. The difference they notice a year later is that it keeps matching, because FireFlight is built to extend as the operation grows.
⚙️ What modules are available out of the box?
PCG deploys FireFlight from a growing library of prebuilt components. Each one is production-tested across real client deployments and configurable by logic, layout, workflow, and permissions without rebuilding from scratch.
Centralized records for clients, contacts, and account history with role-based visibility.
Multi-site, multi-resource scheduling with conflict prevention and real-time availability.
Status, location, assignment, and service history for every asset in the operation.
Parts, consumables, and supply management with min/max thresholds and reorder alerts.
Centralized credential and document repository with expiration alerts and audit logs.
Contract-based invoicing, billing cycle management, and usage-driven charge generation.
Work order creation, assignment, status tracking, and completion documentation.
Contact records, notes with timestamps, automated SMS and email alerts via Twilio and SMTP.
Modules that do not exist in the library yet are built as part of the engagement. Nothing is turned down because it falls outside a predefined feature set.
🤖 What does the AI reporting feature actually do?
In 2026, every software vendor is talking about AI. What most of them mean is a dashboard with a chatbot layered on top. What FireFlight delivers is different: a compliance officer or operations manager types a plain-English question into a chat interface and gets an answer pulled directly from their own live database. No canned report. No waiting for IT to run a query. No exporting to Excel and calculating manually.
The question could be "show me all open air permit violations by site sorted by deadline" or "which vehicles in the fleet consumed more than 20% above their class average last quarter." The system parses the question, constructs the query against the client's actual data, and returns the result immediately. The data never leaves the client's system. The AI layer sits on top of the database, not in place of it.
The large EHS and compliance platforms have been announcing AI features for two years. At the SMB level, none of them have delivered natural language database querying that actually works for a 30-person environmental firm or a mid-size industrial operator. The implementation complexity and the cost of those platforms puts it out of reach.
FireFlight brings that capability to operations that previously had no path to it. A compliance officer who spent hours each week pulling reports and reconciling spreadsheets can now get the same answer in seconds by typing the question. That is the operational difference.
📊 What reporting and dashboard options does FireFlight include?
FireFlight gives operations three levels of reporting visibility, depending on how the client wants to work with their data.
Built per client request using the reporting module. Configured before go-live to show the metrics that matter to that specific operation, not a generic set of KPIs.
Created from custom SQL queries for advanced users who need to pull non-standard views of their data without waiting for a developer to build a new report.
Individual users assemble their own dashboard from approved queries. Admins control which queries are visible to which roles.
Activity, inventory, usage, and billing reports exportable to Excel, CSV, or PDF. Role-based access controls restrict sensitive data by user level.
🔗 Can FireFlight connect to existing systems and import legacy data?
Yes. FireFlight is built with the assumption that a new client already has data somewhere, whether that is a legacy database, a collection of spreadsheets, a third-party platform, or a combination of all three. PCG handles the migration as part of the deployment.
Bulk data importing covers legacy systems, spreadsheets, and CSV exports. For ongoing connections, PCG builds custom API integrations with internal or third-party tools, with either real-time or scheduled sync depending on what the operation requires. The physician staffing platform documented in PCG's case studies runs Twilio for SMS alerts alongside SMTP email, both integrated into the same workflow. The municipal fleet fueling system runs encrypted TCP socket communication with hardware at 65 remote sites. Those integrations are not add-ons; they are part of what FireFlight is built to support.
🔐 What is FireFlight built on and how is security handled?
FireFlight runs on C# .NET Core 8 with Razor Pages and SQL Server. That stack was chosen because it is production-proven at scale, has a long support lifecycle from Microsoft, and handles the performance demands of real-time multi-site operations without architectural compromises.
| Component | Technology |
|---|---|
| Backend | C# .NET Core 8, Razor Pages |
| Database | SQL Server with performance tuning and optimization |
| Security | End-to-end encryption, role-based access control, data compression |
| Permissions | Granular user-level access per form, subtable, and popup with record-level visibility |
| Hosting | PCG-managed, performance-tuned servers with low-maintenance overhead |
| Notifications | SMTP email, Twilio SMS |
| AI layer | Natural language querying against live client database via leading AI provider integration |
The permissions framework is granular. Access is controlled at the form level, the subtable level, and the individual record level. A user who should not see payroll data cannot reach it through any path in the system, including ad-hoc queries. That level of control matters for operations that handle credentialing, compliance records, financial data, or personnel information across multiple departments.
🏭 What kinds of operations is FireFlight the right fit for?
FireFlight fits best when an operation has outgrown its current tools but cannot justify the cost or the implementation timeline of an enterprise platform. The clients who get the most out of it are running something important on software that was never built for the volume, the complexity, or the compliance requirements they are dealing with today.
PCG has deployed FireFlight across municipal fleet operations, healthcare staffing and credentialing, airport ground operations, environmental compliance tracking, industrial safety management, and field service coordination. The common thread is not the industry. It is the situation: a real workflow that needs a real system, not a workaround dressed up as software.
PCG does not sell FireFlight to nonprofits, government agencies, or legal and accounting practices. Those sectors fall outside PCG's documented experience and the sales cycles do not match PCG's operating model. The right client is a private-sector operator with a specific problem and a decision-maker who can move in 30 to 60 days.
🏢 Does FireFlight support multiple clients or tenants on one system?
Yes. FireFlight was built from the start with multi-client architecture. PCG uses it internally to manage deployments for multiple clients through a centralized system, and the same capability is available to any client running a service business with multiple accounts or locations.
Manage multiple customers or accounts through a single system with shared reference tables that expand as clients request additions.
Each client can use a dedicated or shared SQL Server database depending on isolation requirements. Both models are supported.
System-level checks maintain data separation between tenants regardless of whether they share infrastructure or run on isolated deployments.
Isolated hosting for clients with strict data residency requirements. Contained shared hosting for operations where cost efficiency matters more than physical separation.
🎨 What does the interface look like and how much can it be customized?
FireFlight is not a generic-looking enterprise system. PCG built client-level theming directly into the platform so that each deployment reflects the client's branding from day one. Logos, colors, and navigation styles are configured before go-live, not added as an afterthought.
Accessibility is built in, not bolted on. High-contrast themes and dyslexia-friendly fonts are available as user-selectable options. Admins set defaults for new users, but individuals can update their own settings independently. For operations where staff turnover is high or training time is short, standardized form layouts across the system reduce onboarding friction considerably.
Logos, colors, and navigation styles configured per deployment. The system looks like yours, not like generic enterprise software.
High-contrast themes and dyslexia-friendly fonts available as standard options. No accessibility plugin required.
Optimized for mobile, tablet, and desktop. Field staff using phones and office staff using monitors see a layout designed for their screen.
Tooltips, contextual help, and inline validation prevent user errors before they reach the database, not after.
👤 Can individual users personalize their own experience?
Yes. Within the boundaries that admins set, individual users can adjust their interface to suit how they work. This is not a cosmetic feature. For operations with diverse teams, the ability to switch to a dyslexia-friendly font or a high-contrast theme affects how quickly someone can use the system accurately under time pressure.
Users choose from available system-wide themes. Admins control which themes are offered; users pick from that set.
A library of tutorial companions guides users through workflows. Useful for onboarding new staff without requiring one-on-one training sessions.
Toggle between standard and dyslexia-friendly fonts at the user level. Admins set the default; users can update independently.
Admins set default settings for all new users. Individual users can override their own settings without affecting anyone else's experience.
🧩 What kinds of form controls and data structures does FireFlight support?
FireFlight includes a custom control library built for the kinds of data entry that operations actually deal with: linked records, inline editing, dynamic filters, embedded calendars, and hierarchical data structures. These are not bolt-on widgets. They are standard components of the platform.
Text fields, radio buttons, checkboxes, dropdowns, and multiselect options. All configurable by field, form, and user role.
Linked data accessible through inline popups with editing of existing records without leaving the parent form.
Add and remove linked records using dynamic filters. Relationships between records reflect the actual structure of the operation.
Embedded scheduling panels, calendar views, and data tree structures integrated directly into record layouts. Custom widgets can also be embedded into any view.
🔒 How granular is the permissions system?
Access control in FireFlight goes deeper than role-based permissions at the page level. Every form, every subtable, and every popup has its own permission mapping. A user who should not see payroll data cannot reach it through any path in the system, including ad-hoc queries, subrecord navigation, or API calls.
Each form is mapped to validate user access to approved modules. Users cannot navigate to forms outside their permission set.
Admins can identify access conflicts before they become a problem. The system surfaces contradictions in permission assignments during setup.
Default value control for restricted or hidden fields. Sensitive fields can be hidden entirely from users who should not see them.
Permissions extend to the individual record level. Subrecord permissions are tied to the context of the parent form, not applied globally.
🎓 What training and support tools are built into the system?
FireFlight includes embedded training tools so that new staff can get up to speed without requiring dedicated training sessions for every hire. For operations with high turnover or seasonal staffing, this matters more than most vendors acknowledge.
Onboarding flows guide new users through the workflows specific to their role. Not generic help documentation: flows built for how that deployment actually works.
Help icons and tooltips appear in context, at the field or action where they are relevant, not in a separate help tab that no one opens.
Prevents user errors at the point of entry. Staff know immediately when something is wrong, before the record saves and before the error propagates downstream.
High-level operational insights and system controls for administrators. Usage patterns, access logs, and system health visible from a single view.
Frequently asked questions about FireFlight
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding. FireFlight Data System is a proprietary platform built and maintained by Phoenix Consultants Group.
Experience the power of PCG’s expert engineering through the FireFlight Data System.
Our system is built to transform complex inventory and project management into a seamless, high-performance operation.
Let PCG show you how to eliminate manual errors and respond to market demands with the confidence of an intelligent, aware system.
Airport ground operations teams manage fleets of tugs, belt loaders, air starters, ground power units, and other specialized equipment across multiple terminals and shift rotations. When that management runs on whiteboards, spreadsheets, and phone calls, maintenance cycles get missed, equipment location is unknown, and accountability gaps show up in inspection logs and incident reports. PCG built a modular GSE management platform that replaced all of it with a single system tracking every asset, every technician assignment, and every service event in real time.
At a glance
🚛 Fleet tracking for tugs, belt loaders, air starters, GPUs, and all GSE asset types
📦 Parts and maintenance inventory with automated consumption tracking
👷 Personnel management with shift assignments and certification records
📍 Real-time location and service status visibility across all terminals
🔧 Preventive maintenance scheduling with usage-based trigger logic
🔐 Role-based access for maintenance, dispatch, and operations leadership
What was the problem and what did PCG build to solve it?
Ground operations teams were managing a complex, multi-terminal fleet using tools that could not keep pace with the operational volume or the accountability requirements of airport ground operations. The gap between what those tools could track and what the operation actually needed to know was showing up as downtime, inventory discrepancies, and compliance exposure.
- Equipment status and location managed on whiteboards and static spreadsheets
- Manual check-in and check-out processes with no audit trail
- Fragmented communication between maintenance, dispatch, and shift leads
- Missed preventive maintenance cycles causing avoidable breakdowns
- Inventory inaccuracies including lost and duplicate parts records
- No way to generate service history or performance reports across facilities
- No accountability tracking for personnel assignments and inspection logs
- Centralized command platform tracking every GSE asset across all terminals in real time
- QR and barcode integration for check-in, check-out, inspections, and service records
- Usage-based maintenance triggers that fire on hours, mileage, or calendar interval
- Automated parts consumption tied to maintenance work orders
- Full personnel assignment and certification tracking with expiration alerts
- Live operational dashboard with filters by terminal, equipment type, and service category
- Exportable compliance, usage, and downtime reports for regulatory and management review
What are the five core modules in the GSE management system?
The system was built as five independent but integrated modules. Each module manages a distinct operational domain. Because the architecture is modular, changes to the inventory module do not affect the personnel module, and new modules can be added as the operation's requirements expand without requiring changes to existing functionality.
- Real-time status tracking for every piece of ground equipment
- Custom attributes for equipment type, condition, location, assigned gate, and availability
- QR and barcode integration for check-in, check-out, inspections, and service record updates
- Full service history accessible from any asset record
- Parts, consumables, and tools managed by location across all terminals
- Min and max thresholds with automatic reorder alerts before stockouts occur
- Inventory audit logs with timestamps and user attribution
- Automatic part consumption recorded when maintenance work orders close
- Preventive maintenance logic triggered by usage hours, mileage, or calendar interval
- Work order creation and tracking with status, assignments, and technician notes
- Service history reports and compliance logs for each asset
- Overdue maintenance alerts with escalation to supervisors
- Operators, technicians, and supervisors assigned by shift or equipment group
- Credentials, certifications, and training records with expiration date tracking
- Performance and usage logs linked to equipment assignments
- Automated alerts when certifications approach expiration
- Live operational dashboard showing active equipment, out-of-service units, and open service queues
- Custom filters by terminal, equipment type, or service category
- Exportable reports for compliance, usage patterns, and downtime metrics
- Capital replacement and utilization data for management planning
What were the measurable results after deployment?
Beyond the headline numbers, the operation gained the ability to make capital replacement decisions from utilization data rather than from age alone, and shift transitions became faster because incoming leads could see the current state of every asset and every open work order without a verbal handoff.
What were the key technical innovations in this build?
Technology stack
| Component | Technology |
|---|---|
| 🖥️ Frontend | Razor Pages, JavaScript, Bootstrap |
| ⚙️ Backend | .NET Core / C# |
| 🗄️ Database | SQL Server |
| 🔔 Alerts and notifications | SMTP email alerts; optional Twilio SMS integration for maintenance and certification triggers |
| 🔐 Security | Role-based access control with department and function-level permissions; encryption at rest |
| ☁️ Hosting | IIS deployment; on-premise or cloud configuration supported depending on client infrastructure |
Frequently Asked Questions
❓ What was breaking in the city's fueling operation before this project?
The city was running a legacy fueling system that had accumulated years of unindexed transaction data. At the scale of 130,000 fueling events per quarter, that accumulation made the system progressively slower until daily delays became routine. Terminals timed out. Transactions failed to log accurately. Fuel dispensed did not always match what the database recorded, which created billing discrepancies and exposed the city to audit risk.
The underlying security architecture compounded the problem. Every time a vehicle was added, a fuel allowance changed, or a site was edited, the system retransmitted the entire vehicle whitelist to all sites. Unencrypted. In full. Across cellular connections. Data costs were high, the sync traffic was redundant, and the exposure was real. There was no dashboard showing tank levels or system health across the network. Each site operated in isolation.
For a fleet this size, these were not inconveniences. Emergency responders, sanitation crews, and transportation vehicles all depend on fueling access around the clock. A system that crashes or loses transaction data is a liability problem, not just an IT problem.
🛠️ What did PCG actually build, and how does it work?
PCG engineered the platform in .NET Core from the ground up. The architecture handles three things simultaneously: ruggedized hardware integration at each pump, encrypted real-time communication between sites and the central server, and a centralized dashboard that shows the entire operation at once. Each layer was designed so that a failure in any one does not take down the others.
PCG built RFID vehicle identification directly into the terminal, with manual scan keys for backup authentication. Coil ring sensors verify nozzle engagement before dispensing can occur. The hardware is weather-resistant and designed for 24/7 outdoor use at unmanned fueling stations.
Standard AES-256 encryption increases payload size. PCG developed a dual-layer protocol that compresses and encrypts simultaneously, reducing payload sizes by 50-60% before transmission. The city's cellular data costs dropped 80% as a direct result. This was not an off-the-shelf approach. It required custom engineering specifically for this problem.
The old system retransmitted the entire vehicle whitelist on every change. PCG replaced that with delta sync: only what changed gets transmitted, compressed, and encrypted. A single vehicle update no longer triggers a citywide data event.
Each site can operate independently if the network goes down. Transactions queue locally and sync automatically when connectivity restores. No fueling operations lost. No manual reconciliation required afterward.
Access is controlled by department, user, vehicle, and site. The central dashboard shows real-time tank levels via Veeder Root integration, live system health, and fueling activity across all 65 locations. What previously required manual site visits to check is now visible from a single screen.
The data cost problem was not primarily a network problem. It was a protocol design problem. The city was paying cellular rates on redundant full-whitelist transmissions that could have been eliminated with delta sync from the start. Security and efficiency are usually treated as trade-offs. On this project, the compression-encryption layer made both better at the same time.
Fleet fueling systems fail quietly before they fail visibly. Transaction logging errors accumulate in the background for months before an audit surfaces them. The diagnostic work at the start of this engagement found data discrepancies that predated the visible crash symptoms by over a year.
🚀 What changed after the new system went live?
The most immediate change was operational stability. A system that had been crashing daily ran at 99.5% uptime from deployment forward. The 300% improvement in transaction speed was measurable at the terminal level within the first week.
| Outcome | Result | How it was achieved |
|---|---|---|
| System uptime | 99.5% | Standalone site mode, offline queuing, performance-optimized SQL |
| Transaction speed | 300% faster | Indexed SQL, optimized data flow, high-efficiency query architecture |
| Cellular data costs | 80% reduction | Proprietary compression-encryption + delta sync replaced full whitelist retransmission |
| Fuel theft and misuse | Effectively eliminated | RFID authentication, AES-256 encryption, real-time audit logs, per-vehicle fuel limits |
| Departmental billing accuracy | 100% transaction attribution | Every fueling event linked to department, vehicle, and user at point of transaction |
| Tank monitoring | Real-time across all 65 sites | Full Veeder Root integration replaced manual site-by-site retrieval |
The financial impact extended beyond data cost reduction. Real-time audit logs with encrypted user validation eliminated the fuel theft and misuse that had been difficult to quantify under the old system. The city recovered the cost of the project in the first year through a combination of direct theft prevention and accurate departmental billing that replaced a system of estimated allocations.
💰 Financial and operational benefits
The performance numbers are the visible part. The financial impact runs deeper, across three areas that the old system had no way to measure or prevent.
Real-time auditing, encrypted user validation, and per-vehicle fuel limits eliminated theft and misuse that had been accumulating undetected. The city recovered hundreds of thousands of dollars annually once every transaction was tied to a verified user and vehicle at the moment of dispensing.
Every fueling event is now attributed to the correct department, vehicle, and user at the point of transaction. The estimated allocations that had generated billing disputes across 50+ city departments were replaced with usage-based records that hold up to audit review without reconciliation work.
Fuel consumption patterns surfaced vehicles consuming significantly more than their fleet class average. That data fed directly into maintenance scheduling and replacement planning, reducing the time between a performance problem appearing and a decision being made about it.
The proprietary compression-encryption protocol cut cellular transmission costs by 80%. For a 65-site operation running continuous sync across a cellular network, that reduction is a recurring annual saving, not a one-time gain. The protocol paid for its own development cost within the first operating year.
💡 Does this apply if your fleet is smaller than a top-5 metro operation?
The architecture scales down as well as up. A municipal fleet running 500 vehicles across 8 sites faces the same core problems: authentication gaps, inaccurate transaction logging, data that is difficult to audit, and hardware that fails in outdoor environments. The engineering decisions on this project, particularly the standalone site mode and the delta sync model, are directly applicable to operations an order of magnitude smaller.
What makes this project transferable is not the scale. It is the problem class. Any operation where fuel is dispensed without real-time verification and logging is carrying risk that accumulates invisibly until an audit, an investigation, or a budget review forces the question. By that point, years of discrepancies are on the table.
PCG has built fueling systems for municipal operators since before most of the platforms now marketed as fleet management solutions existed. The work documented here is not a proof of concept. It is a production system managing one of the largest municipal fleets in the country, running continuously since deployment.
🔍 Technology stack
| Component | Technology |
|---|---|
| Frontend | ASP.NET Razor, Bootstrap |
| Backend | .NET Core, Entity Framework, LINQ |
| APIs | RESTful JSON APIs, JWT authentication, HTTPS |
| Security | AES-256 encryption, client certificates, RBAC |
| Networking | Encrypted TCP socket services, proprietary compression-encryption protocol |
| Database | SQL Server with partitioning, replication, and indexing |
| Hardware | RFID boards, manual scan keys, coil ring sensors |
| Hosting | On-premise Windows Server cluster with redundancy |
Frequently asked questions about custom fleet fueling software
Allison has been building custom software since the early 1980s, including work as a data analyst for the U.S. Air Force before founding PCG in 1995. The fleet fueling work documented here is one of more than 500 custom applications PCG has delivered across municipal operations, industrial safety, healthcare staffing, and environmental compliance. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
All performance metrics cited in this case study are drawn from PCG's internal project documentation for this engagement.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.