What was breaking in soil remediation tracking before this project?
The client was managing an active Superfund cleanup under EPA oversight. Federally supervised environmental remediation comes with reporting obligations that the project sponsor cannot defer or simplify. Volumes of contaminated soil removed must be documented at the cubic yard level. Source locations and destination disposal sites must be traceable for every load. Contamination testing results must link back to the specific soil they describe. And the projection of how much soil remains to be treated, which determines the timeline and cost trajectory of the entire cleanup, must be defensible to the regulator.
Spreadsheets do not survive that scrutiny. They lose data integrity as multiple people edit them. They cannot enforce relationships between source location, destination, and testing record. They produce projections that no one can audit because the formulas drift over time. For a Superfund site under active EPA supervision, that is not an inconvenience. It is a regulatory exposure that grows with every reporting cycle.
For a Superfund cleanup, the consequences of weak tracking infrastructure compound over time. EPA does not forget reporting gaps. Timeline projections that turn out to be inaccurate get challenged in subsequent reviews. Funding decisions for the remaining cleanup phases depend on the credibility of the data presented. A tracking system that cannot defend its own outputs creates problems that outlive the cleanup itself.
What did PCG actually build for the EPA Superfund tracking environment?
PCG developed a database-backed tracking system designed specifically for federally supervised soil remediation. The architecture handled the complete data chain from contaminated source through testing through disposal destination, with a forward projection engine that produced defensible estimates of remaining work. Each component was built so that the data trail required by EPA auditors was captured at the moment work happened, not reconstructed afterward.
Every cubic yard of contaminated soil removed from the site was logged against its source location within the cleanup area. The system tracked extraction sequences, soil type, and the date and time of each removal. Source data became the anchor that every subsequent record linked back to.
Each load of removed soil was tracked from source to destination. Disposal site records included the receiving facility, transport documentation, and chain-of-custody. EPA reporting requires this trail. The system captured it as a structured record rather than a paper manifest reconstructed at the end of each reporting period.
Testing results from soil samples were linked directly to the specific soil they characterized. Test method, lab, results by analyte, and date were captured against each source location. When a question arose about the contamination profile of soil sent to a specific disposal facility, the answer was a query rather than a manual file search.
The system included a calculation engine that projected forward to estimate remaining soil quantities still requiring treatment. Inputs included treated volumes, contamination boundaries, treatment effectiveness, and remediation rates. The engine produced timeline and cost projections that were defensible to EPA because the calculations were transparent and the underlying data was queryable.
The system gave the client real-time visibility into project timeline, cost trajectory, and regulatory progress against the EPA-approved cleanup plan. Quantities removed, quantities remaining, projected completion, and costs to date were available without manual rollup from spreadsheets. EPA reporting cycles became data extracts from the live system.
Superfund sites fail their tracking obligations in a specific way. The site team usually has the data. They just cannot produce it in the form EPA requires within the timeline EPA expects. A tracking system that captures data at the moment of work and structures it for the format regulators ask for changes the equation. The data was always there. The infrastructure to surface it was not.
The forward projection engine was the part that created the most strategic value, beyond the regulatory reporting. A project sponsor who can produce a defensible estimate of remaining cleanup work has a different conversation with EPA, with funders, and with internal stakeholders than a project sponsor who is producing best-guess timelines from spreadsheets. The number itself is less important than the auditability of how the number was produced.
What changed after the system went into production?
The most immediate change was that EPA reporting cycles stopped being reconstruction projects. The data trail from source soil through testing through disposal destination was already captured and structured. Reports became data extracts. The team's effort moved from assembling reports to running the cleanup.
| Outcome | Result | How it was achieved |
|---|---|---|
| EPA reporting timeline | Data extracts, not reconstructions | Source-to-destination chain captured at the moment of work, structured for regulator format |
| Forward projection of remaining work | Defensible to regulator | Custom calculation engine with transparent inputs and queryable underlying data |
| Source-to-disposal chain of custody | Continuous and complete | Every load tracked from source location through destination disposal facility |
| Contamination testing traceability | Linked at the source-record level | Testing results attached directly to the soil they characterized, by source and date |
| Project timeline visibility | Real-time | Treated volumes, remaining volumes, and projected completion available on demand |
| Cost trajectory tracking | Tied to actual cleanup data | Costs attributed to source locations and treatment phases as work progressed |
The strategic value of the system extended beyond EPA reporting itself. Real-time projection of remaining cleanup work changed the client's ability to manage the project against budget and schedule. Decisions that had previously waited for the next reporting cycle could be made on current data. Funding conversations that had been based on best-guess timelines became conversations grounded in defensible projections.
What capabilities does this kind of system provide for federally supervised environmental cleanup?
The infrastructure built for this Superfund site addresses a problem class that appears across every environmental remediation project under federal or state regulatory oversight. The capabilities below apply to CERCLA Superfund work, RCRA corrective action, state-led brownfield cleanups, voluntary cleanup programs, and any operation where soil, groundwater, or other contamination is being tracked from contaminated source through treatment or disposal.
Every cubic yard of contaminated material tracked from source location through transport through destination disposal facility. The chain that EPA and state regulators require is captured automatically at each handoff rather than reconstructed at the end of reporting cycles.
A calculation engine that estimates remaining cleanup work based on transparent inputs and queryable underlying data. Project sponsors can produce timeline and cost projections that hold up to regulator review and stakeholder scrutiny.
Contamination testing results connected directly to the specific source location, sample, and material they describe. When a question arises about the contamination profile of material sent to a specific facility, the answer is a query against linked records, not a manual file search.
Treated volumes, remaining volumes, projected completion dates, and cost trajectory available on demand against the EPA-approved cleanup plan. Project decisions stop waiting for the next reporting cycle to be made on current data.
Technology stack
| Component | Technology |
|---|---|
| Database layer | Relational database with enforced source-destination-testing relationships |
| Calculation engine | Custom forward projection logic with transparent input parameters |
| Data capture | Spreadsheet and database integration for field data entry |
| Chain of custody | Source location, transport, and destination logged as linked records |
| Testing integration | Lab results linked at the source-record level by sample, method, and date |
| Reporting layer | EPA-format data extracts produced from live system queries |
| Compliance framework | CERCLA / Superfund supervision with EPA reporting alignment |
Does this apply if your cleanup is smaller than a full Superfund site?
The architecture scales down as well as up. State-led brownfield cleanups, voluntary cleanup programs, RCRA corrective action sites, and private remediation under regulatory oversight all face the same core problems as a Superfund site: source-to-destination chain of custody, testing data linked to physical material, defensible forward projections, and reporting that aligns with regulator format. The engineering decisions on this project transfer directly to cleanups an order of magnitude smaller.
What makes this project transferable is not the regulatory framework. It is the problem class. Any environmental cleanup where contaminated material moves from source through testing through disposal, under any oversight regime, is carrying the same data integrity risk this Superfund site was carrying before the system went live. The risk accumulates invisibly until a regulator asks a question the data cannot answer in the form required.
PCG has built environmental compliance and remediation infrastructure since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about Superfund and environmental remediation tracking systems
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 Superfund remediation tracking documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the Superfund site have been generalized. System capabilities and architecture reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
What was breaking in the oil manufacturer's compliance documentation before this project?
The client was operating across 25 physically separate sites, each generating its own compliance records, revision histories, and audit documentation. The document control infrastructure that ISO 9000 certification requires had been assembled site by site over years, in different formats, on different systems, with no single source of record. When an audit arrived, demonstrating compliance meant pulling documents from 25 different locations, reconciling revision numbers, and proving that the version controlled at one site was the same version controlled at another.
That is not a documentation problem. That is a certification risk. ISO 9000 audits do not penalize organizations that have the right document. They penalize organizations that cannot prove which version of a document was in force on a given day at a given site. A multi-site oil manufacturer with no centralized control over revisions was carrying that risk continuously.
For an oil manufacturer, the consequences of an ISO 9000 finding extend beyond the certification itself. Customers, regulators, and downstream partners often require ISO 9000 as a prerequisite for doing business. A lapse exposes the operation to contract risk, not just audit risk.
What did PCG actually build for the multi-site compliance environment?
PCG designed and built a suite of multi-user regulatory compliance databases tied together by a centralized ISO 9000 document management and control system. The architecture was specifically engineered to handle the multi-site reality of the operation rather than forcing all 25 sites to access a single physical database that would have created network and performance bottlenecks. Each layer was built so that local site operations continued normally even when central connectivity was interrupted.
Every controlled document existed in one master location with full revision history. When a procedure was updated, the new version was tagged, dated, and linked to the previous version. Sites pulled the current approved version from the central repository rather than maintaining local copies that could drift out of sync.
The compliance databases were designed for multiple simultaneous users across distributed locations. Record locking, change tracking, and conflict resolution were built into the data layer so that concurrent edits at different sites did not produce corrupted records or lost updates.
Every record creation, modification, and deletion was logged with user, timestamp, and the values before and after the change. ISO 9000 audits require this trail. The system produced it automatically rather than requiring staff to maintain it manually.
Document revisions moved through a defined approval path before becoming the active version. Drafts, reviews, and approvals were tracked in the system. Sites could not accidentally use a draft revision because only approved versions were marked active in the document repository.
The architecture combined local database performance with central document authority. Sites operated against local data layers for daily transactions while document control and revision management remained centralized. This eliminated the network latency problems that a fully centralized system would have created across 25 remote locations.
ISO 9000 certification is often treated as a documentation problem. It is actually a control problem. The question an auditor asks is not "do you have this procedure" but "which version of this procedure was in force at site 14 on March 3rd, and can you prove it." A document repository without revision control and audit trail does not answer that question. A document repository built around revision control and audit trail answers it in seconds.
The multi-site dimension changes the architecture significantly. A single-site ISO 9000 system can run on a centralized database without performance issues. A 25-site system cannot. The decision to combine local database performance with centralized document authority was the architectural call that made the deployment workable. Without it, daily transactions at remote sites would have run on network round trips that would have made the system unusable in practice.
What changed after the system went into production?
The most immediate change was the elimination of cross-site reconciliation work that had previously preceded every audit cycle. Documents controlled at one site matched documents controlled at every other site by construction, not by manual verification. Audit response timelines that had measured in days of file assembly became hours of structured query against the central system.
| Outcome | Result | How it was achieved |
|---|---|---|
| ISO 9000 audit readiness | Continuous | Centralized document control with revision history and full transaction audit trail |
| Cross-site document consistency | Single source of record | Master repository with approved-version logic; local copies replaced with controlled pulls |
| Records and transactions managed | 50,000+ | Multi-user database architecture engineered for the data volume from the design phase |
| Sites under unified control | 25 remote locations | Distributed databases with central document authority; local performance preserved |
| Audit response time | Hours, not days | Structured queries against the live system replaced manual reconstruction across sites |
| Revision control compliance | Enforced at the data layer | Approval workflows prevented draft revisions from being used as active documents |
The strategic value of the system extended beyond ISO 9000 itself. Once compliance records, transactions, and revisions were structured and queryable across all 25 sites, the operation gained visibility into patterns that had been invisible when each site managed its own documents. Cross-site procedural variations that should have been standardized became identifiable for the first time.
What capabilities does this kind of system provide for a regulated multi-site operation?
The infrastructure built for this oil manufacturer addresses a problem class that appears across every multi-site industrial operation under regulatory or certification obligations. The capabilities below are not specific to oil manufacturing. They apply to chemical processing, pharmaceutical manufacturing, food and beverage production, environmental services, and any operation where ISO 9000, ISO 14001, ISO 45001, or sector-specific certifications are part of contractual or regulatory requirements.
One master repository for controlled documents, with revision history, approval workflows, and version-active enforcement. Sites pull current approved versions rather than maintaining local copies that drift over time.
The audit trail required by ISO 9000 and similar standards is captured automatically at the transaction level. Audit response is a structured query, not a file reconstruction project that consumes weeks of staff time.
Record locking, change tracking, and conflict resolution built into the data layer protect against the silent data corruption that accumulates when distributed teams edit shared records without proper concurrency controls.
Local database operations preserve daily transaction speed at remote sites. Central authority over document revisions and approval workflows preserves the certification integrity that requires single-source control.
Technology stack
| Component | Technology |
|---|---|
| Database layer | Multi-user relational database with record locking and change tracking |
| Document control | Centralized repository with revision history and approval workflows |
| Architecture | Distributed databases tied to central document authority |
| Concurrency | Multi-user access with conflict resolution at the data layer |
| Audit trail | Transaction-level logging with user, timestamp, and before/after values |
| Access control | Role-based permissions per site, per document, per record class |
| Scale | Engineered for 50,000+ records and transactions across 25 distributed sites |
Does this apply if your operation is smaller than 25 sites?
The architecture scales down as well as up. A regulated operation running 5 sites faces the same core problems as one running 25: document control gaps between locations, version drift, audit response that becomes a manual reconstruction project, and silent data corruption when distributed teams edit shared records. The engineering decisions on this project, particularly the combination of local database performance with central document authority, are directly applicable to operations of any multi-site scale.
What makes this project transferable is not the size. It is the problem class. Any operation where compliance, certification, or regulatory documentation must be controlled across multiple physical locations is carrying the same risk that this oil manufacturer was carrying. The risk accumulates invisibly until an audit, a customer review, or a contract renewal forces the question of whether the documentation can actually be produced in the form regulators or auditors require.
PCG has built compliance infrastructure for multi-site industrial operations since 1995. The work documented here is one of more than 500 production applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years.
Frequently asked questions about ISO 9000 compliance database systems
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 ISO 9000 compliance work documented here is one of more than 500 custom applications PCG has delivered, with environmental and regulatory compliance representing approximately one-third of that volume across 31 years. Her direct involvement in every project is not a policy. It is how PCG operates. When you call, she answers.
Project details documented with client permission. Specific identifying details about the oil manufacturer have been generalized. Records, sites, and certification status reflect the actual production deployment.
PCG founded 1995. Allison Woolbert's personal experience in software development predates PCG's founding.
🔥 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.
❓ 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.
- 1
- 2