Wildland Fire Contractor Software Problems: The 5 That Delay Your Money, and How to Avoid Them

Why does the build creep from shift tickets into a full company system so often?

You start with one goal: capture shift tickets and crew time in camp so invoices go out clean. By the third scoping call the list has grown to equipment maintenance, fuel logs, a driver qualification file, an inventory of hose and hand tools, a training calendar, and a portal so the government can see your resources. Each addition is reasonable on its own. Together they push a ten week project to nine months, which means it lands in July, which means nobody adopts it.

Two forces drive this. Contractors have been running the whole business on paper for years, so once a system exists the temptation is to put everything in it. And the office staff are the people in the room, while the crew bosses who will actually use it are on an assignment.

The discipline that works is timing rather than willpower. Fix a delivery date in the off season, then cut scope to fit it. Ship shift tickets, crew time, agreement rates and invoicing for one resource category, run a full season on it, then extend. Maintenance and inventory are genuinely useful and they are not what is stopping your money. If a developer agrees to your whole wish list without pushing back on sequence, they have not built for a business with a hard seasonal deadline.

What goes wrong when you move years of tickets, agreements and resource records across?

Most contractors want their history in the new system, and most of that history is paper, photographs of paper, or a spreadsheet whose columns changed twice. Three specific problems follow.

First, agreements. Your historic invoices were calculated under rates that have since been renewed, so if you load only current rates your past invoices become irreproducible, which matters the moment an agency queries a prior year payment. Load agreements as records with effective dates and load the old ones too, even where the resource type no longer exists.

Second, resource identity. An engine that was sold, replaced and given the same internal number is two assets, not one, and merging them corrupts the maintenance and inspection history you are building the system to keep straight. Decide identity rules before import, not during.

Third, receivables. Load outstanding invoices with their real submission dates and current state so aging is honest from day one. Contractors are often tempted to start the ledger clean because the old numbers are embarrassing. That defeats the purpose. The aging report is the artefact you take to your lender in October, and it is worthless if it starts in January.

Anything older than three seasons is usually not worth migrating. Keep the paper, archive the scans, and start clean.

Why do the payroll and accounting integrations break after launch?

The government paperwork side has no integration to break, which is its own problem. Agency systems for resource ordering and incident business administration are built for the agency, and there is no contractor-facing interface that carries your rates and your invoice through. Any developer promising a connection there is guessing.

The integrations that do exist are payroll and accounting, and they break for predictable reasons. Payroll providers change their file formats and their API versions on their own schedule, and the change lands while your crews are deployed. Wage rules move underneath you: overtime, travel time, per diem and, on some assignments, prevailing wage determinations that differ from your standard rate. A file that mapped correctly in March fails in July because a new determination applies to an assignment type you had not encountered.

Accounting integrations break differently. Your bookkeeper reclassifies transactions in the accounting package, which silently diverges from the invoice records in your system, and by year end the two disagree about what was billed. The fix is to decide, in writing, which system owns which fact. Your build owns assignments, tickets, rates and invoices. Accounting owns the general ledger. One direction of flow, with a reconciliation report that lists divergence rather than hiding it. Add automated tests that run the payroll export against the provider every week even when nothing has changed, so a format change surfaces on a Monday rather than on a payroll run.

What happens when qualification currency and inspection status are not covered?

This is the gap that costs you the season rather than the invoice. Before you bill an hour you have to be orderable, which means the resource is available, the equipment has passed inspection, and every person assigned holds current qualifications for the position they will fill, along with current medical and fitness testing where required.

All of those expire, and they expire in the off season when nobody is looking. The first busy week of a season is when everyone discovers what lapsed. A resource refused at an incident costs you the mobilisation, the assignment and, less visibly, your standing with that dispatch centre for the rest of the year.

Systems that skip this look complete in a demo and fail in June. Cover it properly: qualifications, medical and fitness currency and inspection dates as records with expiry, with the calendar run backwards from your season start so renewals are scheduled in March rather than discovered later. Availability should be a state you set deliberately with a logged reason, which also gives you a defensible answer when a dispatch centre asks why you turned down an order.

The compounding benefit is that this is the same data your invoices depend on. The person on the time report is the person whose qualification the system already holds, so the two records cannot drift.

Should you build custom or configure what you already own?

If you run one or two engines and a bookkeeper who knows the forms, stay on paper and a spreadsheet. The owner personally sees every ticket at that size, there is no leak to plug, and software would be a cost with no return. We say this to contractors regularly and mean it.

If your problem is purely bookkeeping, configure what you have. Most contractors already run QuickBooks or similar, and it will hold customers, invoices and aging perfectly well. Build a disciplined rate sheet, one invoice template per agreement, and a naming convention for scanned tickets, and you have solved a real part of the problem for the cost of a weekend.

What accounting packages cannot do is offline capture in camp, agreement rates with effective dates and conditions, duplicate ticket detection across relief operators, or a per-line variance table when an agency pays a different amount. Those are the four things worth building. Generic field service platforms do not fit either, because they assume a customer, an address and an invoice at the end. Your end product is a government-accepted submission, which is a different shape.

The threshold that matters in practice is around eight fielded resources, more than two agreements, or the point where you cannot answer from memory which invoices are outstanding and why.

How do hidden costs get into the quote?

Four items are routinely missing. Offline conflict resolution is the biggest. Caching data is easy. Deciding what happens when two crew bosses on the same engine both create a ticket for the same date while disconnected for nine days is a design decision with real engineering behind it, and a quote that does not mention it has not accounted for it.

Second, agreement variants. Each distinct agreement and agency is its own rate structure, its own conditions and its own set of test cases. Two agreements is not twice one agreement, but four is meaningfully more than two, and every additional resource category adds a billing shape.

Third, prevailing wage. If any of your assignments fall under a wage determination, the payroll side gains rules, exception handling and reporting that a standard hourly build does not carry.

Fourth, device fleet and support. Rugged devices, a mobile plan, and someone to answer a call from a crew boss at midnight in August are running costs, not build costs, and they are yours after launch. Ask any prospective developer to price these four explicitly before you compare quotes.

What separates a build that works from one that fails here?

Timing first. Start in October, not June. A half-adopted system during a busy August is worse than a well-run carbon form, because crews revert under pressure and you finish the season with two incomplete records instead of one complete one. We turn work away in July for this reason.

Second, design for the crew boss, not the office. This system lives or dies on whether a tired engine boss will use it at the end of a sixteen hour shift. That means very few taps, large touch targets, and no required field a person in the field cannot actually know. If the demo looks like an accounting screen, it will not survive a fire.

Third, keep the paper. The incident still wants a form across the table, and your system should print one. A build that tries to eliminate paper on day one fights the process instead of protecting it. The goal is that your record stops depending on the paper surviving the truck cab.

Fourth, insist on the variance table. When an agency pays a different amount, per-line variance turns a dispute into a document you can send. A variance you can point to gets resolved. One you can only describe does not.

Finally, settle ownership of the code, the repository and the hosting in writing before kickoff. At Digital Heroes it is yours from the first commit.